As I recall that is kind of a standard snmp thing. We used to see the same thing in trap oid mappings when we used NNM.
-----Original Message----- From: Kenneth Kirchner [mailto:[email protected]] Sent: Friday, October 07, 2011 9:37 To: spectrum Subject: Re: [spectrum] Bug in Spectrum Trap OID translation? Hello Al, Yeah, as soon as John mentioned the 6/Enterprise relationship it brought back some memories. I vaguely recall writing some Perl to mess with SNMP a long time ago and wondering where the heck the 6 was coming from. To see your example just reinforces it. So now it looks more like a Cisco bug. I am going to look at some other traps in the capture and see if the answer is to modify the MIB or the AlertMap. -Ken On Oct 7, 2011, at 4:39 AM, Sorrell, Al wrote: I'm not sure why, but that's the way EVERY Spectrum trap interpretation is set up. It's like they insert the "6" meaning that it's Enterprise Specific prior to the trap number. If you start looking through the AlertMap files, you'll see that's the way they handle it. It's quite confusing at first, but I just accepted it and "moved on". As long as the AlertMap file is setup to handle that eveverything is cool. e.g. $SPECROOT/SS/CsVendor/Cisco_Router/AlertMap 1.3.6.1.4.1.9.9.20.1.5.6.1 0x00210001 1.3.6.1.4.1.9.9.20.1.2.1.1(1,0) \ 1.3.6.1.4.1.9.9.20.1.2.1.4(2,0) \ 1.3.6.1.4.1.9.9.20.1.2.1.5(3,0) \ 1.3.6.1.4.1.9.9.20.1.2.1.12(4,0) \ 1.3.6.1.4.1.9.9.20.1.2.1.6(5,0) \ 1.3.6.1.4.1.9.9.20.1.2.1.7(6,0) \ 1.3.6.1.4.1.9.9.20.1.2.1.9(7,0) \ 1.3.6.1.4.1.9.9.20.1.2.1.10(8,0) \ 1.3.6.1.4.1.9.9.20.1.2.1.11(9,0) 1.3.6.1.4.1.9.9.24.1.4.4.6.1 0x00210002 1.3.6.1.4.1.9.9.24.1.4.2.1.2(1,0) \ 1.3.6.1.4.1.9.9.24.1.4.2.1.18(2,0) Al ________________________________ From: John O'Mahony [mailto:[email protected]] Sent: Friday, October 07, 2011 5:19 AM To: spectrum Subject: RE: [spectrum] Bug in Spectrum Trap OID translation? Hi Ken What do you actually want to achieve here? If you want to map that trap in Spectrum then you should just go ahead using trap type 6.1 (possibly 0.1 might work also but I'm not sure about that) and everything will work fine in Spectrum. My guess at what's happening here is that the Cisco trap definition is not strictly SNMP compliant. According to RFC 1157 trap prefix 0 should be used for the ColdStart trap and trap prefix 6 should be used for any Enterprise Specific traps. My guess is that Spectrum is working around this Cisco anomaly. Regards, John From: Kenneth Kirchner [mailto:[email protected]] Sent: 07 October 2011 07:49 To: spectrum Cc: spectrum Subject: 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] T. Rowe Price (including T. Rowe Price Group, Inc. and its affiliates) and its associates do not provide legal or tax advice. Any tax-related discussion contained in this e-mail, including any attachments, is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding any tax penalties or (ii) promoting, marketing, or recommending to any other party any transaction or matter addressed herein. Please consult your independent legal counsel and/or professional tax advisor regarding any legal or tax issues raised in this e-mail. The contents of this e-mail and any attachments are intended solely for the use of the named addressee(s) and may contain confidential and/or privileged information. Any unauthorized use, copying, disclosure, or distribution of the contents of this e-mail is strictly prohibited by the sender and may be unlawful. If you are not the intended recipient, please notify the sender immediately and delete this e-mail. * --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] --- To unsubscribe from spectrum, send email to [email protected] with the body: unsubscribe spectrum [email protected]
