Link Layer Discovery Protocol (LLDP) helps a network engineer answer a deceptively simple question: what device is attached to this port? Instead of guessing from cable labels, switch port descriptions, or IP-address tables, a receiving device can inspect information advertised by its directly connected neighbor. That makes LLDP valuable when verifying an installation, tracing an unexpected connection, or reconciling the logical topology with the physical one.
LLDP is standardized by IEEE 802.1AB and works at the link layer. It is designed for adjacent-device discovery in multivendor environments, not for routing traffic, mapping an entire campus by itself, or proving that a remote device is trustworthy. A useful LLDP practice therefore combines neighbor observations with interface status, VLAN configuration, routing information, and asset records. Understanding that boundary prevents a discovery feature from being mistaken for a control-plane or security mechanism.
What a directly connected neighbor can advertise
An LLDP-capable device periodically advertises a compact description of itself over an enabled interface. The receiver records information associated with the ingress port. Typical details include the sender’s chassis identifier, port identifier, advertised lifetime, system name, description, supported capabilities, and sometimes a management address. The information comes from the neighbor’s own configuration; it is not a cryptographically verified inventory entry. It should be treated as a useful observation that may need independent confirmation.
A chassis identifier is intended to distinguish the transmitting device. A port identifier distinguishes the transmitting interface. Neither has to look like a friendly hostname: platforms may use a MAC address, interface name, or locally defined value. A topology application must therefore preserve the raw identifiers and map them to human-readable names carefully. Two ports showing the same remote chassis but different remote port identifiers can indicate two physical attachments to one device rather than an impossible duplicate neighbor.
LLDP does not cross ordinary switched paths in the way an IP trace does. Its link-local Ethernet destination keeps discovery scoped to the immediate link. A switch three hops away cannot simply appear as the direct LLDP neighbor unless another device deliberately proxies or modifies the discovery information. This locality is precisely what makes LLDP useful when validating physical adjacency, but it also means that one neighbor table does not reveal the entire network.
Ethernet framing, TLVs, and the required fields
On Ethernet, LLDP uses EtherType 0x88CC and a link-local multicast destination. Its data is encoded as a sequence of type-length-value structures, abbreviated TLVs. Each TLV identifies a data type, provides its length, and contains its value. This extensible structure lets equipment from different suppliers present a common minimum set while advertising additional information when the implementation supports it.
The essential sequence contains chassis ID, port ID, and time-to-live information, followed by the end-of-LLDPDU TLV. The TTL tells the neighbor how long an advertisement remains useful if no replacement is heard. A zero lifetime is meaningful in a withdrawal scenario, while an expired entry usually means the device, link, or LLDP transmission stopped behaving as expected. It does not, by itself, prove why the entry disappeared.
Optional information such as system capabilities and management address can make the advertisement easier to interpret. A ‘router’ capability indicates the sender advertises that role; it is not a guarantee that routing is enabled on the connected port or that the device is forwarding packets correctly. Likewise, a management address can aid identification but may not be reachable from the receiver’s routing domain. Verify both details before incorporating them into monitoring or automation decisions.
LLDP and Cisco Discovery Protocol in mixed networks
Cisco Discovery Protocol (CDP) and LLDP solve overlapping neighbor-discovery problems, but they are not the same protocol and their advertised fields are not identical. CDP is Cisco-oriented; LLDP offers an interoperable standards-based option. In a mixed-vendor access layer, LLDP is often the common denominator for identifying a switch-to-switch connection or the port to which a phone or access point is connected. Cisco platforms can support both, subject to model, software release, and interface settings.
Seeing a CDP neighbor but no LLDP neighbor does not automatically mean the cable is faulty. A device may transmit only CDP, LLDP may be disabled globally or per port, one direction may be suppressed, or the far endpoint may not implement it. The reverse can also happen. Examine the protocol enablement and transmit/receive settings on both ends rather than treating the absence of one table entry as a general link failure.
The operational distinction also matters in switching and VLANs: a neighbor advertisement can confirm which ports meet physically, while the forwarding configuration determines which traffic those ports carry. LLDP does not validate the allowed VLAN list, trunk encapsulation, native VLAN agreement, loop prevention, or policy enforcement. Those require separate checks and, where appropriate, frame-level testing.
LLDP-MED, IP phones, and power negotiation
LLDP-MED extends discovery for media endpoints such as many IP phones. Depending on the devices, it can advertise endpoint capabilities, network policy information, location-related data, inventory details, and power requirements. A switch may publish a voice VLAN and quality-of-service policy that a compatible handset can use during initialization. This is more specific than the base LLDP identification functions and should not be assumed to work identically across all devices.
In voice deployments, inspect the phone, switch, DHCP service, and voice network configuration together. A correct LLDP-MED policy can help a phone choose a voice VLAN, but it cannot compensate for a missing DHCP scope, a routing failure to the call service, or a conflicting port policy. Some phones also support vendor-specific discovery or manual network settings. Record the actual negotiation outcome rather than assuming advertisement equals configuration acceptance.
Power-over-Ethernet behavior is another source of confusion. Depending on the hardware and extensions, link discovery may participate in communicating power requirements, but electrical detection, power budget, and the applicable PoE standard remain separate considerations. A device that advertises power information can still fail to receive adequate power because of switch budget, cable, class, or hardware issues. LLDP provides visibility, not a substitute for measuring the powered link.
Timers, aging, and why neighbor tables change
LLDP normally retransmits on a periodic schedule, with a hold multiplier or advertised lifetime controlling when a receiver expires the information. Platform defaults commonly use a roughly 30-second advertisement interval, but the actual values are configurable and cannot be assumed universally. Fast-start behavior after a link change may temporarily produce a different cadence. A troubleshooting record should capture both configured timers and observed timestamps.
A disappearing neighbor can signal an interface bounce, a maintenance action, an unplugged cable, a software change, an LLDP transmit failure, or a receiving-table age-out. Correlate events before drawing a conclusion. Check interface up/down logs, transceiver counters, errors, and whether the remote endpoint is actually sending valid LLDP frames. A table entry may persist briefly after a link problem because its advertised lifetime has not yet elapsed.
Large-scale discovery tooling needs to handle this eventual consistency. A single missed advertisement should not automatically trigger a high-confidence ‘device removed’ report. Conversely, a very old table snapshot is not proof of present connectivity. Store collection timestamps, limit the staleness window, and distinguish a newly observed neighbor from one inferred from historical records. This is a data-quality issue as much as a protocol issue.
Using LLDP to build trustworthy topology records
For topology reconciliation, start with a port that has a known physical or operational function. Collect the local device identifier and interface, its LLDP neighbor chassis and port IDs, and the timestamp. Query the corresponding remote endpoint independently when access permits. Matching observations in both directions increase confidence that the connection has been recorded correctly. Divergent descriptions can reveal cabling changes, mislabeled patch panels, or switches that report names differently.
A useful inventory keeps more than just a picture. Record device role, switch stack or chassis context, interface speed, VLAN intent, link aggregation membership, management domain, and evidence date. LLDP is one signal in this record. Without those additions, a diagram may show a line between two devices while omitting whether the connection is the intended production uplink, a dormant failover path, or an accidental access-port connection.
For incident response, the value is a disciplined starting point. If an endpoint appears on an unexpected switch, LLDP helps locate the likely attachment but does not certify endpoint ownership. Pair the observation with MAC address tables, authentication logs, DHCP assignments, and physical security records. A broader network troubleshooting sequence still needs evidence from the layer where the actual failure occurs.
Security limits and safe deployment
LLDP advertisements can expose useful infrastructure information to anyone able to receive them on an enabled port. Depending on advertised TLVs, a connected device may learn a switch’s name, management address, platform description, and port identifier. On a trusted internal uplink, that visibility often justifies the operational benefit. On a publicly accessible or untrusted edge port, the disclosure may be unnecessary. Apply a port-specific disclosure policy rather than enabling every optional TLV everywhere.
LLDP does not authenticate the claimed identity of its sender. An attacker with physical or Layer 2 access may craft advertisements that impersonate a device or pollute an automated inventory. Do not use a learned neighbor name as proof that a port belongs to a secure zone or that a management endpoint is authorized. Management systems should bind discovery observations to authenticated switch sessions, maintained device identities, and changes reviewed through ordinary controls.
On equipment that supports it, disable transmit or receive where discovery has no operational purpose; on other ports, restrict unnecessary optional TLVs. Review behavior after firmware upgrades and template changes, since defaults can vary by platform. LLDP is not an access-control protocol, firewall, loop-prevention system, or encryption service. Keep those controls independent and make the discovery configuration consistent with the organization’s visibility and threat model.
A practical verification workflow
When troubleshooting a missing or unexpected LLDP neighbor, first confirm the interface is physically up and that the port isn’t administratively shut. Then check whether LLDP is enabled globally and in both transmit and receive directions on the relevant interfaces. Compare neighbor details with the switch port description and known remote port. Next, inspect the LLDP configuration and current table on the far device if access is permitted.
If the mismatch remains, capture a short interval of traffic at an appropriate observation point and verify that LLDP frames exist, that their source and destination are sensible, and that the expected chassis and port TLVs are present. Use platform-supported packet capture and follow the organization’s change procedures. A capture showing advertisements but an empty neighbor table points toward receiving, parsing, or policy behavior; a capture with no advertisements points toward transmission, interface, or observation errors.
Finally, treat the learned relationship as a claim to be cross-checked. Confirm the port’s actual VLAN and link membership, the remote device’s identity, and any LLDP-MED or power information relevant to the use case. Update the topology record with a timestamp and any known uncertainty. LLDP is most effective when it turns an assumption about physical connectivity into a specific, testable observation—not when its presence becomes a substitute for the rest of network verification.
