CDP and LLDP: The Neighbour That Is Not There
A connected neighbour that no CDP command will reveal, because it is not a Cisco device. Diagnose it and bring it into view yourself, live, right below.
Symptom
Three devices are cabled in and only two appear in the neighbour table. The cable is fine, the port is fine, and no amount of CDP will ever reveal the third one.
Your mission
Prove the cause, then fix it
Format
Guided CLI investigation
Investigate before you configure.
Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.
Observe the symptom and link state.
Diagnose by comparing the protocol evidence.
Verify the expected device state and confirm the original symptom is resolved.
Console access: SW1
This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.
Need a hint?
Reveal the root cause when you're ready.
Try the investigation first, then use this as your escape hatch, not a dead end.
Lab debrief
Turn the session into a repeatable troubleshooting pattern.
Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.
The problem
You are documenting an inherited network. SW1 has three neighbours cabled to Gi0/1, Gi0/2 and Gi0/3, but show cdp neighbors lists only two. A colleague has concluded that the third port is dead and is about to raise a cabling ticket.
What you'll practice
- Read a CDP neighbour table and its capability codes
- Use interface status to disprove a suspected cabling fault
- Understand that CDP is Cisco proprietary and LLDP is the open standard
- Enable LLDP and confirm a third-party neighbour appears
1. Absence of evidence is not evidence of absence
A missing CDP entry means the neighbour is not speaking CDP to you. It does not mean the cable is bad, the port is down, or the device is off. You will learn to check the port itself before believing the protocol.
2. CDP is Cisco only, LLDP is everybody
CDP is a Cisco proprietary protocol, so a third-party access point, firewall or server will never appear in it no matter what you configure. LLDP is the IEEE standard that both sides can speak, and on IOS it is off by default.
3. Two commands that look similar and are not
cdp enable turns CDP on for one interface; lldp run turns LLDP on for the whole device. You will try the wrong one first and see why it changes nothing, which is the fastest way to remember the distinction.
The topology
SW1 has three connected neighbours: R1 on Gi0/1, SW2 on Gi0/2, and a third-party wireless access point on Gi0/3.
Commands to run yourself
The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.
show cdp neighborsshow interfaces statusshow lldpTopology diagram
Frequently asked
The port shows connected, so why is there no CDP entry for it?
Because CDP entries come from advertisements the neighbour sends, not from the link state. A port can be up, forwarding user traffic perfectly, and still produce no CDP entry, either because the neighbour does not speak CDP at all or because CDP has been disabled on one of the two ends. Link state and discovery are independent, which is why show interfaces status is the command that disproves the cabling theory.
Will cdp enable on the interface help?
Not here. CDP is a Cisco proprietary protocol, so a third-party device has no way to speak it regardless of what you configure on your side. Enabling CDP on the port is a reasonable thing to check if a Cisco neighbour is missing, but against a non-Cisco device it can never produce an entry.
Why is LLDP off by default when CDP is on?
CDP is Cisco's own protocol and ships enabled on Cisco gear; LLDP is the open IEEE 802.1AB standard and IOS leaves it off until you ask for it with lldp run. In a mixed-vendor network it is usually worth enabling both, since each one sees devices the other cannot.
Ready to run this lab yourself?
No setup, no image sourcing. Book a session or ask for a live demo.