Bug in LLDP remote port lookup

Tags: #<Tag:0x00007fec7f6e46f0> #<Tag:0x00007fec7f6e4600> #<Tag:0x00007fec7f6e44e8>

Sometimes in the neighbours view of a device the remote port column appears to be linked incorrectly (i.e. to a completely different port to the one reported by the device CLI or indeed SNMP itself).

I figure this is because in discovery-protocols.inc.php you are using the lldpRemPortDesc as a key to look up the port in the database, as well as the lldpRemPortId. On most of the switches I have access for testing (Cisco, HP Comware) the lldpRemPortDesc will return the user-defined description/alias for a port if one is set, and the real port name if it is not. This means it has the potential to not be unique on the device or be set to something misleading depending on what the user has configured.

In functions.inc.php find_port_id() you seem to be using this (the description) as the primary first-choice way of looking up a port (rather than preferring the identifier) for some reason, so it is susceptible to returning incorrect port IDs depending on how people have configured their port descriptions, particularly if many ports on the switch have the same description.

If I comment out the if ($description) { ... } block in find_port_id everything starts to behave properly. Perhaps there’s a good reason for doing it the order you have but please have a look and potential revisit of this code.

I confirm bug:
On web


In the DB

xe-4/2/9 and xe10/2/9 have the same description

Thinking out loud: from looking at my devices (Cisco, Aruba, HP), I think the primary means of port association should probably be: lldpRemPortId = ifName.

  • lldpRemPortDesc pretty much always returns the ifAlias of the far end, which might not be unique as discussed above.

  • ifDesc is usually the same as ifName except on Cisco where ifName is abbreviated (e.g. Te1/1/1) and ifDescr is full (e.g. TenGigabitEthernet1/1/1).

  • lldpRemPortId usually seems to return the ifName of the far end, which should be unambiguous. So I would go for this as the first choice port association method, falling back to some of the other more questionable methods if this doesn’t match anything.

I’ll try to patch includes/discovery/functions.inc.php find_port_id function to achieve this but might end up inadvertently breaking CDP or other non-standard LLDP MIBs that call this function from discovery-protocols.inc.php as I don’t have much of a way to test those.

1 Like

Please look at my post that is related.

Can you check on your gear and see if the SNMP lldpLocPortId matches the lldpRemPortId of the connected switch. If so, the method I am looking at writing might just fix your problems as well.

The PR I created for this is:

See if it fixes your issues.