LLDP⬧ (IEEE 802.1AB) is a Layer 2 discovery protocol that advertises periodic structured metadata about itself to locally connected peers (neighbors). It's a vendor-neutral alternative to CDP.
CDP → richer (Cisco-specific), more consistent
LLDP → standard, but more fragmented (vendor TLVs)
A neighbor is: “The last device that sent me an LLDP frame on this interface.”
No sessions, no trust model and no state machine; LLDP neighbors are observational — not relational.
LLDP is unauthenticated and blindly trusted by most devices.
Any device on the wire can advertise arbitrary identity, capabilities, or management addresses.
LLDP = structured byte stream (everything else is parsing/interpretation).
In real networks, LLDP is primarily used for troubleshooting, physical mapping, and endpoint discovery.
Devices generate LLDP frames in the Control Plane⬧, transmit them on the Data Plane⬧, and process received frames back in the control plane.
This means that depending on how a device is configured, frames can be visible in captures (SPAN/NIC) but not present in a device's LLDP LLDP Neighbor Table⬧.
The local table which holds the neighbor entries can be inspected on modern switches with typical commands like:
show lldp neighborsshow lldp neighbors detailLLDP operates strictly at Layer 2. Frames are Link-Local⬧, single-hop, and never forwarded by switches.
They are always sent to the destination LLDP Multicast MAC⬧: 01:80:C2:00:00:0E.
LLDP includes a TTL⬧ field, but unlike IP, it does not represent hop count.
It defines the lifetime (in seconds) of the advertised information in the receiver’s neighbor table.
When the countdown reaches zero, the entry is considered stale and removed from the receiver’s local table.
An LLDP packet is carried directly inside an Ethernet frame:
01:80:C2:00:00:0E0x88CCThe LLDP frame consists entirely of TLVs⬧.
A TLV is a dynamic and flexible datastructure
Some TLV's are mandatory while others are optional and of those optional TLV' LLDP doesn't have a fixed packet layout like an OSPF Hello header - it is simply a variable-length TLV stream where even the mandatory TLVs have variable lengths.
Everything is encoded this way, which makes LLDP highly flexible — but also means parsing becomes non-trivial, especially when vendor-specific TLVs are involved.
Each TLV can be broken into two distinct elements - Header and Payload
Total header size: 2 bytes
Total payload size: 1 to 511 bytes
| Type | Req | TLV | What it Actually Tells You | Example | Why You Care in Practice |
|---|---|---|---|---|---|
| 0 | ✔ | End of LLDPDU⬧ | Terminates the TLV stream | 0x0000 | Parser stops here — missing = malformed frame |
| 1 | ✔ | Chassis ID⬧ | Device identity (MAC, hostname, or local ID) | 00:11:22:33:44:55 | Identify which box you're connected to |
| 2 | ✔ | Port ID⬧ | Remote interface identifier | Gi1/0/24 | Identify which port on that device |
| 3 | ✔ | TTL⬧ | Lifetime of this advertisement⬧ (seconds) | 120 | Controls neighbor aging / flapping behavior |
| 4 | ✖ | Port Description | Human-readable port label | "Uplink to Core" | Detect mispatching / labeling errors |
| 5 | ✖ | System Name⬧ | Hostname | SW-CORE-01 | Fast device identification |
| 6 | ✖ | System Description⬧ | OS / platform / version | Cisco IOS-XE 17.x | Fingerprint device type & software |
| 7 | ✖ | System Capabilities⬧ | Device roles (bridge, router, AP, phone, etc.) | Bridge, Router | Know what the device is |
| 8 | ✖ | Management Address⬧ | Reachable management IP | 10.10.10.1 | Direct SSH / API target |
| 127 | ✖ | Organizationally Specific | Vendor extensions (OUI-based TLVs) | LLDP-MED, Cisco extensions | Phones, PoE, VLAN, voice configs, etc. |
The mandatory TLVs must appear first (and in correct order!), but their values are variable-length, so LLDP is parsed sequentially, not by fixed field offsets.
0–3 define the protocol skeleton. Everything else is optional — and where vendors differentiate.
If you don’t understand TLV Type 127⬧, you don’t fully understand LLDP in production networks.
Unknown TLVs are skipped using the Length field, which allows devices to safely ignore extensions they do not understand.
| Type | Req | TLV | Wireshark / TShark Field | What It Means in Practice |
|---|---|---|---|---|
| 1 | ✔ | Chassis ID⬧ | lldp.chassis.id | Remote device identity (MAC/hostname) |
| 2 | ✔ | Port ID⬧ | lldp.port.id | Remote interface (Gi1/0/24, Eth1, etc.) |
| 3 | ✔ | TTL⬧ | lldp.ttl | Entry lifetime (seconds) |
| 4 | ✖ | Port Description | lldp.port.descr | Human label (often misleading) |
| 5 | ✖ | System Name⬧ | lldp.system.name | Hostname |
| 6 | ✖ | System Description⬧ | lldp.system.desc | OS / platform / version |
| 7 | ✖ | System Capabilities⬧ | lldp.system.capabilities | Device type (bridge/router/AP/phone) |
| 8 | ✖ | Management Address⬧ | lldp.mgn.addr | Management IP (sometimes multiple) |
| 127 | ✖ | Org-Specific (IEEE 802.1) | lldp.ieee.* | VLAN, priority, DCB |
| 127 | ✖ | Org-Specific (IEEE 802.3) | lldp.ieee.802_3.* | PoE, link aggregation |
| 127 | ✖ | Org-Specific (LLDP-MED) | lldp.med.* | Phones, voice VLAN, location |
Seeing a TLV⬧ in Wireshark does not guarantee the device accepted it.
Capture = data plane
Neighbor table = control plane
If it's in the packet but not in show lldp neighbors detail, the device dropped or ignored it.
If you have Wireshark installed you can also set the filter to lldp or if you want to use the CLI navigate to the Wireshark folder and type
tshark.exe -D to identify your active network interface and follow:
tshark.exe -i 8 -Y "lldp" -T fields `-e frame.time `-e lldp.tlv.system.name `-e lldp.port.id `-e lldp.mgn.addr.ip4PowerShell LLDP Watcher (tshark)
Live LLDP frame capture → parse → structured neighbor view
| Symptom | Meaning | Root Cause |
|---|---|---|
| No neighbors | Nothing received | LLDP disabled, VLAN mismatch |
| One-way neighbor | Asymmetric | Transmit/receive disabled one side |
| Flapping entries | TTL expiry | Unstable link / packet loss / storm control |
| Missing fields | Partial TLVs | Vendor differences |
Follow this order:
LLDP is transmitted untagged by default, meaning: wrong Native VLAN⬧ → LLDP disappears along with neighbor visibility.
These can silently drop LLDP frames depending on configuration.
LLDP is processed by the control plane and may be rate-limited.
Result: Frames visible in capture, but missing from neighbor table.
If you remember nothing else:
All LLDP issues reduce to: