LLDP and CDP explained: neighbour discovery

LLDP, the Link Layer Discovery Protocol, is the IEEE standard 802.1AB. CDP, the Cisco Discovery Protocol, is Cisco's own, and proprietary. Both do the same job: a device describes itself to the device at the other end of each link.

They are one way. A device advertises and never acknowledges, and it does not forward what it receives. Each neighbour table is built only from what arrives on each port.

LLDP rides directly on Ethernet, ethertype 88CC, sent to the multicast address 01-80-C2-00-00-0E, the nearest bridge address, which no standard bridge forwards. So LLDP only ever reaches the next device.

Three fields are mandatory and come first: the chassis ID, the port ID and the time to live. CDP uses its own multicast address, 01-00-0C-CC-CC-CC, with SNAP encapsulation.

After those come optional fields, each one a type, a length and a value. Port description, system name, system description, capabilities such as bridge, router or telephone, and a management address. Then organisation specific extensions.

The IEEE 802.1 set carries the port VLAN ID and VLAN names, and the 802.3 set carries speed and duplex, link aggregation, maximum frame size and power over Ethernet.

By default, LLDP sends every 30 seconds with a hold multiplier of 4, so a neighbour is remembered for 120 seconds after its last message. Cisco, Huawei, Aruba and Juniper agree on those numbers.

CDP sends every 60 seconds, with a hold time of 180. And a message with a time to live of zero makes the neighbour forget the entry at once.

LLDP-MED, from the TIA standard 1057, extends LLDP for endpoints such as IP phones: a network policy with the voice VLAN, power negotiation, inventory, and location for emergency calls.

Cisco only starts sending MED after it hears MED from the end device. Aruba notes that MED is not meant for links between network devices.

Here vendors disagree. On Cisco Catalyst and Nexus, LLDP is off until you enable it, while CDP is on everywhere. Current Huawei switches enable LLDP globally by default, but not CDP. Aruba enables LLDP on every active port, and listens to CDP in receive only mode.

Juniper's own pages contradict each other on the LLDP default, and its EX and QFX switches cannot run CDP at all; they can only tunnel it.

On Cisco, lldp run globally, then lldp transmit and lldp receive on the interface. On Huawei, lldp enable, globally and on the interface, and both are needed. On Aruba, the lldp command, already on by default. On Juniper, set protocols lldp interface all.

Huawei can also read CDP from Cisco neighbours, with lldp compliance cdp receive on the port.

To read the table: show lldp neighbors on Cisco, display lldp neighbor brief on Huawei, show lldp neighbor-info on Aruba, and show lldp neighbors on Juniper.

Every row is a fact no drawing can give you: this local port faces that device, on that port.

Now the warning. Cisco's IOS XE hardening guide says CDP and LLDP can both be used by a malicious user for reconnaissance and network mapping, and that CDP must be disabled on interfaces connected to untrusted networks.

Cisco also notes that LLDP is not an authentication mechanism: it does not verify who the neighbour is. Juniper suggests filtering the TLVs that carry sensitive information.

The parsing itself has been attacked too. In 2020, five flaws in how Cisco devices read CDP were disclosed as CDPwn; four of them let an attacker on the same segment run code on IOS XR routers, Nexus switches, IP phones and cameras.

In practice, keep discovery on links between your own devices, where it builds your map. Turn it off on ports that face the internet, partners and customers: no cdp enable and no lldp transmit on Cisco.

User ports are a trade off. IP phones use CDP or LLDP-MED to get their voice VLAN and their power, so there you limit what is sent rather than stopping it.

Three things break. A port where CDP and LLDP both negotiate power: Cisco says to disable LLDP there. A neighbour that sends LLDP faster than the CPU rate limit allows: Huawei says the excess is dropped, and the neighbour never appears.

And one port that lists several neighbours: the frames crossed an unmanaged device that passed them through.

NacTrack collects CDP and LLDP from every device over SSH, whatever the vendor, and joins both sides of each link: device, interface, address, status and speed, with the proof from the device's own output. Those links are what draw the topology, layer by layer.