Re: MIB format

Hi,

The OIDs have values, but the OID itself also represents certain values, 
as it contains a meaningful index. The question was about the meaning of 
part of the OID, not about the meaning of the value.

Indeed the "32" is the first index into the table, representing the 
value of cbgpPeer2Type.

The current version of CISCO-BGP4-MIB 
(ftp://ftp.cisco.com/pub/mibs/v2/CISCO-BGP4-MIB.my) defines 
cbgpPeer2Type as type InetAddressType, imported from INET-ADDRESS-MIB. 
Still true however that the InetAddressType value 32 is not defined in 
current INET-ADDRESS-MIB; last version of that MIB that I can find is in 
RFC 4001 (https://tools.ietf.org/html/rfc4001).

Without knowing what InetAddressType 32 stands for, it's just guesswork 
how to interpret the second index into the table (cbgpPeer2RemoteAddr = 
1.14.16.255.255.17.0.0.0.0.0.0.0.0.2).

It could be some kind of implementation bug of course. Suppose that the 
"32" is actually part of the address and that the octet for the address 
type has been accidentally left out. Following the "32" are 15 octets, 
so when we add them together, we have an address consisting of 16 
octets. That equals 128 bits, or the length of an IPv6 address. 
Converting 16 octets from the OID (in decimal / base10 notation) to the 
hex / base16 representation, you'd get 
2001:0d10:ffff:1100:0000:0000:0000:0002, or 2001:d10:ffff:1100::2 when 
using the common shorthand for an IPv6 address. Looks plausible... and 
WHOIS also has results for 2001:0D10::/32.

So, does the ASR in question happen to have a BGP peering with 
2001:d10:ffff:1100::2? Then that session is the one you received a trap 
about, and your ASR is running software with a bug in the CISCO-BGP4-MIB 
implementation. If not, then my guess was completely wrong :-)


Regards,
Jeroen

On 18-05-16 17:37, Jurkiewicz Jean-Marc wrote:
>
> Hi
>
> I think that in :
>
> .1.3.6.1.4.1.9.9.187.1.2.5.1.17.32.1.14.16.255.255.17.0.0.0.0.0.0.0.0.2=04 
> 00
>
> 04 00 is the Error code and Error 
> subcode(https://tools.ietf.org/html/rfc4271#page-21)
>
> NOT 32.1.14.16.255.255.17.0.0.0.0.0.0.0.0.2
>
> So the error 04 = Hold time expired
>
> Subcode 02 = bad message length.
>
> Please: OID should not be confused with returned value
>
> 32.1.14.16.255.255.17.0.0.0.0.0.0.0.0.2
>
> Provides information about the route that was updated while the error 
> occurred: looks like RD (route distinguisher + route + netmask+ ???)
>
> Best Regards
>
> JM
>
> *De :*Fulko Hew [mailto:[email protected]]
> *Envoyé :* mercredi, 18. mai 2016 16:55
> *À :* andrewarnier <[email protected]>
> *Cc :* [email protected]
> *Objet :* Re: MIB format
>
>
>
> On Wed, May 18, 2016 at 10:01 AM, andrewarnier <[email protected] 
> <mailto:[email protected]>> wrote:
> > Hi all,
> >
> > Tue May 17 23:59:43 2016: Unknown trap (.1.3.6.1.4.1.9.9.187.0.8) 
> received
> > from CISCOASR at:
> >
> > Value 0: CISCOASR
> > Value 1: 10.10.1.2
> > Value 2: 386:3:31:07.03
> > Value 3: .1.3.6.1.4.1.9.9.187.0.8
> > Value 4: 10.10.1.2
> > Value 5: public
> > Value 6: .1.3.6.1.4.1.9.9.187
> > Value 7:
> > Value 8:
> > Value 9:
> > Value 10:
> > Ent Value 0: 
> .1.3.6.1.4.1.9.9.187.1.2.5.1.17.32.1.14.16.255.255.17.0.0.0.0.0.0.0.0.2=04 
> 00
> > Ent Value 1: 
> .1.3.6.1.4.1.9.9.187.1.2.5.1.3.32.1.14.16.255.255.17.0.0.0.0.0.0.0.0.2=1
> > Ent Value 2: 
> .1.3.6.1.4.1.9.9.187.1.2.5.1.28.32.1.14.16.255.255.17.0.0.0.0.0.0.0.0.2=hold 
> time expired
> > Ent Value 3: 
> .1.3.6.1.4.1.9.9.187.1.2.5.1.29.32.1.14.16.255.255.17.0.0.0.0.0.0.0.0.2=3
> >
> > I think the trap is about CISCO-BGP4-MIB
> >
> > For example ,
> >
> > As you can see part of the
> > 
> OID(1.3.6.1.4.1.9.9.187.1.2.5.1.28.32.1.14.16.255.255.17.0.0.0.0.0.0.0.0.2)
> > can be translated into cbgpPeer2LastError
> >
> > What's the string (32.1.14.16.255.255.17.0.0.0.0.0.0.0.0.2) meaning?
>
> This trap is the 'cbgpPeer2BackwardTransition' trap, and provides the 
> following 4 variables:
> cbgpPeer2LastError, cbgpPeer2State, cbgpPeer2LastErrorTxt, 
> cbgpPeer2PrevState
>
> Each variable's OID is defined by its base OID and its index.
> In the case of these variables, they are part of a table that is 
> indexed by:
>
> cbgpPeer2Type, cbgpPeer2RemoteAddr
>
> cbgpPeer2Type
>
> ​​
>
> is defined as an INTEGER
> cbgpPeer2RemoteAddr is defined as an InetAddress
>
> ​which ​
>
> is ultimately defined as an OCTET STRING (SIZE (0..255))
>
> so:
>
> 32 - is the
>
> ​​
>
> ​​
>
> ​'​
>
> cbgpPeer2Type
>
> ​'​
>
> ​​
>
> and probably tells you the exact format of the value of 
> cbgpPeer2RemoteAddr
>       (unfortunately the version of that MIB file I have doesn't have 
> the value of 32 defined.
>       Obviously they have updated that MIB since I got my copy)
>
> 1.14.16.255.255.17.0.0.0.0.0.0.0.0.2 - is the
>
> ​value of ​
>
> cbgpPeer2RemoteAddr
>
> And this was all defined in their 'CISCO-BGP4-MIB-V1SMI' MIB.
>

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users