Possible SNMP issue

[Eric Stern]

http://www.oid-info.com/get/1.3.6.1.2.1.2.2.1.5

Looks right to me. The values are either 1000000000 (1,000,000,000 ie 1Gb) or 100000000 (100,000,000 ie 100Mb).

[Nitroxide]

To update this, one of the firmware updates on the Netonix finally stopped this issue in Solarwinds. Oh it was happy days when the logs weren't flooded with this.

Just upgrade to the latest RC

[sirhc]

To update this, one of the firmware updates on the Netonix finally stopped this issue in Solarwinds. Oh it was happy days when the logs weren't flooded with this.

Just upgrade to the latest RC

Always try the LATEST firmware version FIRST before pulling your hair out and making a post asking help.

Glad your issue is resolved.

[noc@ethoplex.com]

It appears that TLS 1.2 isn't supported in v.1.4.7 when using SNMP for alerts. Can anyone else verify?
I needed to uncheck the "Secure" option to get test emails to get through. I have tested on 3 different switches.

I have not tried the beta FW. Would that take care of the issue? I would prefer not to use the beta FW in a production network if possible.

[Julian]

RC version numbering is a holdout from times past - 1.4.8rc12 is not beta firmware.

[davidbaker]

Just a quick update and hopefully last update, after working with Solarwinds for months they found the issue to be with the Netonix. Ill be updating to the new firmware hoping it fixes my issue. Just wanted to post Solarwinds official response to me in hopes it might help others in the future.

This is from Solarwinds support:

"Development believes they have found the issue and its a problem with the device.

Put simply, when we walk the device we don’t see the SNMP responses we need. When we look at what the device replies with via Wireshark, there are responses on the ifHighSpeed OID (which wasn’t found in the walk) and those responses are responsible for the issue.

The bottom line is an SNMP walk from the device, and the responses we get while polling are different. That suggests that the device isn’t handing SNMP requests properly, hence we are reporting inaccurately. We suggest that you contact the vendor with the wireshark, and SNMPwalk and work with them to resolve the issue.


Here is the response from our dev team.

We ask for ifHighSpeed OID (1.3.6.1.2.1.31.1.1.1.15).
According to SNMPwalk the device does not support this OID
.1.3.6.1.2.1.31.1.1.1.13.11 = COUNTER64: 2082192
.1.3.6.1.2.1.31.1.1.1.13.12 = COUNTER64: 23016738
.1.3.6.1.2.1.31.1.1.1.13.13 = COUNTER64: 0
.1.3.6.1.2.1.31.1.1.1.13.14 = COUNTER64: 0
.1.3.6.1.2.1.31.1.1.1.18.1 = STRING: "1"
.1.3.6.1.2.1.31.1.1.1.18.2 = STRING: "2"
.1.3.6.1.2.1.31.1.1.1.18.3 = STRING: "3"
.1.3.6.1.2.1.31.1.1.1.18.4 = STRING: "4"
.1.3.6.1.2.1.31.1.1.1.18.5 = STRING: "5"

When you check the pcap (use filter ip.addr==10.12.64.137 && snmp.name contains 1.3.6.1.2.1.31.1.1.1.15), the device sends responses on ifHighSpeed OID and the value is different with every poll (growing up as a counter). This seems to be device issue and customer should discuss with vendor. We report exactly what we get from device."

[sirhc]

Just a quick update and hopefully last update, after working with Solarwinds for months they found the issue to be with the Netonix. Ill be updating to the new firmware hoping it fixes my issue.

So you're running an OLDER version of firmware on the Netonix Switch?

[Eric Stern]

Just a quick update and hopefully last update, after working with Solarwinds for months they found the issue to be with the Netonix. Ill be updating to the new firmware hoping it fixes my issue. Just wanted to post Solarwinds official response to me in hopes it might help others in the future.

This is from Solarwinds support:

"Development believes they have found the issue and its a problem with the device.

Put simply, when we walk the device we don’t see the SNMP responses we need. When we look at what the device replies with via Wireshark, there are responses on the ifHighSpeed OID (which wasn’t found in the walk) and those responses are responsible for the issue.

The bottom line is an SNMP walk from the device, and the responses we get while polling are different. That suggests that the device isn’t handing SNMP requests properly, hence we are reporting inaccurately. We suggest that you contact the vendor with the wireshark, and SNMPwalk and work with them to resolve the issue.


Here is the response from our dev team.

We ask for ifHighSpeed OID (1.3.6.1.2.1.31.1.1.1.15).
According to SNMPwalk the device does not support this OID
.1.3.6.1.2.1.31.1.1.1.13.11 = COUNTER64: 2082192
.1.3.6.1.2.1.31.1.1.1.13.12 = COUNTER64: 23016738
.1.3.6.1.2.1.31.1.1.1.13.13 = COUNTER64: 0
.1.3.6.1.2.1.31.1.1.1.13.14 = COUNTER64: 0
.1.3.6.1.2.1.31.1.1.1.18.1 = STRING: "1"
.1.3.6.1.2.1.31.1.1.1.18.2 = STRING: "2"
.1.3.6.1.2.1.31.1.1.1.18.3 = STRING: "3"
.1.3.6.1.2.1.31.1.1.1.18.4 = STRING: "4"
.1.3.6.1.2.1.31.1.1.1.18.5 = STRING: "5"

When you check the pcap (use filter ip.addr==101.12.64.137 && snmp.name contains 1.3.6.1.2.1.31.1.1.1.15), the device sends responses on ifHighSpeed OID and the value is different with every poll (growing up as a counter). This seems to be device issue and customer should discuss with vendor. We report exactly what we get from device."

This will be fixed in the next release.