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]
