[j-nsp] BGP4-MIB-v2

[Vincent Bernat]

 ❦ 27 mars 2017 16:10 GMT, Jeff Haas <jhaas at juniper.net> :

>> I have been reported a (simple) bug in the implementation of the
>> BGP4-V2-MIB-JUNIPER. I know that if I open a JTAC case about this, I
>> will be asked a lot of unrelated questions, then I would be told that
>> since this never really worked, this is not the scope for JTAC.
>> 
>> So, as I know some Juniper people reads here, here is the bug. I'd be
>> happy to provide more details if needed.
>
> Read, yes.  Read on a timely basis, no.
>
> I also happen to be the author of the ietf mib that Juniper based this
> MIB on. :-)

Glad I have caught your attention and thanks for taking the time to answer!

>>    jnxBgpM2CfgPeerLocalAddr OBJECT-TYPE
>>        SYNTAX     InetAddress (SIZE (4..20))
>>        MAX-ACCESS read-create
>>        STATUS     current
>>        DESCRIPTION
>>            "The address of the local end of the peering session."
>>        ::= { jnxBgpM2CfgPeerEntry 4 }
>> 
>> (and similar for RemoteAddr). The important bit is the size: variable.
>> 
>> With SNMP, when an index has a variable length, except if it's the last
>> one _and_ the MIB says the size is IMPLIED, the length should be
>> prepended to the value.
>> 
>> So, 192.0.2.47 should be encoded to 4.192.0.2.47.
>
> Probably no.
>
> The headache here is that the underlying type is RFC 4001's
> InetAddress.  As you can see in the documentation in that RFC the
> expectation is that the InetAddressType is used to 'cast' the
> InetAddress to one of the underlying types; e.g. InetAddressIPv4.
> Let's pick on that example:
>
> InetAddressIPv4 ::= TEXTUAL-CONVENTION
>     DISPLAY-HINT "1d.1d.1d.1d"
>     STATUS       current
>     DESCRIPTION
>         "Represents an IPv4 network address:
>
>            Octets   Contents         Encoding
>             1-4     IPv4 address     network-byte order
>
>          The corresponding InetAddressType value is ipv4(1).
>
>          This textual convention SHOULD NOT be used directly in object
>          definitions, as it restricts addresses to a specific format.
>          However, if it is used, it MAY be used either on its own or in
>          conjunction with InetAddressType, as a pair."
>     SYNTAX       OCTET STRING (SIZE (4))

> So, while you're correct with regard to variable types, the
> expectation is that this is "cast" into a fixed sized octet string,
> which has implied length.

I didn't know about RFC 4001 so I may be mistaken, but it doesn't say
anything about the size requirement. Other than the comments in the MIB,
there is also no way to link InetAddress and InetAddressIPv4. This is
not just a matter of being able to pretty-print the IPv4, it's that we
cannot know how to split the index into its components.

> Given that net-snmp seems to recognize how to render the output from
> the MIB, I suspect others came to a similar conclusion.

Net-SNMP is not able to render the output of the MIB correctly if the
size is not specified. See, without the size:

$ snmptranslate -m BGP4-V2-MIB-JUNIPER iso.3.6.1.4.1.2636.5.1.1.2.2.1.1.5.8.1.10.64.0.3.1.10.64.0.1
BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerLastErrorReceivedText.8.ipv4.10.64.0.3.1.10.64.0.1

If I add the size:

$ snmptranslate -m BGP4-V2-MIB-JUNIPER iso.3.6.1.4.1.2636.5.1.1.2.2.1.1.5.8.1.4.10.64.0.3.1.4.10.64.0.1
BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerLastErrorReceivedText.8.ipv4."10.64.0.3".ipv4."10.64.0.1"

Other MIB implementations also using AddrType/Addr includes the size,
for example (on JunOS 14.1):

$ snmpgetnext net-tor-0114-1 IP-MIB::ipAddressTable
IP-MIB::ipAddressIfIndex.ipv4."10.64.0.3" = INTEGER: 567
$ snmpgetnext -On net-tor-0114-1 IP-MIB::ipAddressTable
.1.3.6.1.2.1.4.34.1.3.1.4.10.64.0.3 = INTEGER: 567
-- 
I was gratified to be able to answer promptly, and I did. I said I didn't know.
		-- Mark Twain