SNMP GET HEX Values from SAN switch
Description
Environment
Acceptance / Success Criteria
Attachments
Lucidchart Diagrams
Activity
Benjamin Reed June 24, 2013 at 1:03 PM
merged to 1.12
Ron Roskens October 6, 2012 at 9:49 PM
Also see issues and for similar problems.
Ron Roskens October 6, 2012 at 9:48 PM
Adding a patch:
If the SnmpValue is not a numeric type, nor parsible as a double, but is an octet-string, try parsing the value as a hex value.
Add a test case for persisting.
Ron Roskens October 6, 2012 at 2:59 AM
I've done a little digging into this. There are two issues:
1. FCMGMT-MIB has an index at .1.3.6.1.3.94.4.5.1.2 but the oid is .1.3.6.1.3.94.4.5.1.2.{16 bytes oids - unit id}.{index}:
We need a StorageStrategy configuration that can drop the first 16 oids and leave us with the last entry which is the index number for the port.
It might not be a bad idea to create a new StorageStrategy class that can append an instance value to a sibling-column to get an index lookup.
.1.3.6.1.3.94.4.5.1.1.16.0.0.5.30.101.5.0.0.0.0.0.0.0.0.0.1 = Hex-STRING: 10 00 00 05 1E 65 05 00 00 00 00 00 00 00 00 00
.1.3.6.1.3.94.4.5.1.2.16.0.0.5.30.101.5.0.0.0.0.0.0.0.0.0.1 = INTEGER: 1
...
.1.3.6.1.3.94.4.5.1.26.16.0.0.5.30.101.5.0.0.0.0.0.0.0.0.0.1 = Hex-STRING: 00 00 00 04 3C 0D 9A C0
<mibObj oid=".1.3.6.1.3.94.4.5.1.26" instance="fcmgmtConnUnitIndex" alias="cupstc3RxFrames" type="octetstring" />
2. SnmpAttribute::getNumericValue() needs to handle an octetstring SnmpValue as a hex value.
SnmpAttribute.java
Things to think about:
a. Maybe use BigInteger to convert the hex string if it would overflow a Long so the value could be stored as a Double?
b. Are there any collection entries that currently pass their snmp values back as octet-strings that would be affected by this?
Chris S July 9, 2012 at 2:08 PM
Attached is the PCAP file
We would like to monitor our Brocade Access Gateway switches with SNMP. It appears the all the critical counter we would like to monitor are available in the MIB and can be retrieved with a SNMPWALK or GET. The issue is that all the responses coming back from the needed switch OIDs in the form of a HEX-STRING like this:
16:03:21 # snmpwalk -O e -v 1 -c <community> <hostname> 1.3.6.1.3.94.4.5.1.26
SNMPv2-SMI::experimental.94.4.5.1.26.16.0.0.5.30.9.92.19.0.0.0.0.0.0.0.0.3 = Hex-STRING: 00 00 00 01 01 53 53 FC
OpenNMS will walk the OID and get a response from the switch in the Hex-STRING format is seen above, we have confirmed that with a TCPdump trace and Wire Shark. We have made several adjustment to the snmpdatacollection.xml config file but none of the adjustments has changed the result.