Dual stack BGP breaks InetAddress

[isodude]

# HELP jnxBgpM2PeerIndex This value is a unique index for the remote peer entry in the jnxBgpM2PeerTable - 1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14
# TYPE jnxBgpM2PeerIndex gauge
jnxBgpM2PeerIndex{jnxBgpM2PeerIndex="",jnxBgpM2PeerLocalAddr="120.0.10.1",jnxBgpM2PeerRemoteAddr="0x0A78001400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",jnxBgpM2PeerRoutingInstance="0"} 19
jnxBgpM2PeerIndex{jnxBgpM2PeerIndex="",jnxBgpM2PeerLocalAddr="XXXX:XXXX:0088:8800:0000:0000:0000:XXXX",jnxBgpM2PeerRemoteAddr="0xXXXXX",jnxBgpM2PeerRoutingInstance="0"} 36
iso.3.6.1.4.1.2636.5.1.1.2.1.1.1.14.0.2.X.X.X.X.X.0.X.X.0.0.0.0.0.0.0.11.X.X.X.X.X.X.0.X.X.0.0.0.0.0.0.0.10 = Gauge32: 36
iso.3.6.1.4.1.2636.5.1.1.2.1.1.1.14.0.1.10.120.0.10.1.10.120.0.20 = Gauge32: 19

# show bgp sum
10.120.0.20           44136    2450779    2423701       0       5 1w5d 12:47:48 Establ
inet.0: 9/816766/816765/0
XXXX:XXXX:0:102::1002       44136      40048    1179160       0       3 1w5d 13:35:29 Establ
  inet6.0: 3/6/5/0

protocols bgp group 65001 neighbor 10.120.0.20
interfaces lo0 unit 1 family inet address 10.120.0.10/32

modules:
  junos_bgp:
    walk:
    - jnxBgpM2PeerIndex
    lookups:
      - source_indexes:
        - jnxBgpM2PeerRoutingInstance
        - jnxBgpM2PeerRemoteAddr
        - jnxBgpM2PeerLocalAddr
        lookup: jnxBgpM2PeerIndex
    auth:
      community: <secret>

junos_bgp:
  walk:
  - 1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14
  metrics:
  - name: jnxBgpM2PeerIndex
    oid: 1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14
    type: gauge
    help: This value is a unique index for the remote peer entry in the jnxBgpM2PeerTable
      - 1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14
    indexes:
    - labelname: jnxBgpM2PeerRoutingInstance
      type: gauge
    - labelname: jnxBgpM2PeerLocalAddr
      type: InetAddress
    - labelname: jnxBgpM2PeerRemoteAddr
      type: InetAddress
    lookups:
    - labels:
      - jnxBgpM2PeerRoutingInstance
      - jnxBgpM2PeerRemoteAddr
      - jnxBgpM2PeerLocalAddr
      labelname: jnxBgpM2PeerIndex
      oid: 1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14
      type: gauge
  auth:
    community: <secret>

Host operating system: output of uname -a

Linux remote-control 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux

snmp_exporter version: output of snmp_exporter -version

0.19.0

What device/snmpwalk OID are you using?

Juniper MX204 / 1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14

If this is a new device, please link to the MIB(s).

What did you do that produced an error?

Because InetAddress is not properly detected and gets scrambled.

What did you expect to see?

A proper IPv4 and IPv6

What did you see instead?

Scrambled data

What I tried

If I force the type of RemoteAddr to InetAddressIPv4 and InetAddressIPv6 depending on InetAddressType (1.3.6.1.4.1.2636.5.1.1.2.1.1.1.14.0.{1,2}), it all works out ok, well at least for the addresses.

[brian-brazil]

This is a device bug, the InetAddress index is lacking the index size as required by section 4.1 of RFC 4001. Try overriding it with the InetAddressMissingSize type.

[isodude]

@brian-brazil would care to show how you mean, just for the sake of it?
I see this in the mib

    jnxBgpM2PeerLocalAddr OBJECT-TYPE
        SYNTAX     InetAddress (SIZE(4..20))
        MAX-ACCESS read-only
        STATUS     current
        DESCRIPTION
            "The address of the local end of the peering session."
        ::= { jnxBgpM2PeerEntry 7 }

I tried it out and it works great overriding with InetAddressMissingSize.

modules:
  junos_bgp:
    walk:
    - jnxBgpM2PeerIndex
    overrides:
      jnxBgpM2PeerLocalAddr:
        type: InetAddressMissingSize
      jnxBgpM2PeerRemoteAddr:
        type: InetAddressMissingSize

[SuperQ]

From RFC 4001 section 4.1

4.1.  Table Indexing

   When a generic Internet address is used as an index, both the
   InetAddressType and InetAddress objects MUST be used.  The
   InetAddressType object MUST be listed before the InetAddress object
   in the INDEX clause.

Interestingly, it seems like the MIB (BGP4-V2-MIB-JUNIPER) has the correct INDEX syntax.

    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 }

[brian-brazil]

I tried it out and it works great overriding with InetAddressMissingSize.

That's the one.

From RFC 4001 section 4.1

It's the 2nd paragraph, the device is violating the RFC by not sending the number of octets. This is a bug which should be reported to the vendor.

[SuperQ]

Instance sub-identifiers are then of the form T.N.O1.O2...On, where T is the value of the InetAddressType object, O1...On are the octets in the InetAddress object, and N is the number of those octets.

Oh, I see, yes, the IP entries are missing the "N" length field.

[isodude]

It's reported to vendor.

[brian-brazil]

Closing as there's nothing for us to do here, and we already have a workaround for this class of vendor bug.