skip to content

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%

answer

  1. advertisements go to whoever listens
  2. names, versions, addresses
  3. the voice policy is a hint
  4. transmit, not receive, leaks
  5. nothing is authenticated

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.

solid answer

~40 s

LLDP is an unauthenticated broadcast of self-description, so whatever the switch port transmits, the laptop receives: `System Name` (often revealing site and role), `System Description` (frequently vendor, model and software release, ready to match against known vulnerabilities), `Management Address`, port descriptions, the port VLAN ID from IEEE 802.1's TLVs, and through LLDP-MED's `Network Policy` the voice VLAN ID. The laptop can also transmit: forged LLDPDUs can pose as an IP phone to obtain the voice policy, or pollute the topology data automation trusts. To limit it, disable LLDP transmit on ports facing untrusted users and keep unused ports shut; where phones need MED, send only the TLVs they need; require port authentication before granting the voice VLAN; keep management addresses unreachable from user VLANs; and treat LLDP-learned data as claims, not identity.

go deeper

for a junior

Recall that LLDP tells anything plugged into a port about the switch, including its name and software, and that this is why user ports need care.

for a middle

Explain which TLVs leak what, why transmit rather than receive is the leaking direction, and that LLDP has no authentication.

for a senior

Show the hardening plan: transmit off on untrusted ports, minimal MED TLVs behind port authentication, unreachable management addresses, and alarms for unexpected neighbours.

for a principal

Set the policy line between operational visibility and disclosure across infrastructure, user and unused ports, and decide what automation may trust from LLDP.

## The scenario A visitor finds a live network jack in a meeting room and plugs in a laptop. The access switch behind the jack runs LLDP with transmit and receive enabled on every port and all basic TLVs switched on. Within one advertisement interval the laptop has a description of the switch, even if it never gets an IP address — LLDP runs directly over Ethernet, and as RFC 8520 notes, LLDPDUs are not requests and responses and receivers do not acknowledge them, so the switch never knows who is listening. ## What a transmitting port tells the laptop | What the switch sends | What a visitor learns | |---|---| | `System Name` | the hostname, which often encodes building, floor and role | | `System Description` | frequently the vendor, hardware model and exact software release — enough to look up published vulnerabilities | | `Management Address` | an address where the switch's management plane listens | | `Port Description` | the administrator's notes for the port, sometimes naming uplinks or tenants | | `System Capabilities` | whether it bridges, routes or both | | IEEE 802.1 TLVs | the port's VLAN ID and sometimes VLAN names | | IEEE 802.3 TLVs | link settings, power details, maximum frame size | | LLDP-MED `Network Policy` | the voice VLAN ID, priority and DSCP the switch expects phones to use | None of these is secret in a cryptographic sense, but together they shorten reconnaissance from hours to seconds. The voice VLAN ID is the sharpest item: if the port accepts tagged voice traffic without authenticating the device, the laptop can tag its own frames with that VLAN and land on the voice network. The tagging and hopping mechanics themselves belong to VLAN design; LLDP's contribution is handing over the number. ## What the laptop can send back LLDP has **no authentication**. The switch believes any well-formed LLDPDU it receives, so the laptop can: - **Pose as an IP phone** by sending an LLDP-MED capabilities TLV, prompting the switch to send voice policy and, on some switches, apply phone-specific port behaviour. - **Pollute the inventory.** Tools that build topology maps or drive automation from LLDP neighbour tables will record whatever Chassis ID, System Name and capabilities the laptop invents. - **Create neighbours in bulk.** A stream of LLDPDUs with different Chassis IDs consumes the switch's neighbour storage; how a switch caps that is an implementation choice. ## Limiting the exposure 1. **Disable LLDP transmit on ports that face untrusted users**, and shut or isolate unused ports entirely. Each LLDP agent is configured per port for transmit, receive, both or neither, and it is the **transmit** direction that leaks. Disabling only receive stops the switch hearing the laptop while it keeps advertising. 2. **Send only what is needed where phones live.** If ports must run LLDP-MED for phones, suppress `System Description` and `Management Address`, which phones do not use. 3. **Authenticate before trusting.** Port authentication such as IEEE 802.1X decides whether a device gets the voice VLAN; an LLDP claim to be a phone should never be enough on its own. 4. **Keep management addresses unreachable** from user and guest VLANs, so a leaked address is not a reachable target. 5. **Treat LLDP data as claims.** Automation should cross-check LLDP neighbours against inventory before acting on them; RFC 8520's own LLDP extension leaves what to do with received data entirely to the administrator. 6. **Watch for surprises.** An LLDP neighbour on a port where none is expected, or several, is a cheap alarm for an unplanned switch or a probing device. ## The trade-off Turning LLDP off everywhere removes the leak and also removes the cabling map, phone auto-configuration and fast fault isolation. The usual balance: - **Infrastructure links** — switch to switch, switch to server, switch to access point: keep LLDP fully on, because those ends are trusted and the data is operationally valuable. - **User-facing ports**: no transmit unless phones need it, and then a minimal TLV set behind port authentication. - **Unused ports**: administratively down. A protocol default should not decide this. The standard's job is to make advertisements possible; deciding who should receive them is the operator's.

  • Why shouldn't an automation system assign a port's VLAN purely from the LLDP neighbour it reports?
    Because every LLDP field is an unauthenticated self-description. A laptop can announce itself as a phone or copy a real device's System Name, and the switch records it faithfully. Automation should require port authentication or cross-check against an inventory before granting anything on the strength of LLDP.
  • If you disable LLDP transmit on all user-facing ports, what do you lose and how do you compensate?
    Phones lose LLDP-MED voice policy and fast power negotiation on those ports, and you lose the switch side of the desk-cabling map. Compensate by keeping receive on, so the switch still records phones that advertise; by enabling a minimal MED TLV set only on authenticated phone ports; and by keeping full LLDP on infrastructure links.

saying these in an interview costs you the question

  • LLDP only exposes MAC addresses, nothing an attacker can use
  • LLDP frames are authenticated, so laptops cannot pose as phones
  • Disabling LLDP receive stops the switch leaking its details
  • Turning LLDP off everywhere costs nothing operationally
  • The voice VLAN ID is useless to someone without a phone