[j-nsp] BGP4-MIB-v2

[Jeff Haas]

> On Jan 20, 2017, at 9:29 AM, Vincent Bernat <bernat at luffy.cx> wrote:
> 
> Hey!
> 
> 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. :-)

> 
> 
> The MIB says:
> 
>    jnxBgpM2PeerEntry OBJECT-TYPE
>        SYNTAX     JnxBgpM2PeerEntry
>        MAX-ACCESS not-accessible
>        STATUS     current
>        DESCRIPTION
>            "Entry containing information about the connection with
>             a remote BGP peer."
>        INDEX {
>            jnxBgpM2PeerRoutingInstance,
>            jnxBgpM2PeerLocalAddrType,
>            jnxBgpM2PeerLocalAddr,
>            jnxBgpM2PeerRemoteAddrType,
>            jnxBgpM2PeerRemoteAddr
>        }
>        ::= { jnxBgpM2PeerTable 1 }
> 
> And jnxBgpM2PeerLocalAddr is:
> 
>    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.

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

I also take your point that the idea of the InetAddress "union" would seem to imply a variable length.  However, this is perhaps a better question for the authors of RFC 4001... most of whom don't care about SNMP these days and have moved on to yang. :-)

-- Jeff (who has grown to know much about, and loathe, SNMP)