How does Link Layer Discovery Protocol (IEEE 802.1AB) work?

How LLDP advertises information on a local network

LLDP is designed for direct neighbour discovery, not for routing or remote management. Each device periodically sends Layer 2 advertisements with fields that identify the system, the port, and selected capabilities so adjacent switches, phones, endpoints, or controllers can learn what is connected and how to classify it.

The important operational detail is that LLDP is link-local by design. It is normally not forwarded across routers, which means its visibility is confined to the local broadcast domain. That makes it useful for topology discovery, but it also means anyone on that segment can potentially observe the same metadata if they can capture Layer 2 traffic.

Because the protocol is informational rather than stateful, the value comes from the receiver building a neighbour table from repeated advertisements. In practice, that helps with switchport mapping, VoIP discovery, and automated inventory, while also exposing device names, interface labels, and other details that can simplify reconnaissance.

What LLDP does not protect, and why that matters

LLDP was not designed to authenticate the sender or hide the contents of the advertisement. If a host can listen on the same segment, it may learn enough to identify vendors, roles, and attachment points without needing to compromise the device first. That is why LLDP is often treated as a convenience protocol with security implications, not as a trust control.

The same openness that makes discovery easy can also create a mapping aid for an attacker. A local observer can use LLDP output to understand where infrastructure resides, which ports matter, and which devices may deserve closer scrutiny, especially in flat networks or poorly segmented access layers.

In environments with sensitive port metadata, LLDP should be enabled selectively and reviewed as part of switch hardening. The protocol is most defensible when the operational value of discovery outweighs the exposure of device and topology information, and when access to the segment is already tightly controlled.

Where LLDP fits in operational discovery and hardening

LLDP is best thought of as an inventory assist and topology aid. Network teams use it to correlate what is physically connected with what is logically configured, which reduces manual tracing and supports faster troubleshooting. It can also improve change control when device identity and port capability are visible to adjacent infrastructure.

The downside is that discovery data becomes part of the attack surface. If you enable LLDP everywhere by default, you increase the amount of environment detail available to any device that can join the same Layer 2 domain. That is especially relevant on user access switches, shared offices, guest networks, and mixed-trust segments.

For the protocol standard itself, the authoritative reference is the IEEE 802.1AB specification, and for registry context around protocol and identifier assignments, IANA is the canonical source for internet protocol registries.

Risk and Threat Considerations

LLDP can leak enough infrastructure detail to make lateral reconnaissance easier, even when the traffic never leaves the local link. The exposure is usually modest in a hardened campus or datacenter segment, but it becomes more material when untrusted hosts, rogue devices, or guest systems can attach to the same broadcast domain.

Failure mechanism: LLDP frames are openly advertised on the wire, so any local listener with Layer 2 visibility can collect neighbour identity, port, and capability information without authenticating.

Impact: An attacker can use that metadata to map the network, identify valuable devices or ports, and narrow follow-on abuse such as rogue attachment, targeted spoofing, or selective reconnaissance.

Practitioner Guidance

What to verify: Confirm which switchports truly need LLDP, then check whether the exposed fields include more detail than operations actually require. On access layers, validate that discovery is limited to managed segments and that guest, lab, and other untrusted zones do not inherit it by default.

What good looks like: LLDP is enabled where it supports inventory, VoIP, or automation, but disabled or tightly scoped where topology disclosure would add unnecessary exposure. The resulting neighbour data should be sufficient for operations without turning every access port into a source of intelligence for a local observer.

Practitioner takeaway: Treat LLDP as useful discovery metadata, not as a security boundary, and make enablement a deliberate segment-by-segment decision rather than a universal default.

Related resources from NHI Mgmt Group

• Guide: Network Ports and Protocols Security Guide
• Link Layer Discovery Protocol (IEEE 802.1AB)
• How does the data link layer work?
• How does Simple Mail Transfer Protocol (SMTP) work?
• How does an Application Protocol Data Unit (APDU) work?