Looks like you need to follow the devices that are directly connected to the port where you see this traffic.
LLDP capable switches are expected to not forward LLDP traffic, but non-LLDP capable switches (or switches that were designed to or have a software issue) can forward LLDP as it's just ethernet frames and they need to be actively dropped (or consumed) on switches. Check this (old) piece of documentation where you see that for CDP the behavior is what you see for LLDP. If you search, you can also find references to very small switches, like in IP Phones, that just forward the LLDP.
Next step would be to find out which device is forwarding the LLDP, so 'follow the path'. Then check on that device why it is forwarding the LLDP.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check
https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
------------------------------
Original Message:
Sent: Feb 10, 2023 03:13 PM
From: cgeorge
Subject: LLDP info seen beyond the neighbouring switch
Thanks, Thomas.
Definitely not a loop or shortcut. I did a pcap and see that there is a difference between the proper lldp packets and error packets:
The top packet (expected) is the adjacent core switch and the bottom (unexpected) shows up as multi-hop lldp record from a device on the other side of the core.
Like you said, the normal packet is sent to mcast destination MAC=01:80:c2:00:00:0e.
Bad lldp packet is sent to mcast destination MAC=01:80:c2:00:00:00 which is a valid LLDP OR STP destination. If used with lldp then type field=0x88cc, if used with STP then type field=0x0802. Both packets above are showing type field=0x88cc.
Example:
Good--
Bad--
Is this a problem with the source device or the switch forwarding the packet? We do not use STP so these packets should not be forwarded beyond first hop.
Thanks for the help!
Original Message:
Sent: Feb 10, 2023 02:02 AM
From: thomasbnc
Subject: LLDP info seen beyond the neighbouring switch
Hi
well, my first thought is that you may have something like a loop or a shortcut in your network you may not be aware of. LLDP communication uses multicast address 01:80:C2:00:00:0E. So receiving those frames coming from devices multiple hops away must have something to do with the replication of this traffic towards the port connected to K1.
So maybe you want to investigate on 6405-OL / 6405-OM whether something is configured to forward L2 multicast traffic to the core.
Regards,
Thomas
Original Message:
Sent: Feb 08, 2023 03:27 PM
From: cgeorge
Subject: LLDP info seen beyond the neighbouring switch
Hello,
I am having a problem with the lldp tables of distribution/edge switches showing information that is more than one hop away. It is a campus network with 2x 6405 cores with a VSX link. The distribution switches of various buildings each have trunk legs into each of the cores. On any of the distribution switches I am seeing lldp information from devices that are connected multiple hops away instead of only the adjacent port.
Simplified topology:
dist.switch1 >> core1-6405/core2-6405 << dist.switch2 << device (ex.printer1)
In this case, dist.switch1 would see lldp records on the switch/core trunk from printer1--often more than two hops.
Example of LLDP INFO REMOTE command from distswitch1 (K1/K2 are part of a trunk with legs to each core):
Note--bold is expected, italic should not be seen
K1 | b4 a4 e7 69 xx xx 1/5/33 54-OM1... 6405-OL
K1 | STAFF-TEST 74 ...
K1 | S170-17VR111 a4 ...
K1 | S275-02 b0 ...
...
K2 | b4 a4 e7 xx xx xx 1/5/6 54-OM1... 6405-OM
K2 | FLATPANEL-04 6c ...
K2 | AE319A-S4G417 e8 ...
K2 | S266-07 a4 ...
All entries (except for the first 6405-xx) are from devices 2-5 hops away. Aruba support seems to believe it may have something to do with spanning tree. We do not have spanning tree enabled on the edge switches. On the core 6405's we have RPVST enable but not in use:
Spanning tree status : Enabled Protocol: RPVST
Extended System-id : Enabled
Ignore PVID Inconsistency : Disabled
Path cost method : Long
RPVST-MSTP Interconnect VLAN : 1
Current Virtual Ports Count : 0
Maximum Allowed Virtual Ports : 2048
No STP instance present.
Any ideas what may be causing this? I cannot trace this to a specific event as it started many months ago.