Georg's Log

Wed 14 December 2016

Link Layer Discovery Protocol

Posted by Georg Sauthoff in network   

The Link Layer Discovery Protocol (LLDP) probably isn't the most popular protocol but it can be useful for troubleshooting purposes and for mapping the neighbourhood of a host.

Its purpose is basically to send/receive key/value pairs that are of general interest. For example the switch port number the host is connected to or the ethernet interface auto-negotiation capabilities of another host. The switch port number can be handy e.g. for identifying a cable that has to be connected elsewhere.

Getting Started

The Open LLDP software is included in the base repositories of several distributions, e.g. Fedora and CentOS/RHEL.

For example, to install it on Fedora:

dnf install lldpad

Open LLDP provides a daemon and client utilities. The daemon is able to broadcast LLDP messages and is also responsible to passively collect LLDP messages broadcasted by neighbouring hosts. Thus, the daemon must be started before executing any client utility:

systemctl start lldpad.service

In the following, all interface specific commands use the iface shell variable. With modern interface naming it may have an assignment similar to:


By default, the LLDP daemon doesn't collect nor send anything. This can be verified via (as root):

lldptool -i $iface get-lldp adminStatus

To enable the passive LLDP message collection:

lldptool -i $iface set-lldp adminStatus=rx

Note that settings changed via lldptool are persistent.

If the ethernet neighbourhood has some LLDP enabled device the

lldptool -i $iface stats

command should display an increasing received count, e.g.:

Total Frames Transmitted        = 0
Total Discarded Frames Received = 0
Total Error Frames Received     = 0
Total Frames Received           = 426
Total Discarded TLVs            = 0
Total Unrecognized TLVs         = 0
Total Ageouts                   = 0

Display the actual LDLP messages, recently collected:

lldptool -i $iface get-tlv -n


Since it is a link layer protocol, the LLDP neighbourhood basically is the broadcast domain, excluding parts that are behind bridges.

Also, LLDP messages that are sent by a switch and contain the port number are just sent to one port - for obvious reasons.

Active LLDP

Enabling the broadcasting of LLDP messages on a Linux host with active Open LLDP daemon is as simple as:

lldptool -i $iface set-lldp adminStatus=rxtx

The set of default LLDP key/values that are sent by default can be locally displayed and verified via:

lldptool -i $iface get-tlv

(note the missing -n switch)

Of course, the same key/values should also be displayed when executing

lldptool -i $iface get-tlv -n

on a neighbouring host.

LLDP defines several key/value pairs that aren't enabled, by default. The help output, i.e. lldptool -h contains a list of what is available (see also the man page).

To enable the broadcasting of some more LLDP key/value pairs:

for i in sysName sysDesc sysCap portDesc mngAddr macPhyCfg ; do
  lldptool -i $iface set-tlv -V $i  enableTx=yes

As always, those changes are persistent.


I tested LLDP in different networks and LLDP isn't spoken by everyone. For example, a consumer level TP switch, a AVM FritzBox and a medium Kyocera network printer all don't support LLDP. That means they don't broadcast any LLDP messages by default and they also don't claim LLDP support that could be enabled.

An example of a LLDP message broadcasted by a CentOS 7 system running Open LLDP - as displayed by lldptool -i $iface get-tlv -n:

Chassis ID TLV
        MAC: 01:23:45:67:89:ab
        MAC: 01:23:45:67:89:ab
Time to Live TLV
Port Description TLV
        Interface   2 as eno1
System Name TLV
System Description TLV
        Linux 3.10.0-514.2.2.el7.x86_64 #1 SMP Tue Dec 6 23:06:41 UTC 2016 x86_64
System Capabilities TLV
        System capabilities:  Station Only
        Enabled capabilities: Station Only
Management Address TLV
        Ifindex: 2
MAC/PHY Configuration Status TLV
        Auto-negotiation supported and enabled
        PMD auto-negotiation capabilities: 0x8037
        MAU type: 1000 BaseTFD
Maximum Frame Size TLV

Beside many other things, the output shows that the ethernet interface of that host supports 1 GBit ethernet (full duplex) and has auto-negotiation enabled.

An example of LLDP message generated by a switch in a datacenter environment:

Chassis ID TLV
        MAC: 00:11:23:aa:bb:cc
        Local: 14
Time to Live TLV
Port Description TLV
System Name TLV
        Externes Netz 2.3.1
System Description TLV
        ProCurve J4900B Switch 2626, revision H.10.119, ROM H.08.02 (/sw/code/build/fish)
System Capabilities TLV
        System capabilities:  Bridge, Router
        Enabled capabilities: Bridge
Management Address TLV
        MAC: 00:11:23:aa:bb:cc
        Ifindex: 0
MAC/PHY Configuration Status TLV
        Auto-negotiation supported and enabled
        PMD auto-negotiation capabilities: 0x6c00
        MAU type: 100 BaseTXFD

One can see that the switch just supports 100 MBit ethernet and thus must be quite old. A quick web search confirms this. It also reveals that this switch has installed the latest available firmware. The host that executed the lldptool query is connected to switch port 14.