Wired Intelligent Edge

 View Only
last person joined: 5 hours ago 

Bring performance and reliability to your network with the Aruba Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of the ArubaOS-Switch and ArubaOS-CX devices, and find ways to improve security across your network to bring together a mobile first solution.
Expand all | Collapse all

LLDP info seen beyond the neighbouring switch

This thread has been viewed 27 times
  • 1.  LLDP info seen beyond the neighbouring switch

    Posted Feb 08, 2023 03:42 PM
    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.


  • 2.  RE: LLDP info seen beyond the neighbouring switch

    Posted Feb 10, 2023 02:03 AM

    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




  • 3.  RE: LLDP info seen beyond the neighbouring switch

    Posted Feb 10, 2023 03:14 PM

    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!




  • 4.  RE: LLDP info seen beyond the neighbouring switch

    EMPLOYEE
    Posted Feb 14, 2023 05:19 AM

    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.
    ------------------------------



  • 5.  RE: LLDP info seen beyond the neighbouring switch

    Posted Feb 23, 2023 03:29 PM

    Thanks for the reply and insight, Herman.

    We have seen the LLDP pollution affect multiple switches and multiple devices (PCs, printers, etc.) are showing up in LLDP tables multiple hops away.  It is unlikely that it is the end devices due to diversity of devices and switches.  All devices are connected to LLDP enabled Aruba/HP switches. As you said, this traffic should not be forwarded beyond the local switch.  Aruba support has acknowledged that this is behaviour is incorrect and working on a resolution.

    Any other Network admins seeing the same problem?