Study guide
5.3 LLDP and LLDP-MED Operations & Verification
JNCIS-ENT Enterprise Routing and Switching Study Guide 2026 Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & Junos Enterprise Fundamentals
1.1 JNCIS-ENT Exam Logistics & Blueprint Breakdown 1.2 Junos CLI, Enterprise Platforms & Interface Families 1.3 Layer 2 Bridging Mechanics & Packet Forwarding
2 Chapter 2: VLANs & Inter-VLAN Routing
2.1 VLAN Segmentation and 802.1Q Tags 2.2 Access, Trunk, Native and Voice VLANs 2.3 IRB Architecture and Interface Families 2.4 IRB Configuration and Packet Walk 2.5 VLAN Configuration, Verification & Troubleshooting
3 Chapter 3: Spanning Tree Protocols
3.1 Layer 2 Loops and Root Bridge Election 3.2 STP Costs, Port Roles, States and BPDUs 3.3 RSTP Rapid Convergence & Link Types 3.4 MSTP Architecture & Spanning Tree Operations
4 Chapter 4: Layer 2 Security & Feature Protection
4.1 Edge BPDU and Root Protection 4.2 Loop Protection and Diagnostic States 4.3 Port Security, MAC Limiting & Persistent MAC Learning 4.4 DHCP Snooping, Dynamic ARP Inspection (DAI) & IP Source Guard 4.5 Layer 2 Firewall Filters: Types, Order and Actions
5 Chapter 5: Advanced Layer 2 Features & Storm Control
5.1 Storm Control & Broadcast/Multicast Suppression 5.2 MACsec Link Security and Key Agreement 5.3 LLDP and LLDP-MED Operations & Verification
6 Chapter 6: Protocol-Independent Routing & Load Balancing
6.1 Static, Aggregate, and Generated Routes 6.2 Routing Instances and RIB Groups 6.3 Junos Load Balancing & Filter-Based Forwarding (FBF) 6.4 Martian Routes and Route Acceptance
7 Chapter 7: Junos Routing Policy & Firewall Filters
7.1 Routing Policy Framework & Term Evaluation 7.2 Prefix Lists & Route Filters 7.3 Firewall Filters & Policers
8 Chapter 8: Open Shortest Path First (OSPF) Operation
8.1 OSPF Architecture & Neighbor Adjacency Formation 8.2 OSPF Areas & LSA Types 8.3 OSPFv2 & OSPFv3 Configuration and Verification
9 Chapter 9: Advanced OSPF Features & Routing Policies
9.1 OSPF Special Area Types 9.2 Route Summarization & OSPF Authentication 9.3 OSPF Diagnostics & Common Failure Scenarios
10 Chapter 10: Intermediate System to Intermediate System (IS-IS)
10.1 IS-IS Encapsulation and NET Identity 10.2 IS-IS Levels, Areas and Default Routing 10.3 IS-IS PDU Families and Neighbor Exchange 10.4 IS-IS Database Synchronization and DIS 10.5 IS-IS Configuration, Metrics & Troubleshooting
11 Chapter 11: Border Gateway Protocol (BGP)
11.1 BGP Roles, AS Numbers and TCP Transport 11.2 EBGP/IBGP Sessions, State Machine and Messages 11.3 BGP Attributes & Junos Path Selection Algorithm 11.4 BGP Configuration & Policy Implementation 11.5 BGP Scaling with Route Reflection & Diagnostics
12 Chapter 12: IP Tunneling & High Availability
12.1 GRE & IP-IP Tunneling Architecture 12.2 Link Aggregation (LAG/LACP) & Redundant Trunk Groups (RTG) 12.3 Virtual Chassis Roles and Elections 12.4 Virtual Chassis Links, Splits and Provisioning 12.5 Routing Engine Redundancy: GRES, NSR, NSB and GR 12.6 BFD Detection and VRRP Gateway Redundancy 12.7 Unified ISSU: Requirements and Verification
5.3 LLDP and LLDP-MED Operations & Verification
Key Takeaways Explain This Topic AI
Link Layer Discovery Protocol (IEEE 802.1AB) provides an open, vendor-neutral Layer 2 protocol that advertises device identity, capabilities, and port configuration to adjacent neighbors.
LLDP frames encapsulate information inside Type-Length-Value (TLV) structures; every LLDP frame mandates Chassis ID, Port ID, TTL, and End-of-LLDPDU TLVs.
LLDP-MED (Media Endpoint Discovery, ANSI/TIA-1057) extends LLDP for VoIP and IoT devices, automating Voice VLAN assignment, supported PoE power information exchange, and inventory tracking.
Junos configures discovery protocols under 'protocols lldp' and 'protocols lldp-med', supporting granular per-interface enablement, timer tuning, and TLV filtering.
Verification commands including 'show lldp neighbors', 'show lldp-med neighbors', and 'show lldp local-information' provide critical Layer 2 topology mapping and troubleshooting visibility.
Last updated: October 2026
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 :
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.
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).
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.
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
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.
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.
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.
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: Neighbor TTL = advertisement-interval × hold-multiplier \text{Neighbor TTL} = \text{advertisement-interval} \times \text{hold-multiplier} Neighbor TTL = advertisement-interval × hold-multiplier Under default settings ( 30 × 4 30 \times 4 30 × 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 .