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!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp