[j-nsp] OSPFv3 monitoring using SNMP
bellman at nsc.liu.se
Fri Jun 8 04:23:02 EDT 2018
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
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
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
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...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the juniper-nsp