LLDP Explained: Link Layer Discovery, LLDP-MED and What It Reveals

LLDP, the Link Layer Discovery Protocol, is the IEEE 802.1AB standard that lets a device on an Ethernet link announce its identity, port and capabilities to the device at the other end of the cable, and record what that neighbour announces back. It solves the "which switch port is this server on" problem for every vendor at once. The catch is that anything plugged into the port can read the same announcement, including software versions, model names and management addresses.

This post sits next to our other one protocol per post explainers for layer 2: how Ethernet switching works, 802.1X and EAP, MACsec, ARP and IPv6 Neighbor Discovery, VXLAN and EVPN and SNMP. Here we stay on LLDP itself: the frame format, LLDP-MED, what leaks, how to scope it, and how to read and control it on real systems.

Key takeaways

• LLDP is defined by IEEE 802.1AB. The 2016 edition (approved 29 January 2016, published 11 March 2016) carried two 2021 amendments and is now listed by the IEEE Standards Association as superseded by 802.1AB-2026, which the IEEE SA Standards Board approved on 25 September 2026.
• An LLDP frame uses EtherType 0x88CC and, by default, the destination MAC address 01:80:C2:00:00:0E, which standards conformant bridges do not forward. LLDP is a one hop, one way advertisement: no request, no reply, no handshake.
• Every LLDPDU carries four mandatory TLVs in a fixed order: Chassis ID, Port ID, Time To Live and End of LLDPDU. Optional TLVs add the system name, system description, port description, capabilities and management addresses.
• LLDP-MED (ANSI/TIA-1057, April 2006) adds TLVs for voice VLAN and QoS policy, Power over Ethernet negotiation, inventory (hardware, firmware and software revisions, serial number, manufacturer, model, asset ID) and location, including civic street addresses used for emergency calling.
• LLDP has no authentication and no encryption. Whatever a switch or host advertises is readable by any device on that port, and a device can claim to be anything.
• The safe pattern is: run LLDP on infrastructure links where you want topology data, run it receive only or with trimmed TLVs on server ports, and disable transmission (or at least LLDP-MED inventory) on user, guest and public facing ports.
• On Linux, lldpd with lldpcli, or systemd-networkd with networkctl lldp, shows neighbours. lldpd -k stops the kernel version from being advertised and lldpd -i stops LLDP-MED inventory TLVs.

What LLDP is and what problem it solves

Before LLDP, the question "which physical switch port is this machine plugged into" was answered by walking to the rack, by tracing cables, or by matching MAC address tables across switches. Several network equipment makers solved the problem inside their own product lines with proprietary discovery protocols, but those only worked when both ends of the cable came from the same maker.

IEEE 802.1AB, titled "Station and Media Access Control Connectivity Discovery", standardised the idea. The IEEE Standards Association page for the 2016 edition summarises the purpose: the document "defines a protocol and a set of managed objects that can be used for discovering the physical topology from adjacent stations in IEEE 802 LANs." The lldpd project puts it more plainly on its home page: "LLDP allows you to know exactly on which port is a server (and reciprocally)."

LLDP solves three practical problems:

1. Inventory. Each device learns the identity of every device directly attached to it. A network management system that polls those neighbour tables (over SNMP using the LLDP MIB, or over newer management interfaces using the YANG model added by the 802.1ABcu-2021 amendment) can assemble a full physical topology without anyone typing it in.
2. Troubleshooting. When a link fails, an engineer can see from either end what was supposed to be there: the neighbour's hostname, its port name and the VLAN it expects.
3. Automatic configuration. Extensions such as LLDP-MED let a switch tell an IP phone which voice VLAN and priority to use, and let the phone tell the switch how much Power over Ethernet it needs.

The protocol in one paragraph

An LLDP agent runs on each port. Every transmit interval it builds an LLDP Data Unit (LLDPDU), a sequence of Type Length Value (TLV) records, and sends it to a reserved multicast MAC address. The receiving agent stores the contents in a per port neighbour table and keeps each entry for the number of seconds given in the Time To Live TLV. If no new frame arrives before the TTL expires, the entry ages out. There is no acknowledgement and no session. LLDP is advertise only: a device never asks its neighbour for information, it simply publishes what it has chosen to publish and listens to what the neighbour publishes.

Where LLDP frames go

The Wireshark wiki entry for LLDP documents the transport details. LLDP normally rides directly on Ethernet with EtherType 0x88CC. On other IEEE 802 networks it can be carried in a SNAP header with the same EtherType. LLDPDUs are sent to the destination MAC address 01:80:C2:00:00:0E, which sits in the IEEE block reserved for protocols "constrained to an individual LAN", so an 802.1D conformant bridge will not forward it.

That scoping is configurable. The lldpcli manual page lists three agent types, each with its own destination address:

The practical consequence: in a normal switched network, an LLDP frame from your laptop reaches the access switch and nowhere else, and the frame the access switch sends reaches your laptop and nowhere else. Discovery is strictly between physical neighbours. That is also why LLDP is a good topology tool and a poor remote scanning tool: to read a port's LLDP you have to be on that link.

Timers and TTL

LLDP behaviour is governed by a few timers. The defaults below are the ones documented in the lldpcli manual page for lldpd, which follow the values commonly used by network equipment:

A TTL of zero has a special meaning: a device that is shutting down LLDP on a port can send a final frame with TTL 0 so the neighbour deletes its entry immediately rather than waiting for it to age out.

Inside an LLDPDU: mandatory and optional TLVs

Every piece of LLDP data is a TLV. The TLV header is two octets: a 7 bit type and a 9 bit length, which caps a single TLV value at 511 octets. Wireshark's LLDP dissector source encodes exactly that split, masking the top 7 bits (0xFE00) for the type and the low 9 bits (0x01FF) for the length. The whole LLDPDU has to fit inside one Ethernet frame, which is why the IEEE later added an amendment for multiframe PDUs when some TLV sets (for example detailed data centre bridging configurations) grew beyond that space.

The four mandatory TLVs

The Wireshark wiki summarises the rule from the standard: every compliant LLDPDU must contain at least these four TLVs, in this order.

Optional TLVs go between Time To Live and End of LLDPDU.

The Chassis ID and Port ID TLVs each carry a subtype octet. For the chassis, common subtypes are a MAC address (the most common choice on hosts), a network address, an interface name or a locally assigned string. For the port, common choices are the MAC address of the port, the interface name (for example eth0 or a switch's own port name) or a locally assigned value. The lldpd manual notes that by default lldpd uses the interface MAC address as the Port ID and the interface name as the port description, and that configure lldp portidsubtype ifname switches the Port ID to the interface name. Pairs of Chassis ID and Port ID are the key of a neighbour entry: a receiver identifies "the same neighbour" by that pair.

The optional basic TLVs

The rest of the basic set, again as listed in the Wireshark wiki entry:

The networkctl manual shows the capability flags as single letters: o for Other, p for Repeater, b for Bridge, w for WLAN Access Point, r for Router, t for Telephone, d for DOCSIS cable device, a for Station, c for Customer VLAN, s for Service VLAN and m for Two Port MAC Relay. Wireshark's field reference has a matching boolean for each, such as lldp.tlv.system_cap.router and lldp.tlv.system_cap.wlan_access_pt.

Organizationally specific TLVs

Type 127 is the extension point. An organizationally specific TLV starts with a 3 octet Organizationally Unique Identifier (OUI) and a 1 octet subtype, followed by the value. The Wireshark wiki lists the main publishers:

Because receivers skip TLVs they do not understand, one LLDPDU can carry the basic set plus several extension sets, and each receiver uses the parts it knows.

A worked example

Here is what a typical Linux server running lldpd with default settings advertises. Values are illustrative but the structure is exactly what lldpcli show chassis reports:

Chassis:
  ChassisID:    mac 52:54:00:12:34:56
  SysName:      db-07.prod.example.internal
  SysDescr:     Linux db-07 6.8.0-45-generic #45-Ubuntu SMP PREEMPT_DYNAMIC x86_64
  MgmtIP:       10.20.30.47
  MgmtIP:       fd00:20:30::47
  Capability:   Bridge, off
  Capability:   Router, off
  Capability:   Wlan, off
  Capability:   Station, on

Read it as an outsider would. The hostname tells you the role (a database), an environment (production) and the internal DNS suffix. The system description, which lldpd builds by default from the kernel name, node name, kernel version, build date and architecture, gives the exact kernel build and hints at the distribution. The management addresses give an IPv4 and an IPv6 address on the internal network. None of it is secret in the cryptographic sense, but together it is a useful head start for anyone mapping the network.

What LLDP-MED adds for phones and other endpoints

LLDP-MED, Link Layer Discovery Protocol for Media Endpoint Devices, is ANSI/TIA-1057, published by the Telecommunications Industry Association's TR-41 committee in April 2006. It is a set of organizationally specific TLVs under OUI 00-12-BB, aimed at IP phones, conference units, wireless access points and other endpoints that need the network to tell them how to behave.

Device classes

The lldpd manual, describing its -M option, lists the four LLDP-MED device classes the standard defines and notes that the class determines which TLVs a device must send:

The LLDP-MED TLVs

The Wireshark wiki lists the LLDP-MED TLV subtypes under OUI 00-12-BB:

The Wireshark display filter reference exposes these fields directly, for example lldp.media.vlan_id, lldp.media.dscp and lldp.media.app_type for network policy, lldp.media.power.value for power, lldp.media.civic.value and lldp.media.loc.latitude for location, and lldp.media.firmware, lldp.media.software, lldp.media.sn, lldp.media.manufacturer and lldp.media.model for inventory.

Network policy: the voice VLAN without DHCP tricks

The most common use of LLDP-MED is voice. A switch port is configured with a data VLAN for the computer that plugs into the back of the phone and a voice VLAN for the phone itself. The switch sends a Network Policy TLV that says, in effect, "for application type voice, tag your frames with VLAN 110, layer 2 priority 5 and DSCP 46". The phone applies those settings before it requests an address, so it lands on the right VLAN with the right QoS marking from the first packet.

Power

The Extended Power via MDI TLV lets a powered device and the switch agree on power more precisely than the coarse classes defined in the physical layer standard. The phone states its power type, source, priority and the wattage it needs; the switch can budget its Power over Ethernet supply port by port.

Inventory

The inventory TLVs exist so a network management system can learn the hardware revision, firmware revision, software revision, serial number, manufacturer, model and asset ID of every endpoint without logging into it. That is convenient for asset tracking. It is also, word for word, a list of the things an attacker most wants to know before choosing which known vulnerability to try.

The lldpd manual is explicit about the trade off. Its -i option disables LLDP-MED inventory TLV transmission, and the manual says to "use this option if you don't want to transmit sensitive information like serial numbers."

Location

The Location Identification TLV supports three formats: coordinates (latitude, longitude, altitude and datum), a civic address and an Emergency Location Identification Number. The lldpcli manual shows the coordinate syntax with an example port command, configure ports eth0 med location coordinate latitude 48.85667N longitude 2.2014E altitude 117.47 m datum WGS84, and supports civic address elements such as country, country subdivision, county, city, street, house number, floor and room. The civic elements look much like the civic location format the IETF defined for DHCP in RFC 4776 (November 2006), which covers country, administrative units such as states and cities, street addresses and building information. The purpose is emergency calling: an IP phone that learns "Building 2, floor 3, room 314" from its switch port can pass that location to the emergency service, which is why location is configured per port on access switches. The same feature means a switch port can tell any device plugged into it the street address and room it is in.

LLDP versus older vendor discovery protocols

Before 802.1AB, several network equipment makers built their own link layer discovery protocols. lldpd's documentation describes LLDP as "an industry standard protocol designed to supplant proprietary Link-Layer protocols" and says the goal is "an inter-vendor compatible mechanism". The Wireshark wiki adds that LLDP "was modeled on and borrowed concepts from" those protocols. lldpd itself can still speak four of the older single vendor protocols so that a Linux host can be seen by older gear, but each one has to be switched on explicitly with its own command line flag.

Why a standard matters for mixed fleets

Most real networks mix switch makers, server makers, phone makers and operating systems. With only proprietary protocols, a topology map has holes wherever two makers meet, and a Linux server or a hypervisor cannot describe itself to the switch at all. LLDP gives every device the same vocabulary, so a topology tool, a cabling check or an IP phone works the same way across makers. It also means one hardening policy ("which TLVs do we allow on which ports") can apply across the whole fleet.

One honest caveat: switching to LLDP does not make discovery safer. Both families send the same kind of information in clear text with no authentication. The win is consistency, not confidentiality. If older single vendor protocols are still enabled alongside LLDP, you are leaking the same data twice, so part of any hardening exercise is checking that the older protocols are switched off where you do not need them.

What LLDP reveals, and why it is a reconnaissance gift

Picture someone who has plugged a laptop into a meeting room wall port, or who controls one workstation. Without sending a packet, they can listen for 30 seconds and receive the switch's LLDP advertisement. Depending on configuration, that one frame can contain:

This is why network security guidance treats discovery protocols as an information disclosure issue. Reconnaissance is the first phase of most intrusions, and LLDP removes guesswork from it: the switch has already told the intruder what it is, which version it runs and where its management plane lives.

Conceptual attack patterns

These are well documented classes of abuse. We describe them conceptually; the defence for each is in the next section.

• Passive fingerprinting. Listening is enough. An attacker records the system description and maps the version to known vulnerabilities, then targets the management address.
• Voice VLAN hopping. Because the Network Policy TLV tells any device which VLAN carries voice, a non phone device can tag its frames with that VLAN and land on a network segment that usually has weaker filtering than the user data VLAN. Port based access control with 802.1X, and switch features that only admit a voice VLAN after authentication, close this gap.
• Spoofed neighbours. LLDP has no authentication, so any device can send an LLDPDU claiming to be anything. A spoofed frame can pollute topology maps, confuse automation that trusts LLDP data, or claim a power budget or phone class to obtain special treatment. Tools that consume LLDP should treat it as an unverified hint.
• Resource exhaustion. A flood of LLDPDUs with many distinct Chassis ID and Port ID pairs can fill neighbour tables. lldpd caps this with configure system max-neighbors, which its manual says defaults to 32 neighbours per protocol on each interface, and network operating systems usually have a similar per port limit.
• Parser bugs. LLDP parsers process attacker supplied TLVs on every port by default. lldpd publishes its own history on its security page: a buffer overflow when handling an oversized management address TLV (CVE-2015-8011, fixed in 0.7.19), a crash on a malformed management address (CVE-2015-8012, fixed in 0.7.19), memory exhaustion from LLDPDUs with duplicate port description, system name or system description TLVs (CVE-2020-27827, fixed across 1.0.8 and 1.0.9), and a heap overflow in parsing of an older vendor protocol (CVE-2021-43612, fixed in 1.0.13). The project notes its parser runs in an unprivileged, chrooted process, which is why none of these allowed arbitrary code execution under default hardening. The lesson generalises: the code that parses LLDP is attack surface on every port, so keep it patched, and prefer implementations that isolate parsing.

What hosts reveal, not just switches

It is easy to think of LLDP as a switch feature. But the lldpd manual is clear that, by default, a Linux host running lldpd advertises a system description made of "the kernel name, the node name, the kernel version, the build date and the architecture", plus its first IPv4 and IPv6 addresses as management addresses. A hypervisor, a storage appliance or a server management controller may do the same. In a shared data centre or a colocation cage, that information goes to whoever operates the switch at the other end, which may not be you.

How to scope LLDP safely

The right answer is rarely "turn LLDP off everywhere". Infrastructure teams rely on it for topology, phones rely on LLDP-MED, and server automation uses it to validate cabling. The right answer is to decide per port class what to send and what to accept.

A per port policy

Controls to look for on network equipment

Network operating systems from different makers use different command syntax, but nearly all of them expose the same set of controls, because they map to objects in the standard's managed object model. Look for:

• A global enable and disable, plus per interface transmit and receive switches. Turning off transmit on access ports while leaving receive on is a common middle ground.
• Per TLV selection, so you can stop sending System Description, Management Address or VLAN names on some ports while still sending Chassis ID and Port ID.
• Separate LLDP-MED controls, so voice ports can send network policy and power without inventory or location, and non voice ports send no LLDP-MED at all.
• Neighbour limits per port to bound table growth.
• Logging and SNMP notifications on neighbour changes, which can alert you when an unexpected device (for example a small unmanaged switch with LLDP, or a device claiming to be a phone) appears on a user port.

Pair LLDP scoping with the port level controls covered in our other layer 2 posts. 802.1X decides who may use a port at all, which blunts voice VLAN abuse. MACsec encrypts frames on a link, which makes passive reading of LLDP on an infrastructure link impossible without the keys. SNMP is how most tools read the LLDP neighbour tables remotely, so its own access controls matter.

Controls on hosts

On servers, three lldpd options do most of the work:

• -k disables advertising of the kernel release, version and machine. The manual says the kernel name is still shared and the inventory software version becomes "Unknown".
• -i disables LLDP-MED inventory TLV transmission.
• -r is receive only mode: lldpd listens to neighbours and sends nothing.

lldpcli adds per TLV switches. unconfigure lldp management-addresses-advertisements stops the Management Address TLV. unconfigure lldp capabilities-advertisements stops the capabilities TLV. configure system description "..." replaces the system description with a string you choose. configure system interface pattern limits which interfaces run LLDP at all.

On systemd-networkd, the defaults are already conservative. The systemd.network documentation says LLDP= controls reception and defaults to routers-only, which collects LLDP data only from routers and similar infrastructure and ignores stations and telephones. EmitLLDP= controls transmission and defaults to false, so a host using networkd sends nothing unless you ask it to.

Step by step: read and control LLDP on Linux with lldpd

This walkthrough uses lldpd, the ISC licensed LLDP implementation whose current release listed on its site is 1.0.21. Its installation guide covers Debian and Ubuntu, Fedora and RHEL (with EPEL for older RHEL releases), SUSE, Docker, the BSDs and macOS. None of these commands change anything on the network beyond what your own host advertises.

Step 1: install and start lldpd

# Debian and Ubuntu
sudo apt-get update
sudo apt-get install lldpd

# Fedora, RHEL and derivatives
sudo dnf install lldpd

# Start it now and on boot
sudo systemctl enable --now lldpd
systemctl status lldpd

As soon as it starts, lldpd begins sending LLDPDUs on every physical interface with its default settings. If you want to look before you advertise, stop it and restart it in receive only mode first (step 5).

Step 2: see who is on the other end of each cable

# One line per neighbour
sudo lldpcli show neighbors summary

# Everything the neighbour advertised, including VLANs and LLDP-MED
sudo lldpcli show neighbors details

# Only one interface
sudo lldpcli show neighbors ports eth0 details

# Machine readable output for scripts
sudo lldpcli -f json show neighbors details
sudo lldpcli -f keyvalue show neighbors

The lldpcli manual page shows that commands can be abbreviated, so sh neigh p eth0 sum is the same as show neighbors ports eth0 summary. A typical summary line shows the local interface, the neighbour's Chassis ID, its system name, its Port ID and its port description: enough to update a cabling spreadsheet or to confirm that a server's two uplinks really go to two different switches.

To watch changes live:

sudo lldpcli watch

Step 3: check what your own host advertises

# What lldpd will put in the Chassis and System TLVs
sudo lldpcli show chassis details

# Per interface view, including Port ID and description
sudo lldpcli show interfaces details

# Current configuration, including tx-interval and tx-hold
sudo lldpcli show configuration

# Counters: frames sent, received, discarded, aged out
sudo lldpcli show statistics

Look at SysDescr and MgmtIP in the chassis output. If the description contains the full kernel build string and the management address is an internal address you would rather not hand to a provider's switch, change it in the next step.

Step 4: trim what you send

The lldpd manual says commands in lldpd.conf and in files in the lldpd.d directory under the system configuration directory (usually /etc) are executed by lldpcli at start, so they use the same syntax you type interactively. Daemon flags go in the service's options file: the lldpd installation guide names /etc/default/lldpd on Debian and Ubuntu and /etc/sysconfig/lldpd on Fedora and RHEL. Open the file first and use the variable name it already contains.

# /etc/default/lldpd on Debian/Ubuntu (check the variable name in your file)
# -k: do not advertise kernel release, version and machine
# -i: do not send LLDP-MED inventory TLVs
DAEMON_ARGS="-k -i"

# /etc/lldpd.d/10-hardening.conf
configure system description "Linux server"
configure system interface pattern eth*,ens*,!docker*,!veth*,!virbr*
unconfigure lldp management-addresses-advertisements
configure lldp portidsubtype ifname
configure system max-neighbors 4

What each line does, per the lldpcli manual:

• configure system description overrides the system description string.
• configure system interface pattern limits LLDP to matching interfaces; a leading ! excludes a pattern, so container and virtual bridges are skipped.
• unconfigure lldp management-addresses-advertisements stops sending the Management Address TLV.
• configure lldp portidsubtype ifname sends the interface name as Port ID, which is usually more useful to the switch team than a MAC address.
• configure system max-neighbors bounds how many neighbours lldpd keeps per interface for each protocol (the default is 32; a server port normally has one).

If your cabling tooling needs a management address, use configure system ip management pattern to pick the specific address you want advertised rather than letting lldpd pick the first one.

Restart and check:

sudo systemctl restart lldpd
sudo lldpcli show chassis details

Step 5: receive only, or off, where you do not want to advertise

# Receive only for all interfaces, at runtime
sudo lldpcli configure lldp status rx-only

# Receive only for one interface
sudo lldpcli configure ports eth1 lldp status rx-only

# Turn LLDP off on an interface entirely
sudo lldpcli configure ports eth2 lldp status disabled

The status command accepts rx-and-tx, rx-only, tx-only and disabled. Put the same lines in a file under /etc/lldpd.d/ to make them persistent. Alternatively, start the daemon with -r for receive only on all ports.

Step 6: the systemd-networkd route

On systems that use systemd-networkd, you may not need lldpd at all for reading neighbours.

# /etc/systemd/network/10-uplink.network
[Match]
Name=eno1

[Network]
DHCP=yes
# Receive LLDP from all neighbour types, not only routers
LLDP=yes
# Keep the default: do not transmit LLDP
EmitLLDP=no

sudo networkctl reload
networkctl lldp
networkctl lldp eno1

The networkctl manual shows that networkctl lldp prints the link, system name, system description, chassis ID, port ID, port description and capability flags of each neighbour, and notes that LLDP= must be on for the interface. The systemd.network documentation records that LLDP= was added in systemd version 219 and EmitLLDP= in version 230.

Step 7: verify on the wire with tcpdump and Wireshark

Tools that read configuration can be wrong about what is actually sent. Capture the frames:

# Capture only LLDP frames on eth0; -e prints link level headers
sudo tcpdump -i eth0 -nn -e -v ether proto 0x88cc

# Save 60 seconds of LLDP for Wireshark
sudo timeout 60 tcpdump -i eth0 -w lldp.pcap ether proto 0x88cc

The Wireshark wiki gives ether proto 0x88cc as the capture filter and lldp as the display filter. Useful display filters from Wireshark's LLDP field reference:

lldp                                   all LLDP frames
lldp.tlv.system.name                   frames that carry a System Name TLV
lldp.tlv.system.desc                   frames that carry a System Description TLV
lldp.mgn.addr.ip4 || lldp.mgn.addr.ip6 frames that advertise a management address
lldp.ieee.802_1.vlan.name              frames that advertise VLAN names
lldp.media.subtype                     frames that carry any LLDP-MED TLV
lldp.media.sn || lldp.media.firmware   frames that leak serial numbers or firmware revisions
lldp.media.vlan_id                     frames that advertise a voice or video VLAN
lldp.media.civic.value                 frames that carry a civic address
lldp.chassis.id.mac                    chassis IDs encoded as MAC addresses

Wireshark's own support for LLDP and the LLDP-MED extensions dates back to version 0.10.13, according to its wiki, and the wiki links small sample captures (a minimal LLDP frame, a detailed one and an LLDP-MED frame with a civic location) that are useful for practising these filters without touching a production network.

Run one capture on a user port and one on an infrastructure port and compare. The user port capture is what an intruder sees.

Windows and macOS

Windows

Microsoft documents an LLDP agent for Windows through the NetLldpAgent PowerShell module. The module reference says its use "requires the DataCenterBridging feature to be installed", and its cmdlets get, enable and disable the agent per network interface. The -AddressScope parameter takes NearestBridge, NearestNonTpmrBridge and NearestCustomerBridge, the same three agent types described earlier.

# Find the Data Center Bridging feature name on this server, then install it
Get-WindowsFeature *Bridging*

# Show the LLDP agent settings for one adapter
Get-NetLldpAgent -NetAdapterName "Ethernet1"

# Enable or disable the agent on that adapter
Enable-NetLldpAgent -NetAdapterName "Ethernet1"
Disable-NetLldpAgent -NetAdapterName "Ethernet1"

On Windows machines where you only want to see what the switch is advertising, a packet capture with Wireshark using the capture filter ether proto 0x88cc shows it without enabling any agent.

macOS

The lldpd installation guide covers macOS: it offers an installer package (macOS 10.6 or later) or a Homebrew formula, and notes that the build prints instructions for creating the _lldpd user and group and starting the daemon at boot. If you only want to read what the switch advertises, tcpdump, which ships with macOS, is enough:

# macOS: list interfaces, then capture LLDP on the wired one
networksetup -listallhardwareports
sudo tcpdump -i en0 -nn -e -v ether proto 0x88cc

How data centre tools use LLDP for cabling and topology

In a large data centre, the cabling plan is a document that says "server 14 port 1 goes to leaf switch 3 port 27". Humans make mistakes when they plug thousands of cables. LLDP turns the plan into something a machine can check.

Cabling validation

The pattern is the same whatever the tooling:

1. Hold an intended topology: a list of links, each with two device names and two port names.
2. Collect actual LLDP neighbour data from every switch (over SNMP, a management API or the switch's own data store) and from servers (lldpcli -f json show neighbors).
3. Compare. Every link where the neighbour's System Name and Port ID do not match the plan is a cabling error, flagged before the rack goes live.

Bare metal provisioning is a good public example. The OpenStack Ironic documentation lists inspection hooks that use LLDP collected from the deployment ramdisk: parse-lldp parses the raw binary LLDP data into a parsed_lldp dictionary keyed by interface name, with values such as the switch chassis ID and switch system name, and local-link-connection uses that LLDP information to fill in each port's physical switch connection. The server's switch port is therefore known before the server is configured, and a server cabled to the wrong switch shows up at inspection time rather than after it has been put into service.

On the switch and host side, lldpd's own feature page shows the neighbour data being exposed through a built in SNMP subagent and a client library over a Unix socket, and lldpcli -f can print plain text, XML, JSON or key value output, which is what most cabling scripts consume.

A minimal version with lldpd output:

# Dump this host's neighbours as JSON and print interface, neighbour name and port
sudo lldpcli -f json show neighbors | python3 -c '
import json, sys
data = json.load(sys.stdin)
ifaces = data.get("lldp", {}).get("interface", [])
if isinstance(ifaces, dict):
    ifaces = [{k: v} for k, v in ifaces.items()]
for entry in ifaces:
    for name, info in entry.items():
        chassis = info.get("chassis", {})
        sysname = next(iter(chassis), "?") if isinstance(chassis, dict) else "?"
        port = info.get("port", {}).get("id", {}).get("value", "?")
        print(f"{name}\t{sysname}\t{port}")
'

The JSON layout varies a little between lldpd versions and between one neighbour and several, which is why the script handles both a list and a dictionary. Compare its output against your intended cabling file.

Automated topology maps

Topology mapping tools work the same way at fleet scale: poll each device's LLDP neighbour table, treat each neighbour entry as an edge, and draw the graph. Because LLDP is standard, the same poller works across makers, which is the whole point of the standard. The weakness is the one we covered above: LLDP data is unauthenticated. A topology map built from LLDP shows what devices claim, so treat unexpected edges (a "switch" appearing on a user port, two devices claiming the same Chassis ID) as alerts, not facts.

Data centre bridging and LLDP

LLDP also carries data centre bridging settings: the IEEE 802.1 organizationally specific TLVs for Enhanced Transmission Selection, Priority based Flow Control and Application Priority, listed in the Wireshark wiki, let a switch and a server agree on lossless traffic classes for storage traffic. It fits that Microsoft's LLDP agent module requires the Data Center Bridging feature, and it is a reason LLDP often cannot simply be turned off on data centre server ports.

Timeline: LLDP and LLDP-MED milestones

Common mistakes

• Treating LLDP as harmless metadata. System descriptions and LLDP-MED inventory hand out exact software versions and serial numbers. Review them the way you would review a banner on a login page.
• Leaving LLDP transmit on guest and lobby ports. No device on those ports needs to know your switch model, its build or its management address.
• Sending LLDP-MED on every port. Only phone and media endpoint ports need network policy and power. Location is needed only where emergency calling depends on it.
• Trusting LLDP data in automation. LLDP is unauthenticated. Automation that assigns VLANs or power based only on what a device claims in LLDP can be fooled.
• Forgetting the older discovery protocols. Disabling LLDP while a single vendor discovery protocol stays on leaves the same leak in place.
• Advertising from hosts in someone else's network. Servers in colocation or provider networks often run lldpd with defaults, sending kernel builds and internal addresses to a switch you do not operate.
• Letting container and virtual interfaces run LLDP. Without an interface pattern, a daemon may try to run on bridges and virtual interfaces where it adds noise and nothing else.
• Not patching the parsers. Every LLDP implementation parses untrusted TLVs from every port. Keep network operating systems, host daemons and libraries that parse LLDP current.
• Building a voice VLAN with no port authentication. If any device can read the voice VLAN from LLDP-MED and tag into it, the voice VLAN is only as protected as the least protected wall port.

FAQ

What is LLDP used for?

LLDP is used to discover which device and which port sit at the other end of each Ethernet link. Network management systems use the neighbour tables to build topology maps, engineers use them to troubleshoot links and validate cabling, and IP phones use the LLDP-MED extension to learn their voice VLAN and negotiate Power over Ethernet.

What is the difference between LLDP and LLDP-MED?

LLDP is the base protocol from IEEE 802.1AB: identity, port, TTL and a few optional descriptive TLVs. LLDP-MED is ANSI/TIA-1057, a set of extra TLVs under the TIA's OUI for media endpoints. It adds network policy (VLAN, priority and DSCP), extended power negotiation, inventory and location.

Is LLDP a security risk?

LLDP is an information disclosure risk rather than a direct vulnerability. It has no authentication or encryption, so anything on the port can read what is advertised, and anything can send spoofed advertisements. Limit what is sent on untrusted ports and keep the software that parses LLDP patched.

Should I disable LLDP?

Disable LLDP transmission on user, guest and public facing ports, and keep it on infrastructure links where topology data is valuable. On server ports, keep it if your cabling or automation tools use it, but trim the system description and management address.

Does LLDP go through switches or routers?

No. With the default nearest bridge address 01:80:C2:00:00:0E, LLDP frames are not forwarded by standards conformant bridges, so they stay on a single link. Routers do not forward them either. Two other agent types use different reserved addresses (01:80:C2:00:00:03 and 01:80:C2:00:00:00) that let frames pass through Two Port MAC Relays or provider bridges, but each still stops at the first bridge of the type it targets.

What port and protocol does LLDP use?

LLDP does not use IP or TCP or UDP ports. It is a layer 2 protocol carried directly in Ethernet frames with EtherType 0x88CC. In Wireshark the capture filter is ether proto 0x88cc and the display filter is lldp.

How do I see LLDP neighbours on Linux?

Install lldpd and run sudo lldpcli show neighbors details. On systems using systemd-networkd, set LLDP=yes in the interface's .network file and run networkctl lldp. You can also capture frames with sudo tcpdump -i eth0 -nn -v ether proto 0x88cc.

How often are LLDP frames sent?

lldpd sends one LLDPDU every 30 seconds by default, with a hold multiplier of 4, giving a TTL of 120 seconds. Fast start sends frames more often for a short time when a new neighbour appears.

Can LLDP reveal my location?

Yes, if the switch is configured to send the LLDP-MED Location Identification TLV. That TLV can carry coordinates or a civic address down to floor and room, so that IP phones can report it for emergency calls. Send it only on ports where emergency calling needs it.

What replaced IEEE 802.1AB-2016?

The IEEE Standards Association lists 802.1AB-2016 as superseded by 802.1AB-2026, approved by the IEEE SA Standards Board on 25 September 2026. The 2016 edition had two amendments in 2021: 802.1ABcu for a YANG data model and 802.1ABdh for multiframe protocol data units, so TLV sets too large for one frame can be sent across several.

Where Safeguard fits

Safeguard does not monitor networks, configure switches or inspect LLDP traffic, and it does not scan switch firmware. The connection is narrower and worth stating plainly. The software that parses and produces LLDP is open source in many places: daemons such as lldpd, network operating systems built on Linux, the Python and Go libraries in your network automation repositories, and the container images that run your topology and cabling tools. Safeguard scans those repositories, container images and SBOM files, matches their components against vulnerability databases, ranks findings with reachability analysis and can open pull requests to move a vulnerable dependency to a fixed version.

LLDP itself is a standard, but every implementation that parses it is software, and much of that software in automation tools, network operating systems and containerised collectors is assembled from open source packages. Keeping those packages patched is the part of LLDP security that lives in your build pipeline rather than on the switch.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not LLDP monitoring or network security. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the container image for a topology collector or cabling checker your team builds, the same scan lists the packages and versions inside it, including any LLDP parsing library, and their known vulnerabilities.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a vulnerable dependency in a Python or Go network automation repository that consumes LLDP neighbour data.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• IEEE SA: IEEE 802.1AB-2016, Station and Media Access Control Connectivity Discovery
• IEEE SA: IEEE 802.1AB-2026
• IEEE SA: IEEE 802.1AB-2009
• Wireshark wiki: Link Layer Discovery Protocol
• Wireshark display filter reference: LLDP
• Wireshark source: LLDP dissector (packet-lldp.c)
• lldpd project home
• lldpd features
• lldpd installation
• lldpd usage and manual pages
• lldpd security and past vulnerabilities
• lldpd source: lldpd.8 manual page
• lldpd source: lldpcli.8 manual page
• systemd.network manual: LLDP= and EmitLLDP=
• networkctl manual: lldp command
• Microsoft Learn: NetLldpAgent module
• Microsoft Learn: Get-NetLldpAgent
• Microsoft Learn: Enable-NetLldpAgent
• OpenStack Ironic: inspection hooks (parse-lldp, local-link-connection)
• IETF RFC 4776: DHCP option for civic addresses configuration information

Last reviewed: 23 October 2026. IEEE 802.1AB has a new 2026 edition and network operating systems change their LLDP defaults between releases; check the standard and your platform's documentation for the edition and options you actually run.