Stoatwblr
commented
8 years ago -------- Forwarded Message --------
Subject: Re: RE: NEW SR 152955 - SR 152952 - UK -UCL -Network - CE5850- v100r003SPH008 patch faulty? Date: Mon, 26 Oct 2015 12:55:41 -0400 From: Bill Fenner fenner@gmail.com<mailto:fenner@gmail.com> To: Alan Brown a.brown@ucl.ac.uk<mailto:a.brown@ucl.ac.uk> CC: Jeroen van Ingen j.vaningenschenau@utwente.nl<mailto:j.vaningenschenau@utwente.nl>, Oliver Gorwitsoliver@cpan.org<mailto:oliver@cpan.org>
Hi Alan,
As we've discovered, the problematic ports correspond to missing entries in the BRIDGE-MIB::dot1dBasePortIfIndex. To understand why this makes sense, look at the definition of the LldpPortNumber:
LldpPortNumber ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "Each port contained in the chassis (that is known to the LLDP agent) is uniquely identified by a port number.
A port number has no mandatory relationship to an
InterfaceIndex object (of the interfaces MIB, IETF RFC 2863).
If the LLDP agent is a IEEE 802.1D, IEEE 802.1Q bridge, the
LldpPortNumber will have the same value as the dot1dBasePort
object (defined in IETF RFC 1493) associated corresponding
bridge port. If the system hosting LLDP agent is not an
IEEE 802.1D or an IEEE 802.1Q bridge, the LldpPortNumber
will have the same value as the corresponding interface's
InterfaceIndex object.
Port numbers should be in the range of 1 and 4096 since a
particular port is also represented by the corresponding
port number bit in LldpPortList."
SYNTAX Integer32(1..4096)Your walk of dot1dBasePortIfIndex starts at the value 3:
BRIDGE-MIB::dot1dBasePortIfIndex.3 = INTEGER: 7 BRIDGE-MIB::dot1dBasePortIfIndex.4 = INTEGER: 8 BRIDGE-MIB::dot1dBasePortIfIndex.5 = INTEGER: 9
and the problem interfaces that are neighbors with 40G ports have LldpPortNumber values of 1 and 2:
LLDP-MIB::lldpRemPortId.104679184.1.1 = STRING: "40GE2/0/1" LLDP-MIB::lldpRemPortId.104679184.2.1 = STRING: "40GE2/0/2"
Since there is no entry in dot1dBasePortIfIndex for values 1 or 2, the manager has no choice but to treat them as ifIndex values, thus assigning the neighbors to your "NULL0" and "InLoopBack0" interfaces.
Netdisco's algorithm is slightly different: it uses the values of lldpLocPortDesc to find the name of the port, and then inverts that value into an interface index. This explains why Netdisco (really SNMP::Info) is working yet your other tool (GLPI) is not, and yet they are both behaving reasonably.
Bill
Several problems, probably all related.
Firstly, Huawei switches don't enumerate ports from 0 and they don't necessarily run contiguously (ie, there are holes in the numbering sequence). This was analysed by netdisco developers and that analysis mailed to dduriex late in 2015. (MIBwalks already submitted)
Secondly: Fusion is not detecting/enmuerating VLANs correctly
Thirdly: Devices whose macs are already registered in GLPI are being re-detected and added in again as "unmanaged devices" - mostly these are ports on the Huawei switches and show up as "hub", although some have more details available (but they should be joined to the switch they are part of, not pulled in as standalone items)