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]<mailto:[email protected]> with the body: unsubscribe spectrum
[email protected]
* --To unsubscribe from spectrum, send email to
[email protected]<mailto:[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]
