[j-nsp] OSPFv3 monitoring using SNMP

[Thomas Bellman]

I'm trying to understand the SNMP information my Junipers give
me for OSPF v3, specifically the indices for ospfv3NbrTable and
ospfv3IfTable.  (I want to write a Nagios plugin for checking
OSPFv3 neighbours.)

RFC 5643 says that there is an interface index in there, e.g. in the
ospfv3NbrTable the index includes ospfv3NbrIfIndex.  According to
section 2.1, those references the "IPv6 Interface Table", which
ought to be IP-MIB::ipv6InterfaceTable (defined in RFC 4293).  Junos
doesn't seem to implement that, though, and instead implements RFC
2465, where we instead have IPV6-MIB::ipv6IfTable.

IPV6-MIB::ipv6IfTable contains the column ipv6IfLowerLayer, which
points directly into IF-MIB::ifTable.

However, the data that I get from my Junipers don't match this:

   $ snmptable -Ci -v2c -c... lo-nsc5 OSPFV3-MIB::ospfv3NbrTable
   SNMP table: OSPFV3-MIB::ospfv3NbrTable

             index  ospfv3NbrAddressType  ospfv3NbrAddress  [...]
    2.0.2196529913                  ipv6  [...]
    6.0.2196507131                  ipv6  [...]
    7.0.2196507132                  ipv6  [...]
    8.0.2196529907                  ipv6  [...]
    9.0.2196529910                  ipv6  [...]
   10.0.2196529911                  ipv6  [...]
   11.0.2196529908                  ipv6  [...]
   13.0.2196529909                  ipv6  [...]

The index here is the three-tuple <interface,instance,router-id>.
Then looking at the ipv6IfTable:

   $ snmptable -Ci -v2c -c... lo-nsc5 IPV6-MIB::ipv6IfTable
   SNMP table: IPV6-MIB::ipv6IfTable

    index     ipv6IfDescr     ipv6IfLowerLayer ipv6IfEffectiveMtu   [...]
       16           lo0.0   IF-MIB::ifIndex.16  4294967295 octets   [...]
      511     xe-0/0/25.0  IF-MIB::ifIndex.511        1500 octets   [...]
      512 pfe-0/0/0.16383  IF-MIB::ifIndex.512  4294967295 octets   [...]
      571         irb.121  IF-MIB::ifIndex.571        1500 octets   [...]
      650         irb.110  IF-MIB::ifIndex.650        1500 octets   [...]
      659         irb.101  IF-MIB::ifIndex.659        1500 octets   [...]
      662         lo0.104  IF-MIB::ifIndex.662  4294967295 octets   [...]
      664     xe-0/0/18.0  IF-MIB::ifIndex.664        1500 octets   [...]
      672     xe-0/0/16.0  IF-MIB::ifIndex.672        1500 octets   [...]
      675     et-0/0/48.1  IF-MIB::ifIndex.675        1500 octets   [...]
      678   et-0/0/48.104  IF-MIB::ifIndex.678        1500 octets   [...]
      680         irb.103  IF-MIB::ifIndex.680        1500 octets   [...]
      686    ge-0/0/30.23  IF-MIB::ifIndex.686        1500 octets   [...]
      694    xe-0/0/4.104  IF-MIB::ifIndex.694        1500 octets   [...]
      698    xe-0/0/5.104  IF-MIB::ifIndex.698        1500 octets   [...]
      702     xe-0/0/12.1  IF-MIB::ifIndex.702        1500 octets   [...]
      719      xe-0/0/1.1  IF-MIB::ifIndex.719        1500 octets   [...]
      721      xe-0/0/0.1  IF-MIB::ifIndex.721        1500 octets   [...]

It doesn't have the any interface with index 2, 6, 7 and so on.
For a short while, I thought that those numbers where *positions*
in ipv6IfTable, but that doesn't match either; e.g. neighbour
6.0.2196507131 actually is on the other end of xe-0/0/0.1 (the
last entry in ipv6IfTable), while 7.0.2196507132 is on the other
end of xe-0/0/1.1 (the second to last entry in ipv6IfTable).

Our HP ProCurve and HPE FlexFabric switches don't behave like this.
The interface indices in ospfv3NbrTable and ospfv3IfTable matches
the indices in ipv6InterfaceTable, which matches the indices in
ifTable.

Am I totally misunderstanding the OSPFv3 MIB, or is the Junos
implementation broken?  Does Junos have some other SNMP table I
should look in to be able to map neighbours to interfaces?

(I see the same behaviour on Junos 17.2R1.13, 17.3R1-S3 and
18.1R1.9.)


-- 
Thomas Bellman,  National Supercomputer Centre,  Linköping Univ., Sweden
"Life IS pain, highness.  Anyone who tells   !  bellman @ nsc . liu . se
 differently is selling something."          !  Make Love -- Nicht Wahr!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20180608/1bd7ef13/attachment-0001.sig>