Fundamentals

CDP vs LLDP: What Each Protocol Sees and When to Use Both

Patch panel terminal showing show cdp neighbors and show lldp neighbors output on R2
In: Fundamentals, CCNA, Networking

Every switch and router quietly announces itself to its directly connected neighbors, and you can read those announcements to map a network without a single diagram. Two protocols do this job: CDP, Cisco's own Discovery Protocol, and LLDP, the vendor-neutral IEEE standard. They overlap heavily, they run side by side, and knowing when to use which (and when to turn both off) is a genuine CCNA and day-job skill. This article compares them on a live Cisco IOS XE lab, showing the exact output each produces on the same wire. It sits in the Network Fundamentals guide.

What both protocols do

CDP and LLDP are Layer 2 neighbor-discovery protocols. Each device periodically multicasts a frame out every enabled interface, advertising facts about itself: its name, the port the frame left, its platform and software, its management IP, and more. Neighbors cache what they hear and age it out if the advertisements stop. Because the frames are Layer 2 and never routed, they only ever reveal directly connected devices, which is exactly what makes them trustworthy for physical topology mapping. Neither protocol carries user data or affects forwarding; they are pure control-plane chatter.

The core difference, seen on one wire

Here is the teaching moment. Router R2 connects to three neighbors (R1, R3, and switch SW1). CDP is on by default everywhere, so R2 sees all of them:

R2#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
R1.pinglabz.lab  Eth 0/1           136               R    Linux Uni Eth 0/1
R3.pinglabz.lab  Eth 0/3           135               R    Linux Uni Eth 0/3
R3.pinglabz.lab  Eth 0/2           136               R    Linux Uni Eth 0/1
SW1.pinglabz.lab Eth 0/0           177             R S I  Linux Uni Eth 0/0

Total cdp entries displayed : 4

Four entries, including two separate links to R3 (Eth 0/2 and Eth 0/3), because CDP reports per-interface. Now the same router's LLDP table:

R2#show lldp neighbors
Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID           Local Intf     Hold-time  Capability      Port ID
SW1.pinglabz.lab    Et0/0          120        B,R             Et0/0

Total entries displayed: 1

Only one neighbor. Why? LLDP is not on by default; it must be enabled globally with lldp run. In this lab only R2 and SW1 have it enabled, so R2 sees SW1 over LLDP but not R1 or R3 (which never enabled it). This is the practical difference in a nutshell: CDP works between Cisco devices out of the box, while LLDP has to be switched on but then works across every vendor that supports the standard. In a mixed-vendor network, the device you cannot see over CDP is often perfectly visible over LLDP, and vice versa.

Reading the detail: what a neighbor actually tells you

The summary is for mapping; the detail view is for troubleshooting. CDP detail for the SW1 link:

R2#show cdp neighbors Ethernet0/0 detail
-------------------------
Device ID: SW1.pinglabz.lab
Entry address(es):
  IP address: 10.0.20.10
Platform: Linux Unix,  Capabilities: Router Switch IGMP
Interface: Ethernet0/0,  Port ID (outgoing port): Ethernet0/0
Holdtime : 176 sec

Version :
Cisco IOS Software [IOSXE], Linux Software (X86_64BI_LINUX_L2-ADVENTERPRISEK9-M), Version 17.18.2
...
VTP Management Domain: ''
Native VLAN: 10
Duplex: full
Management address(es):
  IP address: 10.0.20.10

In one command you learned the neighbor's management IP (10.0.20.10), its software version, its native VLAN (10), and its duplex (full). That native-VLAN field alone catches a classic misconfiguration: if two ends of a trunk disagree on native VLAN, CDP logs a mismatch. LLDP detail carries much the same, in standardized TLV form:

R2#show lldp neighbors Ethernet0/0 detail
------------------------------------------------
Local Intf: Et0/0
Chassis id: aabb.cc00.1600
Port id: Et0/0
Port Description: TO-R2
System Name: SW1.pinglabz.lab
System Description:
Cisco IOS Software [IOSXE], Linux Software ..., Version 17.18.2
System Capabilities: B,R
Enabled Capabilities: B,R
Management Addresses:
    IP: 10.0.20.10
Auto Negotiation - supported, enabled
Physical media capabilities:
    1000baseT(FD)
Vlan ID: 10

LLDP structures its data as TLVs (Type-Length-Value fields): System Name, Port Description, Management Address, and so on. It also carries the neighbor's Port Description ("TO-R2"), which is the interface description you configured, a handy sanity check that you are patched where you think you are.

Timers and how they differ

Both protocols advertise on a repeating timer and hold what they learn for a multiple of it. The defaults differ, and the difference matters for how quickly a dead neighbor ages out:

CDP

Advertises every 60 seconds, holdtime 180 seconds. Cisco-proprietary, on by default, uses multicast MAC 0100.0ccc.cccc.

LLDP

Advertises every 30 seconds, holdtime 120 seconds. IEEE 802.1AB standard, off by default, uses multicast MAC 0180.c200.000e.

You can see the holdtimes counting down in the earlier output: CDP entries near 177 (of 180), LLDP near 120. If a neighbor stops advertising, CDP forgets it after up to 180 seconds and LLDP after up to 120. The traffic counters confirm both are actively running:

R2#show cdp traffic
CDP counters :
	Total packets output: 84, Input: 81
	CDP version 2 advertisements output: 84, Input: 81

R2#show lldp traffic
LLDP traffic statistics:
    Total frames out: 92
    Total frames in: 23

The security angle: when to turn discovery off

Everything that makes discovery useful to you makes it useful to an attacker. A device plugged into an untrusted port can passively read CDP or LLDP frames and immediately learn your device names, software versions, management IPs, native VLAN, and platform, a ready-made reconnaissance handout. The hardening rules are simple:

  • Disable discovery on untrusted and edge-facing ports. Use no cdp enable and no lldp transmit / no lldp receive per interface on anything facing users, the internet, or another organization.
  • Keep it on for infrastructure links where the operational value (mapping, troubleshooting, and voice-VLAN assignment for IP phones) outweighs the risk.
  • Turn CDP off globally with no cdp run if your policy forbids it entirely, but remember that some features (Cisco IP phones, some PoE negotiation) rely on it.

LLDP-MED, an extension, is what lets a Cisco phone learn its voice VLAN from the switch, so a blanket disable can break IP telephony; scope it to the ports that need it.

Configuration quick reference

! Enable LLDP globally (CDP is already on by default)
Switch(config)# lldp run

! Disable CDP on one untrusted interface
Switch(config)# interface Ethernet0/5
Switch(config-if)# no cdp enable

! Disable LLDP transmit and receive on that interface
Switch(config-if)# no lldp transmit
Switch(config-if)# no lldp receive

! Turn CDP off everywhere
Switch(config)# no cdp run

The switch's own view confirms the asymmetry

Look at the same link from SW1's side to close the loop. Over CDP, SW1 sees R2 (both run CDP by default):

SW1#show cdp neighbors
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
R2.pinglabz.lab  Eth 0/0           135               R    Linux Uni Eth 0/0

Total cdp entries displayed : 1

And over LLDP, SW1 also sees R2, because these are the two devices where LLDP was enabled:

SW1#show lldp neighbors
Device ID           Local Intf     Hold-time  Capability      Port ID
R2.pinglabz.lab     Et0/0          120        R               Et0/0

Total entries displayed: 1

Discovery is bidirectional but only where both ends participate. R2 and SW1 see each other over both protocols; R1 and R3 (CDP only) are invisible to LLDP entirely. In a real audit this is how you discover that a third-party switch is present but silent on CDP: enable LLDP and it appears.

Which protocol should you actually run?

The pragmatic answer for most enterprises is both, on infrastructure links only. CDP gives you rich Cisco-to-Cisco detail and drives features like IP-phone power negotiation; LLDP gives you visibility into the switches, servers, APs, and phones that are not Cisco. Running both costs almost nothing (a frame every 30 to 60 seconds) and means your topology tools and your NMS see the whole picture regardless of vendor. The one firm rule is the security one: whichever protocols you run, disable them on ports that face users, the internet, or another organization, because the detail that helps you map the network helps an attacker just as much.

Key takeaways

CDP and LLDP both map directly connected neighbors, but CDP is Cisco-only and on by default (60/180-second timers) while LLDP is the IEEE standard, off until you run lldp run (30/120-second timers). On a mixed-vendor network you often need both; the lab above showed R2 seeing three neighbors over CDP but only the one LLDP-enabled switch over LLDP. Use the detail views to pull a neighbor's management IP, version, native VLAN, and duplex in a single command, and disable discovery on any untrusted or edge-facing port because the same data is a gift to an attacker. For the broader topology and switching context, head back to the Network Fundamentals guide.

Written by
More from Ping Labz
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Ping Labz.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.