skip to content

LLDP Neighbor Discovery

3 roadmaps5 questions

Switches and hosts advertise their name, port and capabilities to direct neighbours in LLDP frames, building a live cabling map. Interviewers ask how you would find which switch port a server is on.

on this pageshow

explore

questions

5

In a rack cabling audit, how does LLDP tell you which switch and port a server's network interface is plugged into?

level: juniorimportance: must knowfreq 32%

answer

  1. each end announces itself
  2. nobody asks, nobody answers
  3. chassis plus port identify the far end
  4. multicast that bridges do not forward

basics

~20 s

LLDP devices periodically announce their identity and the port each frame left from, to a multicast address standard switches do not forward. A server that hears its switch's frame learns the switch name and port number at the other end of its cable.

solid answer

~40 s

LLDP (IEEE 802.1AB) is a one-hop, one-way advertisement protocol running directly over Ethernet with EtherType `0x88CC`. Each enabled port periodically sends an LLDPDU whose mandatory TLVs are `Chassis ID`, `Port ID` and `Time To Live`, usually followed by `System Name` and `Port Description`. The frame goes to a reserved link-local multicast MAC address that standard bridges consume rather than forward, so whatever you hear came from the device at the other end of that cable. To audit a rack, enable LLDP receive on the server's interfaces, read the stored neighbour — switch name plus Port ID — and compare it with the cabling plan; the switch's own neighbour table gives the reverse view for every port at once.

go deeper

for a junior

Recall that LLDP lets each end of a cable announce its device name and port, and that reading the server's neighbour tells you exactly where its cable lands.

for a middle

Explain the mandatory Chassis ID, Port ID and Time To Live TLVs, the one-way advertisement model, and why the reserved multicast address keeps the answer to one hop.

for a senior

Show the operational edge cases: receive-only or disabled agents, adapters or hypervisors swallowing frames, and two neighbours on a port revealing an unplanned switch.

for a principal

Frame LLDP as a cheap, continuous source of truth for a cabling inventory, and say when its claims need cross-checking because they are unauthenticated self-descriptions.

## What LLDP is The **Link Layer Discovery Protocol** (LLDP), defined by IEEE 802.1AB, lets each device on an Ethernet link announce who it is and which of its ports the announcement left from. It runs directly over Ethernet with **EtherType `0x88CC`**, so it needs no IP address on either side; RFC 7404 makes that point when it notes that LLDP keeps working on router links that carry only IPv6 link-local addresses. RFC 8520 summarises the two properties that matter for a cabling audit: - **One hop.** An advertisement describes one link and is meant to be read only by the device at the other end of it. - **One way.** A device sends an LLDP data unit (an **LLDPDU**) on its own schedule. Nobody requests it, and the receiver never acknowledges it. Each receiver stores what it heard against the port it heard it on, and forgets it when the advertisements stop. ## Reading one advertisement An LLDPDU is a sequence of **type-length-value fields (TLVs)**. Three are mandatory and come first; the others are optional, though most switches send several of them. | TLV | Mandatory? | What it tells you in an audit | |---|---|---| | `Chassis ID` | yes | which device sent the frame — often one of its MAC addresses | | `Port ID` | yes | which port on that device the frame left from | | `Time To Live` | yes | how many seconds the receiver may keep this information | | `System Name` | no | the device's configured hostname | | `Port Description` | no | the administrator's label for that port | | `Management Address` | no | an address for reaching the device's management plane | A worked reading: the server's second interface has stored Chassis ID `00-00-5E-00-53-10` (a MAC address, from the documentation range of RFC 9542), System Name `rack14-leaf-a` and Port ID `port-23`. The cable from that interface therefore ends on port 23 of the switch called `rack14-leaf-a`. Note that the **Chassis ID is not necessarily a hostname**: the standard lets it be a MAC address, a network address, an interface name or a locally assigned string, among other forms, which is why the optional System Name is the field people actually read. ## Running the audit 1. **Enable the right directions.** An LLDP agent can be set per port to transmit, receive, both or neither. The switch ports must transmit; the server interfaces must receive. Enabling transmit on the servers as well gives the reverse view. 2. **Wait for one advertisement cycle.** IEEE 802.1AB's default transmit interval is 30 seconds (an implementation may change it), so within about a minute every working link has delivered at least one LLDPDU. 3. **Read each server interface's neighbour:** switch name or Chassis ID, plus Port ID. 4. **Read the switch's neighbour table** if the servers transmit. One table lists the device on every port of that switch, which is how a whole rack is checked from one place. 5. **Compare with the cabling plan.** A mismatch means a mis-patched cable, a swapped interface name, or a plan that was never updated. ## Why the answer is always the next device LLDPDUs go to a **reserved link-local multicast MAC address** — normally `01-80-C2-00-00-0E`, which IEEE 802.1 calls the nearest-bridge address. It sits in the `01-80-C2-00-00-00` to `01-80-C2-00-00-0F` block that standard bridges keep to themselves instead of flooding; TRILL's RFC 6325 likewise classes that whole block as layer 2 control frames its bridges must not forward. A conforming switch therefore reads the frame and stops it. That is what makes the result trustworthy: the advertisement stored on a server interface came from the device at the other end of that cable, not from anything further away. ## When the answer is missing or odd - **No neighbour at all.** The far side has LLDP disabled or set to receive only, or something in between consumed the frame. Some network adapters run their own LLDP agent in firmware and a hypervisor's virtual switch may not pass LLDP to a guest; both are implementation behaviour worth checking first. - **Two neighbours on one port.** A hub, or one of the many inexpensive unmanaged switches that pass the reserved multicast through contrary to the standard, sits in the path, so devices beyond it are heard as well. - **An unexpected neighbour.** A passive patch panel is invisible to LLDP, but a small switch or media converter that runs its own agent is not; the neighbour is whatever terminates the cable electrically and speaks LLDP. - **LLDP not available.** The fallback is following the server's MAC address through the switches' forwarding tables, a slower technique with its own traps. The habit worth carrying into an interview is to name both directions and the scope: LLDP answers "what is on the other end of this one cable", reliably and with no IP configuration, as long as both ends run it.

  • A server shows no LLDP neighbour even though the switch has LLDP enabled. What would you check?
    Whether the switch port actually transmits and the server interface actually receives, since each direction is configured separately. Then whether something between them consumes the frames: an adapter running its own LLDP agent in firmware, or a hypervisor's virtual switch that does not pass LLDP to the guest. Finally, wait at least one transmit interval after enabling it, because LLDP never answers a request — the server can only wait for the next advertisement.
  • Why can one switch port list two LLDP neighbours at once?
    Because something on that cable passes the reserved multicast through instead of consuming it. A hub repeats every frame, and many unmanaged switches flood the nearest-bridge address contrary to the standard, so the switch hears every LLDP speaker behind that device. Two neighbours on an access port usually means an unplanned switch under a desk or in a rack.

LLDP is a name badge each device wears facing the one person across the table: it says 'switch rack14-leaf-a, seat 23', nobody has to ask to read it, and nobody further down the room can see it.

saying these in an interview costs you the question

  • LLDP queries the switch and waits for its reply
  • LLDP frames cross every switch, so you see the whole network
  • LLDP needs an IP address on the server to work
  • The Chassis ID is always the switch's hostname
  • LLDP finds the port by searching the switch's MAC address table
open as a page

How does LLDP differ from CDP, and why would a network built from several vendors' switches run LLDP?

level: juniorimportance: should knowfreq 24%

basics

~20 s

LLDP and CDP both advertise a device's identity, port and capabilities to its direct neighbour, but LLDP is the IEEE 802.1AB standard any vendor implements, while CDP is one vendor's proprietary protocol. Mixed-vendor networks run LLDP so every device can see every other.

open as a page

Which three TLVs open every LLDP frame, and how does the Time To Live TLV let a neighbour forget a device that disappeared?

level: middleimportance: should knowfreq 16%

basics

~20 s

Every LLDPDU opens with Chassis ID, Port ID and Time To Live. The TTL says how many seconds to keep the sender's information: without a fresh advertisement the entry ages out, and a TTL of 0 deletes it at once.

open as a page

What does an LLDP-speaking access switch reveal to a laptop plugged into an unused office wall port, and how would you limit it?

level: seniorimportance: should knowfreq 20%

basics

~20 s

A transmitting access port tells any laptop the switch's name, model and software release, its management address, the port's VLAN and often the voice VLAN. Stop LLDP transmit on untrusted ports, trim TLVs where phones need them, and authenticate ports.

open as a page

How does LLDP-MED let an IP phone on an access switch port learn its voice VLAN and negotiate its PoE power?

level: middleimportance: nice to knowfreq 12%

basics

~20 s

LLDP-MED, a TIA extension carried in ordinary LLDP frames, has the switch advertise a Network Policy TLV giving the voice VLAN ID, priority and DSCP, and lets phone and switch exchange Extended Power-via-MDI TLVs to agree an exact power draw.

open as a page