Ken- You're right that the value of varbind 1.3.6.1.6.3.1.1.4.1 is the OID of the trap, which in your case is 1.3.6.1.4.1.9.9.187.0.1. If this was a v1 trap, the OID would have been in three pieces: + Enterprise OID: 1.3.6.1.4.1.9.9.187 + Generic trap type: 6 (this is an artifact of the v1 standard, and does not appear in your v2 trap) + Specific trap type: 1 (this is the last number from your OID)
To process the v1 version of this trap in Spectrum, the alert map file would specify the concatenation of these three elements: 1.3.6.1.4.1.9.9.187.6.1. To prevent having to duplicate alert map entries for v2 traps, Spectrum has a method to map v2 trap OIDs onto the v1 trap OIDs. This method is detailed in the "How an SNMPv2 Trap is Mapped to a CA Spectrum Event" section of Appendix A in the "Event Configuration User Guide". In your particular instance, the modification is simply to replace the "0" in the v2 OID with a "6" to get the equivalent v1 OID. HTH, Jim On 10/6/11 11:49 PM, "Kenneth Kirchner" <[email protected]> wrote: Hello Christian, No, I am absolutely not sure what I am looking at. That is why I am here. :-) This is my first attempt at decoding a trap at the packet level. Thankfully WireShark has the structure of SNMP data, so it can fill in the pieces (and it's really awesome that I can plug the EngineID, user, auth key, and private key into it and decode the v3 packet!). I opened a TAC case with Cisco when I saw this in the event logs because I thought I was missing a MIB. Cisco says there is no such thing as a trap with an OID of *.187.6.1 so either it's an IOS bug or a Spectrum bug. According to my research, the 1.3.6.1.6.3.1.1.4.1.0 OID is the "snmpTrapOID" and it is how Spectrum (or any NMS) determines which trap it received. It is part of the SNMPv2 notification specification. That's why the value assigned to that OID is the OID of the trap the device sent. There is no other spot in the PDU that provides this information that I can find. You get two OID's in every trap at a minimum. The first is the uptime OID of the device (in seconds), the second is the OID of the trap that was triggered. In this case, there was a BGP event that triggered the *187.0.1 trap, and that trap included 4 var binds of additional data (6 OID's total in the trap PDU). Why did Spectrum bollox it up and think it said 187.6.1? Does it have something to do with there being 6 OID's in the packet or is it just coincidence? I think I have a trap generator and I might test this theory if I can figure out how to work it. I would say that your point about what arrived at Spectrum is incorrect. I captured the packet at the Spectrum interface and upon decoding it, there is no mention of 187.6.1, but there is mention of 187.0.1 which is a valid trap OID and the MIB definition of that trap matches the var bind OID's perfectly. There is no question in my mind that this should have been translated as an 187.0.1 trap. This will probably turn into a CA Support case tomorrow, unless someone here has seen this and it's a known issue (and hopefully fixed in SP1). And there is a pattern developing. There was another unknown trap of *.187.6.2 that came in with the snmpTrapOID value set to *.187.0.2 which is also a valid trap OID in the BGP4 MIB, so... Anybody else drinkin' my Kool-aid? -Ken >From the Cisco SNMP Object Navigator: snmpTrapOID (1.3.6.1.6.3.1.1.4.1) = "The authoritative identification of the notification currently being sent. This variable occurs as the second varbind in every SNMPv2-Trap-PDU and InformRequest-PDU." On Oct 6, 2011, at 10:53 PM, Christian Schneider wrote: Hi Ken, Are you shure you are looking at the right place? Unknown alert received from device Router_X of type Rtr_Cisco. Device Time 355+08:35:50. (Trap type 1.3.6.1.4.1.9.9.187.6.1) is what is arrived @Spectrum and Why is Spectrum picking *187.6.1 as the trap OID when the SNMPv2 Trap OID (1.3.6.1.6.3.1.1.4.1.0) value clearly states that it is *.187.0.1? There this is what the Trap OID you where reference to. Now as you can see above 1.3.6.1.4.1.9. refers to the Cisco Private Mib (CiscoBgp4MIB) but .1.3.6.1.6.3... is something else (v2 SNMP Modules) Regards, -- * --To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected] --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
