I sincerely need your help troubleshooting abnormal PeerNode recognition on Huawei S16808 switches. Screenshots of network topology and device links in NetXMS are attached.
Below are nxsnmpwalk commands and outputs against the Huawei private OID on both switches:
plaintext
root@XMNMS01:~# /usr/bin/nxsnmpwalk -v 2c -c stonewell2000 10.61.99.2 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2
huaweiDatacomm.42.4.1.19.1.2.0 [Hex-STRING]: 00 00 AC 5E 14 7F 89 01

root@XMNMS01:~# /usr/bin/nxsnmpwalk -v 2c -c stonewell2000 10.61.99.3 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2
huaweiDatacomm.42.4.1.19.1.2.0 [Hex-STRING]: 00 00 AC 5E 14 7F 89 01
Could you please help identify the root cause and advise a fix? Many thanks.

The identical value on both switches is expected, not the fault. 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2 is hwMstpiBridgeID, and under V-STP the M-LAG pair presents itself as one logical bridge, so both chassis report the same bridge ID. In your case that ID (AC:5E:14:7F:89:01) is xA's own dot1dBaseBridgeAddress, which you can see in xA's Hardware Inventory tab.

NetXMS reads that OID specifically to handle this - see https://github.com/netxms/netxms/issues/3353, fixed in 6.2.0. Without it, STP discovery invents a link to the M-LAG peer on every downstream port. Which server version are you running? If it is older than 6.2.0, upgrade first and re-run a configuration poll plus a topology poll on both switches.

The peer-link and keepalive links in your screenshots look correct: the six Eth-Trunk0 members (40GE5/0/34-35, 40GE6/0/34-35, 40GE7/0/34-35) and 10GE4/0/47 all resolve to the right peer and match your diagram. Two other things do look wrong, and neither can come from STP discovery:

1. On both switches, MEth0/0/0 and 10GE2/0/1 list the switch itself as peer node, pointing at each other. STP discovery cannot produce a self-link - it skips a bridge that resolves to the local node.

2. 40GE6/0/6-9 on xA linked to 10GE4/0/42-45 on xB. These ports are DOWN/Disabled, and a down port has no forwarding or blocking STP state, so STP would not report them. They are also absent from your diagram.

Could you widen the Interfaces table and show the "Peer discovery protocol" column? It is cut off in both screenshots, and it is the one field that tells me which discovery source created these links (STP, LLDP, CDP, or FDB). Also confirm whether 40GE6/0/6-9 were ever cabled to xB - if they were, these may just be stale cached links.

Thank you for your help! I found that the peer node information on both devices failed to fully auto-update to the latest timestamp. I have manually deleted all port entries with a Peer Last Updated timestamp from half a month ago on the two devices, then re-run the configuration polling operation with reset. Please refer to the attachment for the current running status of the devices; could you help analyze this issue and advise a solution?

To clarify, with what exactly version are the screenshots?

My apologies, I overlooked that. The version of NetXMS is 6.2.1.

Thanks — the new data makes this clear. Everything on both switches is now discovered via LLDP, all six Eth-Trunk0 members and the 10GE4/0/47 keepalive resolve correctly in both directions, and the links on the down ports did not come back. Those were stale entries: NetXMS keeps unconfirmed peer information for Objects.Interfaces.PeerRetentionTime days (default 30) before removing it automatically, so your ~2-week-old entries were still within the retention window. You can lower that server configuration parameter if you want faster expiry.

The remaining MEth0/0/0 <-> 10GE2/0/1 "self" link is reported by the switches themselves, not invented by NetXMS. Your other links prove the two chassis advertise distinct LLDP chassis IDs, so the only way this entry can appear is that each switch sees its own LLDP frames back on those two ports. Check on the switch directly: display lldp neighbor interface 10ge 2/0/1 — if it lists the switch itself as neighbor, the loop is physical: either MEth0/0/0 is patched into 10GE2/0/1 on the same chassis (in-band management), or both ports connect to an unmanaged management switch that floods LLDP between them. To check from the NetXMS server side, please walk the full LLDP remote table on both switches and post the output here (or send them to me privately):

nxsnmpwalk -v 2c -c <community> 10.61.99.2 1.0.8802.1.1.2.1.4.1.1
nxsnmpwalk -v 2c -c <community> 10.61.99.3 1.0.8802.1.1.2.1.4.1.1

If the cabling is intentional, the displayed link is correct and can be ignored; disabling LLDP on MEth0/0/0 would also suppress it.

Thank you very much. The physical topology is shown in the figure. There is no physical link between MEth0/0/0 and 10GE2/0/1. The SNMP logs have been uploaded. Could you please help analyze and provide guidance? I would highly appreciate your support!

The walks confirm it, and both chassis behave identically. xA hears its own chassis ID (AC:5E:14:7F:89:01) on local ports 1 and 123; xB hears its own (AC:5E:14:7F:74:01) on local ports 1 and 51. In each case one entry points at 10GE2/0/1 and the other at MEth0/0/0, so the two ports see each other. Everything else in both walks is clean - all six Eth-Trunk0 members, the 10GE4/0/47 keepalive and the downstream CE8865 / CE6857E / H3C links resolve correctly in both directions.

You are right that there is no cable between those two ports, and there doesn't need to be. LLDP only requires them to be in the same broadcast domain. Here's what's actually happening:

LLDP frames are sent to 01-80-C2-00-00-0E, which is nearest-bridge scope - a standards-compliant bridge consumes them and never forwards them. So whatever sits between MEth0/0/0 and 10GE2/0/1 either ignores that rule (unmanaged switch, media converter, patch through a passive device) or is explicitly configured to tunnel LLDP. Both ports having exactly one neighbour each - each other - rules out a managed LLDP-speaking switch in between, because then both would show that switch instead.

To pin down which one:

display lldp neighbor interface MEth0/0/0
display lldp neighbor interface 10GE2/0/1
display l2protocol-tunnel group-mac all          # LLDP tunneling configured?
reset lldp statistics interface 10GE2/0/1        # then re-check counters
display lldp statistics interface 10GE2/0/1      # frames still arriving = live path, not stale table

Also check the running config for l2protocol-tunnel lldp enable or link-protocol transport lldp anywhere on the management path.

Note: the description configured on 10GE2/0/1 reads TO_XM-GL-HX-xA_MEth0/0/0 on xA and TO_XM-GL-HX-xB_MEth0/0/0 on xB, which suggests this path was built deliberately. Descriptions go stale, so treat it as a hint rather than proof - but both chassis being labelled and behaving the same way makes an accident unlikely. Worth asking whoever cabled the management network.

If the path is intentional, the LLDP data is correct and the link can be ignored; disabling LLDP on MEth0/0/0 suppresses it.

Separately, NetXMS should not display a node as its own peer no matter what the device reports. STP discovery already filters this case, LLDP does not - that's a bug on our side, filed as https://github.com/netxms/netxms/issues/3439

Thank you very much.