Cheers,
I highly recommend to read the chapter “SNMPv2 Support” (page 111) in the Spectrum “Event Configuration User Guide”. You obviously receiving SNMPv2 Traps and Spectrum is using a v2-to-v1 Trap-Translation-Method as described in RFC2576. The docs explain in detail what Spectrum does to map a v2-Trap to an event. Regards, Jan Von: Kenneth Kirchner [mailto:[email protected]] Gesendet: Freitag, 7. Oktober 2011 08:49 An: spectrum Cc: spectrum Betreff: Re: [spectrum] Bug in Spectrum Trap OID translation? 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]
