> On Jan 20, 2017, at 9:29 AM, Vincent Bernat <[email protected]> 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)
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
