LLDP peer node recognition FQDN vs. host name

[user54119]

We have the following situation on a Cisco Switch ('switch1', LLDP enabled):

switch1 Port1:
Connected to a second switch ('switch2') by a VLAN trunk port.
In Object Details of switch1 I can see on interface tab for Port1 peer node 'switch2.domain.com', peer discovery protocol is LLDP.
In Tools - Info - Topology Table (LLDP) on switch1 I can see as system name of the peer 'switch2'.
So everything is fine here

switch1 Port2:
Connected to an WLAN AP ('ap1') by a VLAN trunk port.
In Object Details of switch1 I can see no peer node on interface tab for Port2.
In Tools - Info - Topology Table (LLDP) on switch1 I can see as system name of the peer 'ap1.domain.com'.
Is it possible that NetXMS cannot recognition the peer if it sends FQDN instead of pure hostname?
What is the standard for LLDP system name?

[victor]

Hi,

actually, LLDP is quite flexible in what is used to identify node - every peer sends it's identification along with ID type. It can be MAC address, host name, interface name, etc.). Can you please share results of SNMP walk on OID .1.0.8802.1.1.2.1.4.1.1 on switch1 as well as .1.0.8802.1.1.2.1.3 for ap1?

Best regards,
Victor

[user54119]

Hi Victor

switch1 SNMP walk on OID .1.0.8802.1.1.2.1.4.1.1:

.1.0.8802.1.1.2.1.4.1.1.4.0.50.1 [INTEGER] = 4
.1.0.8802.1.1.2.1.4.1.1.4.0.57.2 [INTEGER] = 4
.1.0.8802.1.1.2.1.4.1.1.4.0.58.3 [INTEGER] = 4
.1.0.8802.1.1.2.1.4.1.1.5.0.50.1 [Hex-STRING] = FC AA AA AA 7C 08
.1.0.8802.1.1.2.1.4.1.1.5.0.57.2 [STRING] = °²Üo/4
.1.0.8802.1.1.2.1.4.1.1.5.0.58.3 [Hex-STRING] = 10 AA AA AA CA 4E
.1.0.8802.1.1.2.1.4.1.1.6.0.50.1 [INTEGER] = 7
.1.0.8802.1.1.2.1.4.1.1.6.0.57.2 [INTEGER] = 7
.1.0.8802.1.1.2.1.4.1.1.6.0.58.3 [INTEGER] = 7
.1.0.8802.1.1.2.1.4.1.1.7.0.50.1 [STRING] = 8
.1.0.8802.1.1.2.1.4.1.1.7.0.57.2 [STRING] = 1
.1.0.8802.1.1.2.1.4.1.1.7.0.58.3 [STRING] = 3
.1.0.8802.1.1.2.1.4.1.1.8.0.50.1 [STRING] = Uplink
.1.0.8802.1.1.2.1.4.1.1.8.0.57.2 [STRING] = lan
.1.0.8802.1.1.2.1.4.1.1.8.0.58.3 [STRING] = lan1
.1.0.8802.1.1.2.1.4.1.1.9.0.50.1 [STRING] = switch2
.1.0.8802.1.1.2.1.4.1.1.9.0.57.2 [STRING] = ap1.domain.com
.1.0.8802.1.1.2.1.4.1.1.9.0.58.3 [STRING] = gw1.domain.com
.1.0.8802.1.1.2.1.4.1.1.10.0.50.1 [STRING] = Switch2-Type
.1.0.8802.1.1.2.1.4.1.1.10.0.57.2 [STRING] = Linux
.1.0.8802.1.1.2.1.4.1.1.10.0.58.3 [STRING] = Gateway-Type
.1.0.8802.1.1.2.1.4.1.1.11.0.50.1 [STRING] =
.1.0.8802.1.1.2.1.4.1.1.11.0.57.2 [STRING] = 8
.1.0.8802.1.1.2.1.4.1.1.11.0.58.3 [STRING] = 8
.1.0.8802.1.1.2.1.4.1.1.12.0.50.1 [STRING] =
.1.0.8802.1.1.2.1.4.1.1.12.0.57.2 [STRING] = 8
.1.0.8802.1.1.2.1.4.1.1.12.0.58.3 [Hex-STRING] = 08 00

ap1 SNMP walk on OID .1.0.8802.1.1.2.1.3:
nothing. This device maybe does not support this OIDs for LLDP.

kind regards
Dani

[victor]

Hi,

that's likely a problem. Currently NetXMS can only build topology if both peers provide LLDP information via SNMP. In this particular case ap1 reports that it identify itself using MAC address (.1.0.8802.1.1.2.1.4.1.1.4.0.57.2 = 4), but because it does not provide own LLDP ID via SNMP NetXMS cannot find node with this LLDP ID. I can add a fallback search using remote system name (.1.0.8802.1.1.2.1.4.1.1.9) - it may cause inconsistent results though if for example few nodes have identical system names.

Best regards,
Victor

[user54119]

Hi Victor

Thanks for the explanations. I started a feature request at the manufacturer of these devices (access points), but that can take very long.
It would be good to add a fallback by system name. Normally NetXMS will find node by ID and only if not the name would be second chance. Can you implement this for V2.0-RC1?

thanks
Dani

[victor]

I'll implemented it in 2.0-RC1 - change should be quite easy.

Best regards,
Victor

[user54119]

thanks!!!!

[user54119]

Hi Victor

Have you implemented this in V2.0-RC1? I just updated but cannot see any change.

thanks
Dani

[victor]

Hi,

sorry, I'm completely forgot about this. Now I'll add a change request (https://dev.raden.solutions/issues/883) so I won't forget to implement it in RC2.

Best regards,
Victor