Trap OIDs from WLSX-TRAP-MIB compiled in Spectrum MIB Tools do not match the traps seen from the device.
Article ID: 52662
Updated On:
Products
Issue/Introduction
After compiling the WLSX-TRAP-MIB in Spectrum MIB Tools and creating the AlertMap files, the trap OIDs sent from the device and those from in the AlertMap file from the compile of the WLSX-TRAP-MIB are different. The solution explains why they are different.
Environment
Component: SPCCSS
Resolution
For example, the AlertMap file from the trap mib compile has the following OID for trap number 1121:
1.3.6.1.4.1.14823.2.3.1.11.1.2.6.1121
But the device is sending the following oid for trap number 1121:
1.3.6.1.4.1.14823.1.1.4.6.1121
After reviewing the trap mib, it was determined MIB Tools did in fact create the AlertMap files with the correct trap OIDs according to the WLSX-TRAP-MIB.
To explain: Using the following AlertMap file entry provided by the customer:
# wlsxUserEntryChanged
1.3.6.1.4.1.14823.2.3.1.11.1.2.6.1121 0xfff00079
What we did was use the aruba-trap.my file provided by the customer to walk the MIB to verify the trap mapping. To do this, you need to walk the trap OID backwards through the MIB. Using the above OID for the wlsxUserEntryChanged trap, you start at "1121". When you search for "1121" in the aruba-trap.my file, you find the following:
wlsxUserEntryChanged NOTIFICATION-TYPE
OBJECTS {wlsxTrapTime, wlsxTrapTableGenNumber,wlsxTrapUserIpAddress,
wlsxTrapUserPhyAddress,wlsxTrapTableEntryChangeType}
STATUS current
DESCRIPTION
"
This trap indicates that the user configuration has changed.
"
::= {wlsxTrapDefinitionsGroup 1121 }
Enterprise traps will always use the standard value of 6, so when walking backwards as defined by the SNMLP trap standards, we can assume walking backwards the next number is 6. So, with that we now have "1121.6".
Using {wlsxTrapDefinitionsGroup 1121 } from the wlsxUserEntryChanged trap, to get the next number, we need to find where "wlsxTrapDefinitionsGroup" is defined. Looking back through the MIB, we find the following:
--Trap Definitions Group contains Traps definitions.
wlsxTrapDefinitionsGroup OBJECT IDENTIFIER ::= { wlsxTrapsGroup 2 }
So, using the above, the next number after 6 is the 2. So now we have "1121.6.2".
Using { wlsxTrapsGroup 2 } from the above, to get the next number, we need to find where "wlsxTrapsGroup" is defined. Looking back through the MIB, we find the following:
-- This group defines all the traps generated by the switch.
wlsxTrapsGroup OBJECT IDENTIFIER ::= { wlsrTrapMIB 1 }
Using the above, the next number after "2" is the "1" from above which now gives us "1121.6.2.1". Following back through the mib for the next number, we need to find where "wlsrTrapMIB" is defined.
Looking back through the mib, we find the following:
wlsrTrapMIB MODULE-IDENTITY LAST-UPDATED "0907071721Z"
ORGANIZATION "Aruba Wireless Networks"
CONTACT-INFO
"Postal: 1322 Crossman Avenue
Sunnyvale, CA 94089
E-mail: [email protected]
Phone: +1 408 227 4500"
DESCRIPTION
"This MIB defines the Traps generated by the switch.
"
REVISION "0907071721Z"
DESCRIPTION
"The initial revision."
::= { wlsrEnterpriseMibModules 11 }
Using the above information, the next number after the 1 is 11, which now gives us "1121.6.2.1.11".
Continue walking the MIB all the way back. If we look at what we have and compare it with the OID in the AlertMap and the OID from the trap itself, we can see that the OID from the AlertMap file is correct according to the MIB.
Our walk back through the MIB gave us "1121.6.2.1.11"
AlertMap trap OID "1.3.6.1.4.1.14823.2.3.1.11.1.2.6.1121"
Trap OID from device "1.3.6.1.4.1.14823.1.1.4.6.1121"
Conclusion:
The trap OID from the device is always assumed to be correct because it is the device that is sending the trap to Spectrum. Spectrum has no control on what the device is sending as a trap. The only thing Spectrum can do is process what it receives. So you must change the AlertMap file to match what is received from the device.
Feedback
