Not all OID's in snmp.yml are walked by snmp_exporter.

[codylellis]

I am using third party MIB from security vendor with a couple of tables from if_mib.

I've included practically all tables from the 3rd party MIB to get vendor relevant data.

Although the generator properly placed the OID's in the snmp.yml, I never see it walked in a packet capture when running a manual walk from snmp_exporter portal. Nor does the data show up in metrics scrape page. Only some of it does...

I proceeded to use generator to export an snmp.yml with a specific table that wasn't appearing before... and then I could see the data in the portal/metrics, however when all are included, this table (almost all the tables) never works anymore, nor do I see a majority of the vendor related information.

Is there a limit on the size of snmp.yml or the number of tables in the generator.yml?

Is there a limit on the number of items walked?

[bastischubert]

Is there a limit on the size of snmp.yml or the number of tables in the generator.yml?
Is there a limit on the number of items walked?
sky's the limit

do you mind adding your snmp.yml (without the auth credentials), a description whats missing and the output of snmp_expoerter when run like this: ./snmp_exporter --log.level=debug --snmp.debug-packets

[codylellis]

snmp_exporter_debugs.zip

manual walk from portal was run against 192.168.1.211

What's missing?

Anything with IPS
1.3.6.1.4.1.2620.1.53.1

from looking at the output of the manual walk in the portal, it seems a whole lot more is missing as well

When generating other snmp.yml, I've tried adding each tree by the parent oid / the name of the tree

I included the mib files as well.

[codylellis]

Any idea by chance?

[SuperQ]

It seems like the the device is not returning anything for 1.3.6.1.4.1.2620.1.53.1. Looking at the end of the log, everything seems to be fine:

ts=2024-12-13T15:12:10.267Z caller=stdlib.go:105 level=debug auth=snmpv3 target=192.168.1.211 source_address= worker=0 msg="Walk completed with NoError"
ts=2024-12-13T15:12:10.267Z caller=stdlib.go:105 level=debug auth=snmpv3 target=192.168.1.211 source_address= worker=0 msg="BulkWalk completed in 38 requests"
ts=2024-12-13T15:12:10.267Z caller=gosnmp.go:119 level=debug auth=snmpv3 target=192.168.1.211 source_address= worker=0 msg="Walk of subtree completed" oid=1.3.6.1.4.1.2620 duration_seconds=544.011124ms
ts=2024-12-13T15:12:10.273Z caller=collector.go:460 level=debug auth=snmpv3 target=192.168.1.211 source_address= worker=0 module=chkp msg="Finished scrape" duration_seconds=0.550284516

The device ends there, it just stops returning data. Perhaps the target device has a walk limit?

I typically recommend avoiding overly broad walks like this, as they are prone to returning a lot of useless data. Rather, write a generator config with more specific OID trees. This also makes it easier to debug which thing is having trouble returning dtaa.

[codylellis]

Thanks,
There's no limit on server side. I had previously tried only by table/subtree name and that wasn't working.

When I tried by the specific OID subtree, that did work.

However, I noticed that when I added the 'higher-level' subtree OID such as 1.3.6.1.4.1.2620 in addition to, for example 1.3.6.1.4.1.2620.1.53, no other sub-tree that I specified would be queried.

Removing 1.3.6.1.4.1.2620 resolved specific query issue.

However, in both cases, 1.3.6.1.4.1.2620.1.53 showed up in the generated snmp.yml with or without the 1.3.6.1.4.1.2620.

If the configuration is unlimited, I don't see why the parent ID 1.3.6.1.4.1.2620 causes such issue.

Yes, I can walk 1.3.6.1.4.1.2620 with snmpwalk without issue.

    - 1.3.6.1.4.1.2620
    - 1.3.6.1.4.1.2620.1.1
    - 1.3.6.1.4.1.2620.1.3
    - 1.3.6.1.4.1.2620.1.5
    - 1.3.6.1.4.1.2620.1.6
    - ... 
    - 1.3.6.1.4.1.2620.1.53