LLDP vs CDP: Layer 2 Discovery Protocols Compared

Every switch you have ever managed runs some form of neighbor discovery, and the protocol choice says a lot about your vendor mix: Cisco CDP is proprietary and rich, while LLDP is the IEEE 802.1AB open standard that any vendor's gear can speak. Both operate at Layer 2 and both answer the same operational questions — what is connected to this port, and what is its platform, software and capability? This guide compares how they work, how to configure and verify them, and how to keep them from becoming a reconnaissance tool.

The two protocols are frequently described as competitors, and on a pure Cisco network that framing is fair enough - CDP does everything LLDP does and a little more. On a mixed network it collapses immediately, because a Juniper, Arista, Aruba or Huawei switch will happily answer LLDP and ignore CDP entirely. The useful mental model is not "which is better" but "which one reaches the device at the other end of this cable," and on a multi-vendor fabric the answer is often both, running side by side.

Protocol Fundamentals

• LLDP — IEEE 802.1AB standard, supported across all vendors (Cisco, Juniper, Arista, Huawei, HPE, Mellanox and open source). Sends Type-Length-Value (TLV) frames with chassis ID, port ID, system name, capabilities and management address. Extensible — LLDP-MED adds VoIP and PoE information.
• CDP — Cisco proprietary, but widely supported by other vendors for compatibility (many HP/HPE and Polycom devices answer CDP). Carries device ID, port ID, platform, software version and native VLAN. Frames are multicast at Layer 2.

The practical difference: CDP gives you a slightly richer device picture (including the native VLAN and duplex state) but LLDP is the safe default in a mixed environment because it is standards-based and more extensible. The Cisco Learning Network discussion of LLDP versus CDP summarises the trade-off well: choose LLDP for interoperability and detail, keep CDP where Cisco-only features need it.

Both protocols are one-way and stateless in the sense that a device advertises without expecting a reply. There is no adjacency negotiation and no authentication; a switch simply multicasts its information every timer interval and listens for the same from its neighbors. That design is why discovery "just works" between any two devices that both speak the protocol, and also why it is so easy to leak information - anything that can receive the multicast frames can read the advertisement.

The TLVs That Actually Matter

LLDP is built from TLVs, and only a handful are ever useful in day-to-day operations:

• Chassis ID — the identity of the device, usually its base MAC address or configured system name.
• Port ID — the interface name on the neighbour, which is what you need to cable-check a link from one end alone.
• System Name — the configured hostname; this is the field that makes a neighbour table readable.
• System Capabilities — router, bridge, telephone, access point. Useful for spotting a device type before you know what it is.
• Management Address — an IP address you can reach the neighbour on, which turns "what is plugged into Gi1/0/12?" into an SSH session.
• Port Description — the interface description configured on the neighbour.

CDP adds a few fields LLDP does not carry by default, most notably the native VLAN of the neighbour's port and the duplex/negotiation state. In practice the native-VLAN field is genuinely useful during a trunk-mismatch investigation, and it is one of the few reasons to keep CDP enabled even in an LLDP-first environment. LLDP-MED goes the other way and adds fields relevant to voice: network policy (which advertises the voice VLAN and QoS markings to a phone) and PoE power requirements. On an IP-telephony deployment those TLVs remove a lot of manual configuration from the phones; the Cisco equivalent for voice VLAN provisioning is covered in Cisco voice VLAN setup for IP phones.

Timers and Behavior

Both protocols send periodic advertisements and expire neighbors that stop advertising. CDP defaults to a 60-second timer with a 180-second hold time; LLDP uses a 30-second timer with a 120-second hold time on most platforms. Because the two protocols are independent, switches run them side by side — a Cisco switch facing a Cisco access switch usually exchanges both.

The timer relationship is worth remembering when a neighbour disappears from the table. A CDP neighbour is held for three advertisement intervals (60 x 3 = 180 seconds), and LLDP for roughly four (30 x 4 = 120). If a link flaps briefly, the neighbour entry may persist for a minute or more after the cable is back, which is good for stability and mildly misleading during a fault - the neighbour table can show a device on a port that is currently down. Both timers are configurable, and both become relevant when you want faster detection during a cable-verification exercise.

! Cisco IOS - adjust timers
Switch(config)# cdp timer 30
Switch(config)# cdp holdtime 90
Switch(config)# lldp timer 30
Switch(config)# lldp holdtime 120
Switch(config)# lldp reinit 2

Configuration and Verification

! Cisco IOS - LLDP is off by default
Switch(config)# lldp run
Switch# show lldp neighbors
Switch# show lldp neighbors detail
Switch# show lldp interface GigabitEthernet1/0/1
Switch# show lldp traffic
! Cisco IOS - CDP is on by default
Switch# show cdp neighbors
Switch# show cdp neighbors detail
Switch# show cdp entry *
Switch(config)# no cdp run
Switch(config-if)# no cdp enable

On Junos both are configured at the interface level under protocol lldp and protocol cdp, with show lldp neighbors and show cdp neighbors as the operational views. The single most useful habit: when a port shows an unexpected neighbor, show lldp neighbors detail (or cdp entry) usually reveals the platform, software version and management address of whatever is plugged in.

The same patterns appear on every other CLI. On ArubaOS-CX, LLDP is enabled per interface and verified with show lldp neighbor-info; the transmit/receive and verification workflow is documented in ArubaOS-CX LLDP: transmit, receive and verification. On Arista EOS, LLDP is on by default and shown with show lldp neighbors, while CDP must be switched on explicitly per interface. Knowing which platforms default to which protocol is half the work: IOS defaults to CDP on and LLDP off, EOS defaults to LLDP on and CDP off, and a link between the two therefore starts out exchanging only one direction of information until someone enables the other.

Using Discovery to Cable-Check a Link

The single best operational use of both protocols is verifying a physical link without walking to the far end. The workflow is short and repeats well:

1. Read the local interface: show lldp neighbors gigabitEthernet1/0/1 detail.
2. Note the System Name and Port ID fields - those identify the device and the exact port on the far side.
3. SSH to the management address from the TLV and confirm from the other end that the port maps back to the local switch.
4. Compare interface descriptions on both ends; a mismatch is usually a documented-but-unapplied change.

That loop turns a cable-plant investigation into a two-minute CLI exercise instead of a site visit, and it works across vendors because the fields are standardised. The multi-vendor command equivalents for the surrounding configuration are collected in the multi-vendor CLI cheat sheet.

Security: Disable Where You Do Not Need It

Discovery protocols leak topology information — every frame advertises your device names, models and software versions to anyone on the segment. Best practice from both Cisco and general hardening guides: enable LLDP/CDP only on ports that genuinely need neighbor discovery (interswitch links, VoIP segments) and disable them on untrusted edge ports, internet-facing segments and guest networks. If you must run them, treat CDP as the higher-risk option since it advertises more operational detail.

There are three concrete risks. First, reconnaissance: a neighbour table is a map of the topology, including management addresses that a scanner can act on. Second, platform fingerprinting: the software version in the advertisement tells an attacker which known vulnerabilities are worth trying. Third, the protocol itself can be abused: nothing authenticates an LLDP frame, so an attacker on an access port can inject a fake advertisement and influence what your monitoring believes is connected. Disabling both protocols on edge ports, and clearing or ignoring discovery on untrusted segments, removes the information source rather than trying to sanitise it.

A pragmatic policy that works in mixed environments:

! Disable both globally, then enable where needed
Switch(config)# no cdp run
Switch(config)# no lldp run
Switch(config)# interface range gigabitEthernet1/0/1 - 24
Switch(config-if-range)# cdp enable
Switch(config-if-range)# lldp transmit
Switch(config-if-range)# lldp receive

For monitoring that reports on the network without exposing device internals, flow-based telemetry is a better fit than discovery. The differences between the sampling and flow-export protocols are covered in our sFlow vs NetFlow vs IPFIX article.

Troubleshooting Common Discovery Problems

When a neighbour does not appear, the cause is almost always one of five things, and they are worth checking in this order:

1. The protocol is off on one end. LLDP is disabled by default on IOS, so a Cisco-to-Cisco link that shows CDP neighbours and no LLDP neighbours is a configuration gap, not a fault.
2. The protocol is disabled on the interface. A global lldp run enables it everywhere, but no lldp transmit or no lldp receive on a specific port silences it there; check the interface, not just the global state.
3. The frames are being dropped. UDLD and discovery both rely on Layer 2 broadcasts and multicasts reaching the neighbour; a filter, a misconfigured VLAN, or a broken receive path will stop advertisements even though the link is up.
4. The timer is longer than you waited. A freshly enabled protocol needs one advertisement interval before the neighbour appears - up to 30 seconds for LLDP, 60 for CDP. Re-running show lldp neighbors a few seconds later is not a fault until a full interval has passed.
5. The far end simply does not speak it. A server NIC, a printer or a cheap access point may carry no discovery protocol at all. In that case the absence of a neighbour is the correct result, and the port should have discovery disabled rather than debugged.

Two verification commands separate a protocol problem from a physical one. show lldp traffic counts transmitted and received frames per interface; if the transmit counter is climbing on both ends but the receive counter is static, the frames are being lost in the path. show lldp interface reports whether transmit and receive are enabled per port. Confirm both before concluding that the neighbour is misconfigured.

Which Protocol Should You Run?

The decision is less about preference and more about the fabric you actually have:

• Cisco-only fabric: run both. CDP is on by default and gives the native VLAN and duplex detail; LLDP costs nothing and covers future non-Cisco additions.
• Mixed or multi-vendor fabric: make LLDP the baseline on every link and keep CDP only where Cisco-specific features require it.
• Voice deployments: LLDP-MED on access ports, so phones receive the voice VLAN and power policy automatically.
• Untrusted edge: neither. Disable both and enable them only after the port is reclassified.

Whichever you choose, verify it from both ends of the link at least once per major change. Discovery is cheap, it is already on the wire, and a two-line command is the difference between a confident cable map and a guess.