5.3 LLDP and LLDP-MED Operations & Verification

Layer 2 Neighbor Discovery: IEEE 802.1AB vs. Proprietary CDP

In complex enterprise campus architectures comprising hundreds of access switches, distribution aggregates, wireless access points, and VoIP devices, maintaining accurate physical topology documentation is an immense operational challenge. Cables are frequently swapped during maintenance, patch panels are mislabeled, and endpoints move dynamically between access ports. Network operators and Network Management Systems (NMS) require an automated Layer 2 discovery protocol to discover directly connected neighbors, ascertain remote interface names, identify device models, and detect cabling errors without relying on upper-layer IP routing reachability.

Historical Context: CDP vs. LLDP

Historically, network vendors developed proprietary Layer 2 discovery mechanisms, most notably Cisco Systems' Cisco Discovery Protocol (CDP). While CDP effectively mapped homogeneous Cisco environments, it created major interoperability barriers in multivendor networks. An enterprise deploying Juniper Networks EX switches alongside third-party IP phones, firewalls, or servers could not natively exchange topology metadata via CDP.

To establish a universal, vendor-neutral standard, the Institute of Electrical and Electronics Engineers ratified IEEE 802.1AB, officially named the Link Layer Discovery Protocol (LLDP). Modern enterprise networks utilize IEEE 802.1AB LLDP as the universal standard for Layer 2 discovery across all major networking operating systems, including Junos OS, Linux servers, hypervisors (VMware ESXi), and enterprise VoIP platforms.

Frame Encapsulation and Transmission

LLDP operates strictly at the Data Link Layer (Layer 2). It does not require an IP address to operate and functions independently of bridge forwarding tables:

• Destination MAC Address: LLDP frames are transmitted using the standard IEEE multicast MAC address 01:80:C2:00:00:0E. This address falls within the reserved 802.1D bridge-filtered multicast range (01:80:C2:00:00:00 to 01:80:C2:00:00:0F). According to IEEE bridging standards, compliant Layer 2 switches must never forward or flood frames destined to 01:80:C2:00:00:0E across other switch ports. Consequently, LLDP advertisements remain strictly link-local between directly adjacent physical neighbors.
• EtherType: Standard Ethernet frames carrying LLDP payloads use EtherType 0x88CC.
• Unidirectional Advertising: LLDP is inherently a one-way periodic broadcast mechanism. A device advertises its own state at regular intervals (advertisement-interval, default 30 seconds) without requiring acknowledgments or handshakes from adjacent neighbors.

---

LLDP Data Unit (LLDPDU) and TLV Architecture

Information within an LLDP frame is organized into modular information elements called Type-Length-Value (TLV) structures. Each TLV begins with a 2-byte (16-bit) header comprising a 7-bit Type field (defining the data type, allowing up to 128 unique types) and a 9-bit Length field (specifying the length of the Value payload in octets, ranging from 0 to 511 bytes), followed by the variable-length Value field.

+----------------------+----------------------+---------------------------------+
|   TLV Type (7 bits)  |  TLV Length (9 bits) |      TLV Value (0-511 octets)   |
+----------------------+----------------------+---------------------------------+

Mandatory TLVs

The IEEE 802.1AB specification mandates that every valid LLDP frame must contain four specific TLVs in an exact sequential order:

1. Chassis ID TLV (Type 1): Uniquely identifies the transmitting chassis. In Junos OS, the default Chassis ID is the hardware base MAC address of the switch chassis or supervisor.
2. Port ID TLV (Type 2): Identifies the specific physical or logical egress interface transmitting the frame (for example, ge-0/0/1 or its interface MAC address).
3. Time-to-Live (TTL) TLV (Type 3): Informs the receiving neighbor how long (in seconds) it should retain the received information in its local LLDP neighbor database before expiring and purging the entry. If an endpoint gracefully shuts down, it transmits a "LLDP shutdown" frame containing a TTL of 0, prompting neighbors to purge the entry immediately.
4. End of LLDPDU TLV (Type 0): A fixed 2-byte delimiter (Type = 0, Length = 0) that terminates the TLV sequence in the frame.

Standard Mandatory LLDPDU Sequence:
[ Chassis ID (Type 1) ] -> [ Port ID (Type 2) ] -> [ TTL (Type 3) ] -> [ Optional TLVs... ] -> [ End of LLDPDU (Type 0) ]

Basic Management and Optional TLVs

Between the mandatory TTL TLV and the terminating End-of-LLDPDU TLV, switches insert optional standard TLVs providing operational context:

• Port Description (Type 4): The administrative description string configured on the interface.
• System Name (Type 5): The configured system hostname of the switch (e.g., core-sw01.campus.net).
• System Description (Type 6): Detailed hardware and software metadata, including Junos OS release version and switch model (Juniper Networks, Inc. ex4400-48t, version 22.4R1.10).
• System Capabilities (Type 7): Flags indicating supported and enabled device capabilities (e.g., Bridge, Router, Repeater, WLAN AP, Telephone).
• Management Address (Type 8): The IPv4 or IPv6 address assigned to the switch's out-of-band management interface (me0 or vme) or loopback (lo0.0), allowing NMS platforms to identify SNMP/SSH endpoints.

---

LLDP-MED (Media Endpoint Discovery) Extensions

While basic IEEE 802.1AB excels at switch-to-switch discovery, enterprise VoIP deployments require specialized interactions between access switches and IP telephones. Standard LLDP cannot instruct an IP phone to tag its packets with a specific Voice VLAN, nor can it dynamically negotiate Power over Ethernet (PoE) wattages beyond basic hardware classification.

To bridge this gap, the Telecommunications Industry Association (TIA) developed ANSI/TIA-1057, known as LLDP-MED (Media Endpoint Discovery). LLDP-MED defines vendor-neutral extensions to LLDP specifically optimized for multimedia endpoints, categorized into three endpoint classes:

• Class I: Generic endpoints (such as IP communications controllers or basic sensors).
• Class II: Media endpoints (such as video conference units, media gateways, and streaming servers).
• Class III: Interactive communication devices (standard IP desktop telephones).

Core Capabilities of LLDP-MED

1. Network Policy TLV (Voice VLAN Provisioning): When an IP phone powers on via PoE, it initially transmits untagged frames. Through the LLDP-MED Network Policy TLV, the Junos switch dynamically communicates four critical parameters to the phone:

   • Application Type: Voice
   • VLAN ID: The 802.1Q Voice VLAN ID (e.g., VLAN 20)
   • Tagging Mode: Tagged (instructing the phone to tag voice packets)
   • Class of Service (CoS): Layer 2 802.1p priority (PCP 5) and Layer 3 Differentiated Services Code Point (DSCP 46 / Expedited Forwarding) Upon receiving this policy, the phone automatically configures its internal DSP to tag voice traffic with VLAN 20 while permitting downstream PC traffic to remain untagged on the access VLAN.

2. Extended Power via MDI (Advanced PoE Management): Standard IEEE 802.3af/at PoE uses hardware resistor detection, which allocates power in coarse, static blocks (e.g., 15.4W for 802.3af or 30W for 802.3at). LLDP-MED allows an IP phone to communicate its exact real-time power requirement in 0.1-watt increments (e.g., requesting precisely 6.4 watts). The Junos PoE controller adjusts its power budget accordingly, freeing up surplus wattage on the switch power supply to support additional PoE devices.

3. Inventory Management TLVs: Endpoints advertise granular asset data to the switch, including hardware revision, firmware version, serial number, and manufacturer name. Network management tools can harvest this information via SNMP to maintain automated hardware inventories.

4. Location Identification TLVs (Emergency E911): The switch can advertise civic street addresses, building numbers, and room coordinates to the phone. When an emergency call (911) is placed from the phone, the VoIP PBX extracts this location data to route emergency responders to the exact room.

---

Junos Configuration for LLDP and LLDP-MED

On Juniper EX and QFX series switches, the factory configuration may include interface all; absent an LLDP configuration, the protocol itself is disabled. Inspect show configuration protocols lldp before relying on discovery. Administrators can customize operational parameters under the protocols lldp and protocols lldp-med hierarchies.

Configuring Basic LLDP

[edit protocols lldp]
set interface all
set interface ge-0/0/47 disable
set advertisement-interval 30
set transmit-delay 2
set hold-multiplier 4
set lldp-configuration-notification-interval 15

LLDP Timer Tuning Parameters

• advertisement-interval: Controls periodic LLDP advertisements (default 30 seconds; minimum 5). transmit-delay is a separate minimum spacing after changes (default 2 seconds); the advertisement interval must be at least four times this delay.
• hold-multiplier: A multiplier used to calculate the TTL advertised to neighbors (default is 4). The neighbor's retention timer is computed as: $\text{Neighbor TTL} = \text{advertisement-interval} \times \text{hold-multiplier}$ Under default settings ($30 \times 4$), the receiving neighbor caches the LLDP entry for 120 seconds before timing out.

Restricting TLV Advertisements

For security reasons, administrators may wish to suppress certain optional TLVs (such as System Description or Management Address) on public-facing or untrusted access ports:

[edit protocols lldp interface ge-0/0/1]
set disable

To control individual advertised TLVs, consult supported tlv-select options. Changing a port-ID subtype does not suppress a management-address TLV. Disabling LLDP on an interface suppresses all discovery there, so consider the effect on phones before removing advertisements.

Configuring LLDP-MED and Voice VLAN Integration

To support IP telephony, LLDP-MED must be activated on user-facing access ports and linked with the VoIP configuration under switch-options:

[edit vlans]
set DATA-USERS vlan-id 10
set VOICE-USERS vlan-id 20

[edit switch-options voip]
set interface ge-0/0/1.0 vlan VOICE-USERS
set interface ge-0/0/1.0 forwarding-class expedited-forwarding

[edit protocols lldp-med]
set interface ge-0/0/1

---

Operational Verification & Troubleshooting

Network administrators inspect LLDP and LLDP-MED operational state using several diagnostic commands.

Verifying Adjacent Neighbors

The standard command show lldp neighbors displays directly connected Layer 2 neighbors:

user@EX4400> show lldp neighbors
Local Interface    Parent Interface    Chassis Id           Port info          System Name
ge-0/0/0.0         -                   00:05:86:71:11:00    ge-0/0/10.0        dist-sw01.campus.net
ge-0/0/1.0         -                   00:04:f2:88:99:aa    eth0               Polycom-VVX450
ge-0/0/2.0         -                   00:26:88:44:bb:cc    Port 1             Access-Point-Floor2

Verifying LLDP-MED Endpoints

To inspect VoIP-specific parameters, execute show lldp-med neighbors:

user@EX4400> show lldp-med neighbors
Interface: ge-0/0/1.0
  Device class: Class III (IP Phone)
  Network Policy:
    Application type: Voice
    Policy: Defined
    Tag: Tagged
    VLAN ID: 20
    Layer 2 Priority: 5
    DSCP Value: 46
  Power via MDI:
    Power type: PD device
    Power source: PSE
    Power priority: Critical
    Power requested: 6.4 Watts

Inspecting Local Switch Information

To review the parameters this switch is actively transmitting to its peers:

user@EX4400> show lldp local-information
LLDP status: Enabled
Advertisement interval: 30 seconds
Hold multiplier: 4
Notification interval: 15 seconds
Chassis ID type: Mac address
Chassis ID: 00:05:86:12:34:56
System name: access-sw01.campus.net
System description: Juniper Networks, Inc. ex4400-48t, version 22.4R1.10

Common Operational Traps & Troubleshooting Caveats

• LLDP Drops Across Non-Compliant Hubs/Extenders: If an unmanaged Layer 2 device sits between the Junos switch and an endpoint, it may either drop frames destined for 01:80:C2:00:00:0E or flood them incorrectly, preventing neighbor discovery.
• Voice VLAN Policy Mismatches: If switch-options voip specifies a voice VLAN name that does not exist under vlans, the switch cannot generate the LLDP-MED Network Policy TLV, causing attached IP phones to remain stuck on the untagged data VLAN.
• Timer Asymmetry: If the remote neighbor has an aggressive keepalive expectation while the Junos switch's advertisement-interval is lengthened, neighbors may periodically age out entries, causing flapping in NMS topology maps.

Output note: Command output shown here is a schematic teaching example, not a captured device session. Field names and feature support depend on platform and Junos release.

Official references checked 2026-10-18: LLDP timers.