All Apps and Add-ons

Entire SNMP Table is queried insted of object_name

bohrasaurabh
Communicator

References:

system = 1.3.6.1.2.1.1

sysName = 1.3.6.1.2.1.1.5

ifEntry = 1.3.6.1.2.1.2.2.1

ifDescr = 1.3.6.1.2.1.2.2.1.2

ifSpeed = 1.3.6.1.2.1.2.2.1.5

I have the object_names as defined below in the local/inputs.con defined.

object_names = 1.3.6.1.2.1.2.2.1.5,1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.1.5

What I am noticing is that instead of just querying the sysName, ifDescr and ifSpeed from the device (its a cisco device), the snmp_ta queries the entire system and ifEntry tables using getBulkRequest.

On a RHEL server if you run the snmpbulkwalk with an OID, it just returns the all the OID entry.

snmpbulkwalk -v 2c -c public 192.168.10.11 1.3.6.1.2.1.2.2.1.5

Has anyone else noticed this. Any workaround which is available?

Tags (1)
0 Karma
1 Solution

bohrasaurabh
Communicator

Additional References:

ifType = 1.3.6.1.2.1.2.2.1.3

ifMtu = 1.3.6.1.2.1.2.2.1.4

ifPhysAddress = 1.3.6.1.2.1.2.2.1.6

After a lot of testing I can definitely say there is bug if we use GET BULK.

From my original question if you see objects_names, I just want to query ifSpeed, ifDescr (both of these have multiple instances) and sysName from the target device.

The device I am testing has 1069 interfaces. So the number of events after SNMP poll expected are 1069 + 1069 + 1 = 2139. As verified by running the following commands on an RHEL box using snmpbulkwalk shipped with net-snmp.

snmpbulkwalk -v 2c -c public 192.168.10.11 1.3.6.1.2.1.2.2.1.5 = 1069 results

snmpbulkwalk -v 2c -c public 192.168.10.11 1.3.6.1.2.1.2.2.1.2 = 1069 results

snmpbulkwalk -v 2c -c public 192.168.10.11 1.3.6.1.2.1.1.5 = 1 result

Based on my initial configuration as below, I was getting 3267 events per poll.

===Partial initial config of inputs.conf===

[snmp://myDevice]

object_names = 1.3.6.1.2.1.2.2.1.5,1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.1.5

do_bulk_get = 1

split_bulk_output = 1

===End Partial initial config of inputs.conf===

After feedback from Damien and separating sysName into a different stanza as its an instance itself. I received 2183 events. Cutting down the unnecessary events by 1128.

However there were still 44 extra events. At this point I noticed that there were extra 22 events each from ifType and ifPhysAddress, which happens to be the next OIDs after ifDescr and ifSpeed respectively (See references for the OIDs). No instance of ifMtu was observed.

Note: You have to specify sysName as instance with .0 in the end and NO GET BULK

===Partial second config of inputs.conf===

[snmp://myDevice]

object_names = 1.3.6.1.2.1.2.2.1.5,1.3.6.1.2.1.2.2.1.2

do_bulk_get = 1

split_bulk_output = 1

[snmp://myDevice_sysName]

object_names = 1.3.6.1.2.1.1.5.0

do_bulk_get = 0

split_bulk_output = 0

===End Partial second config of inputs.conf===

On further testing this morning, I separated all the three OIDs in different stanzas, and after that I started receiving 2151 events. Only 12 extra events. I observed that there were 6 extra events from each ifType and ifPhysAddress.

===Partial final config of inputs.conf===

[snmp://myDevice_ifSpeed]

object_names = 1.3.6.1.2.1.2.2.1.5

do_bulk_get = 1

split_bulk_output = 1

[snmp://myDevice_ifDescr]

object_names = 1.3.6.1.2.1.2.2.1.2

do_bulk_get = 1

split_bulk_output = 1

[snmp://myDevice_sysName]

object_names = 1.3.6.1.2.1.1.5.0

do_bulk_get = 0

split_bulk_output = 0

===End Partial final config of inputs.conf===

Lessons learned for 1.0.6b release

  1. Using an instance (like sysName) and an OID which has instances in the same object_names might fetch you a lot of unwanted events (initial config with GET BULK).
  2. Even though "comma" is supported in the object_names field, if OIDs having multiple instances are queried in a comma separated object_names you will get 22 (or its multiple) unwanted events (second config)
  3. Even if you separate the OIDs which has multiple instances in different stanza's, you will get 6 unwanted events per stanza (final config).
  4. Do not use "commas" in the config.

If this defect can be resolved that would be very helpful, as I will be able to save indexing of 8640 (60x24x6) events per OID with instance per device. To start with I am planning to poll 100 devices for ifDescr and ifSpeed every minute which would mean 1.73 million unwanted events per day could be saved from indexing.

View solution in original post

0 Karma

bohrasaurabh
Communicator

Additional References:

ifType = 1.3.6.1.2.1.2.2.1.3

ifMtu = 1.3.6.1.2.1.2.2.1.4

ifPhysAddress = 1.3.6.1.2.1.2.2.1.6

After a lot of testing I can definitely say there is bug if we use GET BULK.

From my original question if you see objects_names, I just want to query ifSpeed, ifDescr (both of these have multiple instances) and sysName from the target device.

The device I am testing has 1069 interfaces. So the number of events after SNMP poll expected are 1069 + 1069 + 1 = 2139. As verified by running the following commands on an RHEL box using snmpbulkwalk shipped with net-snmp.

snmpbulkwalk -v 2c -c public 192.168.10.11 1.3.6.1.2.1.2.2.1.5 = 1069 results

snmpbulkwalk -v 2c -c public 192.168.10.11 1.3.6.1.2.1.2.2.1.2 = 1069 results

snmpbulkwalk -v 2c -c public 192.168.10.11 1.3.6.1.2.1.1.5 = 1 result

Based on my initial configuration as below, I was getting 3267 events per poll.

===Partial initial config of inputs.conf===

[snmp://myDevice]

object_names = 1.3.6.1.2.1.2.2.1.5,1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.1.5

do_bulk_get = 1

split_bulk_output = 1

===End Partial initial config of inputs.conf===

After feedback from Damien and separating sysName into a different stanza as its an instance itself. I received 2183 events. Cutting down the unnecessary events by 1128.

However there were still 44 extra events. At this point I noticed that there were extra 22 events each from ifType and ifPhysAddress, which happens to be the next OIDs after ifDescr and ifSpeed respectively (See references for the OIDs). No instance of ifMtu was observed.

Note: You have to specify sysName as instance with .0 in the end and NO GET BULK

===Partial second config of inputs.conf===

[snmp://myDevice]

object_names = 1.3.6.1.2.1.2.2.1.5,1.3.6.1.2.1.2.2.1.2

do_bulk_get = 1

split_bulk_output = 1

[snmp://myDevice_sysName]

object_names = 1.3.6.1.2.1.1.5.0

do_bulk_get = 0

split_bulk_output = 0

===End Partial second config of inputs.conf===

On further testing this morning, I separated all the three OIDs in different stanzas, and after that I started receiving 2151 events. Only 12 extra events. I observed that there were 6 extra events from each ifType and ifPhysAddress.

===Partial final config of inputs.conf===

[snmp://myDevice_ifSpeed]

object_names = 1.3.6.1.2.1.2.2.1.5

do_bulk_get = 1

split_bulk_output = 1

[snmp://myDevice_ifDescr]

object_names = 1.3.6.1.2.1.2.2.1.2

do_bulk_get = 1

split_bulk_output = 1

[snmp://myDevice_sysName]

object_names = 1.3.6.1.2.1.1.5.0

do_bulk_get = 0

split_bulk_output = 0

===End Partial final config of inputs.conf===

Lessons learned for 1.0.6b release

  1. Using an instance (like sysName) and an OID which has instances in the same object_names might fetch you a lot of unwanted events (initial config with GET BULK).
  2. Even though "comma" is supported in the object_names field, if OIDs having multiple instances are queried in a comma separated object_names you will get 22 (or its multiple) unwanted events (second config)
  3. Even if you separate the OIDs which has multiple instances in different stanza's, you will get 6 unwanted events per stanza (final config).
  4. Do not use "commas" in the config.

If this defect can be resolved that would be very helpful, as I will be able to save indexing of 8640 (60x24x6) events per OID with instance per device. To start with I am planning to poll 100 devices for ifDescr and ifSpeed every minute which would mean 1.73 million unwanted events per day could be saved from indexing.

0 Karma

Damien_Dallimor
Ultra Champion

I think you also emailed me , and the email had more details than the above post does , ergo , posting my email answer here also for the benefit of the audience.

You have "Perform GET Bulk" enabled

do_bulk_get = 1

Disable it.

do_bulk_get = 0

0 Karma

Damien_Dallimor
Ultra Champion

You've just described how it is designed to work.

A stanza is either in "get bulk" mode or "single mode" based on whether or not you select the Perform GET BULK" check box.

Ergo , the OID patterns you enter in the "Object Names List" should reflect you modal choice for the stanza definition.

So you should separate up your stanza definitions accordingly.

0 Karma

dongxian
New Member

Hi Damien,

The GETBULK seems only working with the regular indexed table, like the OID:1.3.6.1.2.1.2.2.1.2 (IF-MIB::ifDescr), which works and return ifDescr.1, ifDescr.2, etc.

There are some table which is not index by .1, .2, instead, they are index by MAC address. In this case, your GETBULK (or pysnmp) doesn't seem work. I got error messages on splunkd.log, something like:

SmiError: Excessive instance identifier sub-OIDs left at MibTableRow((1, 3, 6, 1, 4, 1, 12356, 101, 14, 5, 1), None): (208, 45, 86, 26, 154)

snmpwalk is working fine with this table.

Do you have any idea how to fix it?

Thanks!
Don

0 Karma

seanel
Path Finder

I also think I see some bugginess too though with the getsubtree instead of bulk.

If I have a bunch of subtree walks seperated into individual stanzas, I get just what I expect to get. However if I then combine them into a single stanza, then I end up with about 12 extra objects from another tree which is not requested.

Not a big deal as I can use seperate stanzas anyway - but thought I should report it here

0 Karma

bohrasaurabh
Communicator

I understand that. Even than there is issue wih the app when get bulk is used. It does get bulk polls for the next oid also which should be fixed.

0 Karma

Damien_Dallimor
Ultra Champion

You can setup multiple SNMP input stanzas for different combinations of OID polling behaviours. So "get bulk" polling might be in 1 stanza and "single instance" polling in another stanza etc...

0 Karma

bohrasaurabh
Communicator

Based on the devices we have there could be several of interfaces on them and there is no way to use instance. The only issue I see in my config is that the last oid is an instance sysName, however the first two are oids with multiple instances.

If I remove the sysName and just have ifDescr and ifSpeed. I notice that the results are close, however not accurate

Additional OID’s which are polled are
IfType = 1.3.6.1.2.1.2.2.1.3 and IfPhysAddress = 1.3.6.1.2.1.2.2.1.6

Which happens to the next OIDs from the one I am polling. I guess for get bulk your code is polling the oids & next oids also

0 Karma

Damien_Dallimor
Ultra Champion

Then, as you are not walking the tree, specify your OIDs correctly to target the specific Object instances in the tabular group.

As a simple example :

ifEntry = 1.3.6.1.2.1.2.2.1

1.3.6.1.2.1.2.2.1.10.1.

0 Karma

bohrasaurabh
Communicator

I get the below error message if I disable do_bulk_get

SNMPv2-SMI::mib-2."2.2.1.5" = "No Such Instance currently exists at this OID" SNMPv2-SMI::mib-2."2.2.1.2" = "No Such Instance currently exists at this OID" SNMPv2-MIB::sysName."" = "No Such Instance currently exists at this OID"

0 Karma
Get Updates on the Splunk Community!

Splunk Custom Visualizations App End of Life

The Splunk Custom Visualizations apps End of Life for SimpleXML will reach end of support on Dec 21, 2024, ...

Introducing Splunk Enterprise 9.2

WATCH HERE! Watch this Tech Talk to learn about the latest features and enhancements shipped in the new Splunk ...

Adoption of RUM and APM at Splunk

    Unleash the power of Splunk Observability   Watch Now In this can't miss Tech Talk! The Splunk Growth ...