cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
850
Views
0
Helpful
2
Replies

LLDP Implementation Woes

al_whaley
Level 1
Level 1

To me, the Cisco implementation of LLDP seems extremely broken.  I would love to find out I’m wrong and there is a way to use it effectively.  However so far my experience is as follows below.  This is all on the SG300, SG350, SG350X and similar series.

What I believe the world wants is to be able to receive, in a network node (e.g. server or other) connected to a Cisco switch port, is any LLDP packets that come it’s way.  That way every node can hear LLDP packets from other nodes on the same LAN.  That *IS* the entire point of LLDP.

However the Cisco implementation allows the user to either “enable” LLDP, stopping LLDP packets from transiting the switch, eating all LLDP packets for the switch’s own consumption and not allowing any nodes access to them, or one can “disable” LLDP but turn on “Flooding” which causes two other problems.  The first problem with flooding is that one cannot then be aware of the switch itself as it will refuse to participate in LLDP in any way.  The other problem, is that two switches connected via LAG (multiple Ethernet trunks) flood things back and forth over multiple paths and cause a packet storm.  Because the Cisco implementation disables port configuration in the “disable” mode, it’s not possible to turn off some of the LAG trunks to get around this part of the problems.

What the world really wants is to be able to have LLDP enabled, but be able to specify that LLDP information is not blocked, instead both received but also passed on so that the switch accumulates neighbor information but allows other nodes to also be aware of LLDP packets, and that furthermore the flooding information as well as the switch’s own transmissions for itself only be sent on one LAG trunk connection (duh!).

I have attempted to make a crude attempt to gather information from switches that are in the “enable” mode by having a server daemon log into various switches and acquire the LLDP neighbor information only to find that it isn’t possible to get it in a good format.  If a server daemon sends IOS commands and gathers “screen” output, it ends up in a multi-line mess.  This isn’t the preferred solution anyway.

Can anyone suggest a better way?  Is Cisco planning any fixes?

2 Replies 2

Joseph W. Doherty
Hall of Fame
Hall of Fame

Cannot speak on Cisco plans, but I'll note several years ago had some "woes" with LLDP PoE phones (non-Cisco) having issues working connected to some 3750 switches.  Problems resolved by updating IOS on those devices.  Such a case is where service contracts and TAC are very helpful/important.

If not running latest "recommended" IOS for your SG switches (assuming Cisco has such recommendations), you might see if that helps at all.

Thanks for the reply.  Sadly this appears to be a longstanding-since-inception approach that appears to have been deliberately taken by Cisco and is rather ignorant about the purpose of sharing information amongst LLDP peers.  Cisco devices gobble up all the LLDP data and don't share it.  

 

And yes, everything is up to date.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco