Protocol Atlas

L2 · switching · reviewed

LLDP

Link Layer Discovery Protocol

A standard TLV advertisement of chassis, port, and TTL — vendor-neutral neighbour discovery.

Presenter modeEmbed this figure

IEEE 802.1AB-2016 §7IEEE 802.1AB-2016 §8

Why it exists

Operators need to know what is on the far end of a cable without logging into it — in a mixed-vendor network CDP is not enough.

Enable LLDP transmit and receive where neighbour inventory is wanted; add MED for phones.

Mandatory TLVs and a held neighbour

A switch sends an LLDPDU toward the reserved multicast address. The neighbour records chassis, port, and TTL, and refreshes before the entry ages out.

SW1SW2
  • Link
  • Blocking
  • Packet in flight
  • Discarded
  • Emphasis
Select a device to read its state. Arrow keys walk the topology.
Text equivalent of this diagram
Devices and links at this step
ElementKindState
SW1switch—
SW2switch—
SW1 — SW2linkup
1 / 3

SW1 transmits an LLDPDU to 01:80:C2:00:00:0E. The destination is in the bridge-filtered reserved range — a compliant bridge must not forward it.

What changed

  • Emphasis on SW1
  • LLDPDU: SW1 → SW2

How it works

Mandatory TLVs are chassis ID, port ID, and TTL. Frames use a reserved multicast destination that bridges must not forward. MED extends the protocol for endpoints.

On the wire

Constructed examples, encoded from the field table below them — not captured traffic.

Chassis ID and Port ID as MAC addresses, TTL 120 s, End of LLDPDU. Optional TLVs omitted.

Ethernet
Destination 01-80-C2-00-00-0E (nearest bridge group address). EtherType 0x88CC. Compliant bridges do not forward these frames. IEEE 802.1AB-2016
LLDPDU
Ordered TLVs: Chassis ID, Port ID, Time To Live, then End of LLDPDU. Optional TLVs may appear before End. IEEE 802.1AB-2016

Configure it

Global LLDP with transmit and receive enabled on an access uplink.

Cisco IOS-XE 17.12 · Catalyst 9300, Catalyst 9200draft

  1. lldp run

    Enables the LLDP agent system-wide. Without this, interface-level tx/rx knobs have nothing to run.

    IEEE 802.1AB-2016 §8

  2. interface GigabitEthernet1/0/1
 lldp transmit
 lldp receive

    Both directions must be on for a full adjacency. One-way configs produce one-sided neighbour tables — intentional for some edges, confusing when accidental.

    Common mistake: Leaving transmit off on one side and assuming the far end will still list you.

    IEEE 802.1AB-2016 §8.1

  3. lldp timer 30
lldp holdtime 120

    Advertisement interval and TTL multiplier relationship: holdtime should exceed several timer periods so a missed PDU does not age the neighbour out immediately.

    IEEE 802.1AB-2016 §8.2

Verify

show lldp neighbors
Chassis and port IDs for directly connected neighbours.
show lldp neighbors detail
System name, capabilities, and TTL remaining.

Caveats

  • Marked draft: syntax has not been checked against Cisco documentation or a device.
  • LLDP is not forwarded by bridges; neighbours must be directly connected.

When it breaks

Symptom first, because that is what you have when it happens.

  1. A neighbour is cabled and does not appear in the neighbour table.

    Narrow it down

    1. Check whether LLDP is enabled globally and on the interface, and in which direction.
    2. Confirm the neighbour is not running CDP only.
    3. Look at whether transmit and receive are both enabled.

    Cause

    Transmit and receive are independent. On some platforms LLDP is off by default.

    Fix

    Enable both directions on both devices.

  2. A neighbour appears and then disappears every few minutes.

    Narrow it down

    1. Compare the advertised TTL against the transmit interval.
    2. Check whether frames are rate-limited or dropped.
    3. Look for a device in the middle consuming frames.

    Cause

    The entry ages out because advertisements are not arriving often enough.

    Fix

    Check interval and TTL, and establish whether something is in the middle.

  3. An IP phone does not receive its voice VLAN.

    Narrow it down

    1. Check whether LLDP-MED is enabled, not just LLDP.
    2. Confirm the switch advertises the network policy TLV.
    3. Look at whether the phone is asking for it.

    Cause

    The voice VLAN is carried in LLDP-MED, not base LLDP.

    Fix

    Enable LLDP-MED and verify the network policy TLV.

  4. Inventory of edge devices includes unexpected models facing the internet.

    Narrow it down

    1. Check which edge ports still transmit LLDP.
    2. Confirm policy for untrusted edges.

    Cause

    LLDP on an untrusted edge advertises chassis, software, and management details to a listener.

    Fix

    Disable transmit toward untrusted edges; keep it on between trusted switches.

  5. Two switches show each other as neighbours across what should be a routed hop.

    Narrow it down

    1. Confirm the intermediate device is not a media converter or transparent tap.
    2. Check whether anything is supposed to terminate L2.

    Cause

    Transparent L2 devices pass reserved multicasts, so discovery skips them.

    Fix

    Treat the neighbour table as “nothing consumed the frame,” not “direct copper.”

Design notes

Enable LLDP transmit and receive where neighbour inventory is wanted; add MED for phones.

Misconceptions

“LLDP is Cisco’s discovery protocol renamed.”
CDP is Cisco’s. LLDP is IEEE 802.1AB and vendor-neutral. Many devices run both.
“LLDP frames are forwarded like any other.”
They use a reserved destination a compliant bridge must not forward — otherwise discovery would report distant devices as neighbours.
“The neighbour table proves a direct cable.”
It proves nothing in between consumes the frames. Media converters and some taps pass them through.

More walkthroughs

Transmit without receivefailure

Transmit and receive are independent. One side advertising while the other only transmits produces a neighbour table that is visible from one direction only.

SW1 · tx+rxSees SW2: noSW2 · tx onlyReceive disabledSees SW1: yes
  • Link
  • Blocking
  • Packet in flight
  • Discarded
  • Emphasis
Select a device to read its state. Arrow keys walk the topology.
Text equivalent of this diagram
Devices and links at this step
ElementKindState
SW1 · tx+rxswitchSees SW2: no
SW2 · tx onlyswitchSees SW1: yes
SW1 · tx+rx — SW2 · tx onlylinkup
1 / 2

SW1 sends and listens. SW2 only transmits. SW1 never sees SW2; SW2 may see SW1.

What changed

  • SW1 · tx+rx: Sees SW2 → no
  • SW2 · tx only: Sees SW1 → yes
  • Receive disabled

Base LLDP without MEDfailure

A phone needs the network policy TLV from LLDP-MED. Base LLDP identifies the neighbour and still leaves the phone on the data VLAN.

IP phoneVLAN: data (untagged)SW1 · LLDP onlyNo MED policy TLV
  • Link
  • Blocking
  • Packet in flight
  • Discarded
  • Emphasis
Select a device to read its state. Arrow keys walk the topology.
Text equivalent of this diagram
Devices and links at this step
ElementKindState
IP phonehostVLAN: data (untagged)
SW1 · LLDP onlyswitch—
IP phone — SW1 · LLDP onlylinkup
1 / 2

SW1 advertises chassis and port correctly. The phone never learns a voice VLAN because the network policy TLV is an LLDP-MED extension.

What changed

  • IP phone: VLAN → data (untagged)
  • No MED policy TLV

Check yourself

  • A neighbour appears on one side only. What is the usual cause?
  • Why must a bridge not forward LLDP frames?
  • A phone does not get its voice VLAN over LLDP. What is missing?
  • Does a neighbour entry prove a direct cable?
  • What happens when TTL expires without a refresh?
  • Why run LLDP in a mixed-vendor campus?
  • Transmit and receive on an LLDP agent are:
  • Why disable LLDP transmit on an untrusted edge?