BGP4-V2-MIB-JUNIPER, take 2

[paravoid]

OK, I have no idea if this is an implementation, MIB, snimpy, or libsmi bug, or a misunderstanding of mine but last time you were helpful, so maybe you are this time too :)

Background

Three years ago, I was trying to use BGP4-V2-MIB-JUNIPER with snimpy, and ran into a wall. At the time, you thought it was a Juniper bug, reported it to j-nsp, and Jeff Haas (IETF draft MIB author, and Juniper employee) filed a PR internally about it. This has been now fixed in recent JunOS (18.1R1, 18.2R1, 19.3R3, 19.4R2, 20.1R1) \o/ It is behind a configuration option (set protocols bgp snmp-options emit-inet-address-length-in-oid) as (as you had guessed at the time) it would otherwise break backwards compatibility.

Issue at hand

So, time for take 2 :)

$ snmpwalk … BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerState
…
BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerState.0.ipv4."91.198.174.246".ipv4."10.20.0.100" = INTEGER: established(6)

Equivalent snimpy code is:

Snimpy[20]> list(m.jnxBgpM2PeerState.items())
…
 ((<Unsigned32: 0>,
   <Enum: ipv4(1)>,
   <OctetString: b'[\xc6\xae\xf6'>,
   <Enum: ipv4(1)>,
   <OctetString: b'\n\x14\x00d'>),
  <Enum: established(6)>),

(Same while walking jnxBgpM2PeerState, and for jnxBgpM2PeerIdentifier)

So it seems like snimpy does not recognize/parse the IP addresses there and instead reports them as OctetStrings. It seems like in the MIB, they are defined as e.g. jnxBgpM2PeerLocalAddrType and jnxBgpM2PeerLocalAddr, which are InetAddressType and InetAddress (SIZE(4..20)) respectively.

I'm not sure how snimpy /can/ know that the entry has two (type, address) tuples in sequence, but I'd surely like it to :) It seems like 33715fa has something about overriding types, and the test suite has some code for InetAddress/InetAddressType, but I'm unsure how one could use that here.

Thanks for the help :)