Study guide
2.3 LLDP, LLDP-MED, and Voice VLAN Configuration
HPE Aruba Networking Certified Associate - Campus Access HPE6-A85
Track your progress as you read
Finished sections get a check mark.
1 Introduction: HPE6-A85 Exam Overview
HPE6-A85 Exam Facts and Current Blueprint
2 Chapter 1: Network Stack Fundamentals
1.1 OSI Reference Model and Encapsulation 1.2 TCP/IP Protocol Suite and IP Headers 1.3 Layer 2 Operation, ARP, and 802.1Q Tagging
3 Chapter 2: Physical Connectivity and Host Addressing
2.1 Ethernet Media and Transceiver Standards 2.2 Power over Ethernet (PoE, PoE+, PoE++) Standards and Budgeting 2.3 LLDP, LLDP-MED, and Voice VLAN Configuration 2.4 Host IP Addressing and DHCP Relay Operations
4 Chapter 3: Network Resiliency and Virtualization
3.1 Virtual Switching Framework (VSF) Architecture and Topologies 3.2 VSF Split Detection, Failover, and Auto-Stacking 3.3 Virtual Switching Extension (VSX) Architecture and Operations 3.4 High-Availability Gateways: VRRP and VSX Active-Gateway
5 Chapter 4: AOS-CX Architecture and Switch Operation
4.1 AOS-CX Hardware Portfolio and State Database Architecture 4.2 Network Analytics Engine (NAE) and Automated Telemetry 4.3 AOS-CX Interface Configuration and Port Control 4.4 Link Aggregation (LAG) and LACP Configuration
6 Chapter 5: Layer 2 Protocols and Spanning Tree
5.1 AOS-CX VLAN Configuration and Native VLAN Handling 5.2 Spanning Tree Protocols: STP, RSTP, and MSTP 5.3 Spanning Tree Protections and Loop Prevention 5.4 MAC Address Table Learning, Aging, and Forwarding
7 Chapter 6: Wireless Fundamentals, Standards, and RF
6.1 IEEE 802.11 Standards and Wi-Fi Generations 6.2 RF Fundamentals, Signal Propagation, and Channel Design 6.3 Aruba Access Point Hardware Portfolio and Suffix Conventions 6.4 WLAN Topologies, BSSID/ESSID, and Roaming Standards
8 Chapter 7: Aruba Wireless Architecture and Management
7.1 AOS 10 Architecture and Aruba Central Integration 7.2 Wireless Forwarding Modes: Bridge vs Tunnel Mode 7.3 Automated RF and Client Optimization: AirMatch and ClientMatch 7.4 Secure Wireless Access: WPA3, SAE, and MPSK Implementation
9 Chapter 8: IP Routing Fundamentals and OSPF
8.1 IP Routing Principles and Packet Forwarding 8.2 OSPFv2 Protocol Mechanics and Adjacency Formation 8.3 OSPF Designated Routers and Multi-Area Deployments 8.4 ECMP, Static Routing, and VRF Isolation
10 Chapter 9: Campus Network Security and Segmentation
9.1 DHCP Snooping and Dynamic ARP Inspection 9.2 Port Security and MAC Address Limiting 9.3 ClearPass Policy Management and RADIUS Change of Authorization 9.4 Dynamic Segmentation, User-Based Tunneling, and Policy Enforcement
11 Chapter 10: Authentication, Authorization, and Accounting
10.1 The AAA Framework and Architecture 10.2 802.1X Authentication and EAP Methods 10.3 MAC Authentication and Captive Portal Onboarding 10.4 Administrative Access Control: RADIUS vs TACACS+
12 Chapter 11: Network Management and Telemetry
11.1 Aruba Central Cloud Architecture and Group Configuration 11.2 Zero-Touch Provisioning (ZTP) and Aruba Activate 11.3 AI Insights and Aruba User Experience Insight (UXI) 11.4 Network Telemetry, Streaming APIs, and SNMP/Syslog
13 Chapter 12: Troubleshooting the Solution
12.1 Structured Troubleshooting Methodologies and Scope Isolation 12.2 AOS-CX Layer 2 and Interface Diagnostic Commands 12.3 Layer 3, IP Services, and End-to-End Diagnostics 12.4 Physical-Layer Troubleshooting 12.5 Troubleshooting Wireless Clients and Network Access
14 Chapter 13: Optimizing Performance: QoS, Baselines, and Comparisons
13.1 Quality of Service (QoS) Classification and Marking 13.2 Queuing Algorithms and Congestion Management 13.3 Traffic Policing, Shaping, and Broadcast Rate Limiting 13.4 Establishing a Performance Baseline 13.5 Comparing Results to the Baseline
15 Chapter 14: Plan the Solution
14.1 Analyzing the Current Environment 14.2 Interpreting an Architect's High-Level Design 14.3 Creating a Low-Level Design 14.4 Preparing for Implementation
16 Chapter 15: Validate and Operate the Solution
15.1 Validating the Solution 15.2 Performing Firmware Updates 15.3 Making Basic Ongoing Configuration Changes 15.4 Maintaining Network Documentation
2.3 LLDP, LLDP-MED, and Voice VLAN Configuration
Key Takeaways Explain This Topic AI
LLDP (IEEE 802.1AB) is a vendor-neutral Layer 2 link discovery protocol operating via multicast frames (01:80:C2:00:00:0E) to exchange neighbor device capabilities, system names, and management addresses.
LLDP-MED (ANSI/TIA-1057) extends standard LLDP with specialized TLVs for endpoint devices, delivering automated Network Policy (VLAN and QoS), extended power management, and physical location coordinates; on AOS-CX the Network Policy TLV is sent only when a voice VLAN exists.
Voice VLAN architecture segregates latency-sensitive voice traffic from bursty PC data traffic over a single physical switch port connected to an IP phone with a daisy-chained workstation.
In a converged access port deployment, the workstation communicates untagged in the native/access data VLAN, while the IP phone uses LLDP-MED Network Policy instructions to tag voice frames in the designated voice VLAN.
AOS-CX switches mark a VLAN as the voice VLAN with the voice command in VLAN context and verify neighbors with show lldp neighbor-info and show lldp neighbor-info <port> .
Last updated: October 2026
Modern enterprise campus access networks are densely populated with heterogeneous endpoint devices—workstations, printers, IP phones, wireless access points, IoT building sensors, and surveillance cameras. Efficiently onboarding and integrating these devices requires automated discovery mechanisms at Layer 2. Without automated discovery protocols, network engineers would be forced to manually configure static VLAN tags, Quality of Service (QoS) markings, and power budgets on every individual switch port.
Two critical technologies automate this endpoint integration: Link Layer Discovery Protocol (LLDP) and its specialized extension, LLDP-MED (Media Endpoint Discovery) . When combined with the AOS-CX Voice VLAN feature, they allow a single physical switch port to seamlessly support both an enterprise IP telephone and a daisy-chained user workstation while enforcing strict Layer 2 traffic isolation and Layer 3 QoS prioritization.
Link Layer Discovery Protocol (IEEE 802.1AB)
LLDP is an open, vendor-neutral Layer 2 discovery protocol formalized by the IEEE in standard 802.1AB . It replaces proprietary discovery protocols (such as Cisco Discovery Protocol [CDP] and Foundry Discovery Protocol [FDP]), providing universal neighbor visibility across multi-vendor network hardware.
Protocol Mechanics
Multicast Destination MAC: LLDP frames (called LLDP Data Units, or LLDPDUs ) are transmitted directly into the local physical segment using the standardized IEEE Bridge Filter multicast MAC address: 01:80:C2:00:00:0E .
EtherType: LLDP frames use EtherType 0x88CC .
Link-Local Constraint: Standard 802.1D compliant bridges and switches never forward frames addressed to 01:80:C2:00:00:0E across other interfaces. LLDPDU exchange is strictly confined to the local physical link between adjacent neighbors.
Timers:
Transmit Interval (default 30 seconds): The periodic frequency at which an AOS-CX switch generates outbound LLDPDUs.
Holdtime Multiplier (default 4): Determines neighbor record lifetime (TTL = interval × multiplier = 30 × 4 = 120 seconds ). If no new LLDPDU is received within 120 seconds, the neighbor record is pruned from the switch state database.
Fast-Start Mode: When a link transitions from Down to Up, the switch transmits several LLDP frames in rapid succession (e.g., every 1-2 seconds) to accelerate initial endpoint discovery before settling into the steady-state interval.
TLV Architecture
LLDP communicates information using structured Type-Length-Value (TLV) blocks. Each TLV begins with a 7-bit Type field, followed by a 9-bit Length field (0 to 511 bytes), and the actual Value payload.
Every LLDPDU must include four Mandatory TLVs in strict sequence:
Chassis ID TLV (Type 1): Uniquely identifies the transmitting device (commonly the switch base MAC address or system UUID).
Port ID TLV (Type 2): Identifies the specific physical interface generating the frame (e.g., "1/1/1" or the interface MAC address).
Time to Live (TTL) TLV (Type 3): Advertises how long the recipient should retain the neighbor record in its cache. A TTL of 0 signals an immediate teardown (e.g., during clean switch shutdown).
End of LLDPDU TLV (Type 0): A 2-byte null TLV (Type 0, Length 0) marking the final boundary of the LLDP packet.
Between the TTL TLV and End of LLDPDU TLV, switches insert Optional Basic Management TLVs :
System Name (Type 5): The configured host name of the switch or device.
System Description (Type 6): Software version, operating system release, and hardware build details.
System Capabilities (Type 7): Bitmask indicating device functions (e.g., Bridge, Router, WLAN Access Point, Telephone) and which capabilities are currently enabled.
Management Address (Type 8): The primary IPv4 or IPv6 address assigned to the device for administrative access (e.g., via SSH or Aruba Central).
Port Description (Type 4): Administrative interface description or alias.
LLDP-MED (ANSI/TIA-1057) Extensions
Standard IEEE 802.1AB LLDP was designed primarily for switch-to-switch topology discovery. To address the specialized requirements of Voice over IP (VoIP) telephony and networked media devices, the Telecommunications Industry Association (TIA) developed LLDP-MED (Media Endpoint Discovery), ratified as standard ANSI/TIA-1057 .
LLDP-MED Device Types
ANSI/TIA-1057 separates network connectivity devices (LAN access switches and similar infrastructure, such as an AOS-CX access switch) from three classes of endpoint :
Class I (Generic Endpoints): Basic endpoints that use core LLDP-MED services (for example, IP communications controllers or other basic devices).
Class II (Media Endpoints): Devices that handle media streams, such as media gateways and conference bridges.
Class III (Communication Device Endpoints): End-user communication devices, such as IP phones and softphones.
The switch is therefore not an "endpoint class"; it is the network connectivity device that sends policy and power information to Class I-III endpoints.
Specialized LLDP-MED TLVs
LLDP-MED introduces advanced TLVs that eliminate manual endpoint provisioning:
Network Policy TLV:
Informs the endpoint of the exact Layer 2 and Layer 3 parameters for its application traffic.
Fields include Application Type (Voice, Voice Signaling, Video, Guest Voice), VLAN ID , VLAN Tagging Flag (Tagged vs. Untagged), Layer 2 802.1p Priority (CoS) , and Layer 3 DSCP Value (e.g., DSCP 46 / Expedited Forwarding for voice media, DSCP 24 / CS3 for signaling).
Extended Power-via-MDI TLV:
Enhances basic hardware PoE classification by enabling high-resolution power negotiation.
Advertises power requirement in 0.1 Watt increments , power priority (critical, high, low), and power source (PSE vs. local external supply).
Inventory Management TLVs:
Provides comprehensive asset tracking telemetry.
Collects manufacturer name, model name, hardware revision, firmware revision, software version, serial number, and asset tag.
Location Identification TLV:
Transmits physical geospatial or civic address data to the endpoint.
Essential for Emergency 911 (E911) compliance, ensuring emergency responders can pinpoint the exact building, floor, and cubicle location of a 911 call placed from a VoIP telephone.
Converged Voice and Data Port Architecture
In standard enterprise campus installations, running two separate structured copper cable drops to every cubicle—one for the computer and one for the IP telephone—doubles horizontal cabling, patch panel, and switch port costs. To avoid this expense, enterprise IP phones feature an internal three-port Layer 2 switch :
Port 1 (LAN / Uplink): Connects upstream to the wall jack and the AOS-CX access switch.
Port 2 (Internal DSP / CPU): Connects internally to the IP phone voice engine, digital signal processor (DSP), and microphone/speaker assembly.
Port 3 (PC Pass-Through): Connects downstream via a short patch cord to the employee desktop workstation or docking station. +-------------------------------------------------------------+
- | AOS-CX Access Switch |
- | Port 1/1/1 (Trunk Native) |
- +------------------------------+------------------------------+
- |
- | Single Physical Ethernet Drop
- v
- +----------------------------------+
- | Enterprise IP Phone |
- | (Internal 3-Port L2 Switch) |
- | |
- | +------------+ +------------+ |
- | | Port 1 LAN | | Port 2 DSP | | (Voice Engine)
- | +-----+------+ +-----+------+ |
- | | | |
- | +-------+-------+ |
- | | |
- | +-----+------+ |
- | | Port 3 PC | | (Pass-Through)
- +----------+-----+------+----------+
- |
- | Standard Patch Cord
- v
- +----------------------+
- | User PC Workstation |
- +----------------------+
- The Need for Traffic Segregation
Allowing PC traffic and voice traffic to mix unconstrained on the same Layer 2 broadcast domain introduces major operational hazards:
Latency and Jitter: Large bursty file downloads, OS updates, or video streams from the PC can saturate the link, causing queue buffer bloat, packet drops, and intolerable voice clipping.
Security and Eavesdropping: A compromised workstation running packet capture tools (such as Wireshark) could sniff unencrypted RTP voice streams or execute ARP spoofing against telephone endpoints.
Broadcast Radiation: Large volumes of PC broadcast/multicast traffic unnecessarily wake up IP phone processors.
The Solution: Voice VLAN with 802.1Q Tagging
To isolate and protect traffic, the switch port is configured to support two distinct VLANs simultaneously:
Data VLAN (Untagged / Native): The user workstation does not understand or generate 802.1Q tags. It transmits standard untagged Ethernet frames. The IP phone passes these frames across its internal switch untouched. When they arrive at the AOS-CX switch port, the switch maps them into the configured Native/Access Data VLAN (e.g., VLAN 10).
Voice VLAN (Tagged 802.1Q): The IP phone learns its network policy via LLDP-MED. It encapsulates its own voice media frames in an 802.1Q header containing the Voice VLAN ID (e.g., VLAN 20) and a Layer 2 802.1p CoS priority tag of 5 . The switch accepts these tagged frames, places them into the dedicated Voice VLAN, and maps CoS 5 into strict priority queuing.
AOS-CX Voice VLAN and LLDP-MED Configuration
On AOS-CX, a converged voice port is built from two pieces: a VLAN flagged as the voice VLAN, and an interface that carries the data VLAN untagged and the voice VLAN tagged.
Step 1: Define the Voice VLAN and the Port
The interface is configured as a trunk port where the Data VLAN is native (untagged) and the Voice VLAN is tagged. The voice command in VLAN context marks VLAN 20 as the voice VLAN, which is what the switch advertises in the LLDP-MED Network Policy TLV: switch# configure terminal
- ! Define the Data and Voice VLANs
- switch(config)# vlan 10
- switch(config-vlan-10)# name DATA_VLAN
- switch(config-vlan-10)# exit
- switch(config)# vlan 20
- switch(config-vlan-20)# name VOICE_VLAN
- switch(config-vlan-20)# voice
- switch(config-vlan-20)# exit
- ! Configure the physical access port
- switch(config)# interface 1/1/1
- switch(config-if)# description "Cubicle 104 - VoIP Phone and PC"
- switch(config-if)# no shutdown
- switch(config-if)# vlan trunk native 10
- switch(config-if)# vlan trunk allowed 10,20
- switch(config-if)# exit
- Step 2: Confirm LLDP-MED Advertisement on the Port
LLDP-MED TLVs are controlled per interface with lldp med [poe | capability | network-policy] . All three are enabled by default, and the switch sends MED TLVs only after it hears a MED TLV from the connected endpoint. The Network Policy TLV is sent only when a voice VLAN policy exists (AOS-CX 10.14 CLI and Fundamentals Guides): switch(config)# interface 1/1/1
- switch(config-if)# lldp med network-policy
- switch(config-if)# exit
Exam tip: ArubaOS-Switch (ProVision) and other vendors use different LLDP-MED policy syntax. On AOS-CX, remember the pair voice (VLAN context) plus a trunk that tags the voice VLAN.
- AOS-CX CLI Diagnostics and Verification
- Viewing Discovered Neighbors
To view all connected LLDP neighbors across switch interfaces, execute show lldp neighbor-info . ( show lldp info remote-device is the older ArubaOS-Switch form.) The outputs below are abbreviated for study purposes: switch# show lldp neighbor-info
LLDP Neighbor Information
- LocalPort | ChassisId PortId PortDesc SysName
- -------- + ----------------- ----------- --------- -------------------------
- 1/1/1 | 00:04:f2:88:12:a4 0004f28812a4 Port 1 Polycom-VVX450
- 1/1/2 | 20:4c:03:91:e0:10 204c0391e010 eth0 Aruba-AP655-Bld1
- 1/1/49 | a8:65:02:11:ff:00 1/1/49 1/1/49 CX6405-Core-Agg01
- Inspecting LLDP-MED Details on a Port
To inspect deep LLDP-MED parameters—including negotiated network policies, power allocation, and inventory—execute show lldp neighbor-info <PORT> : switch# show lldp neighbor-info 1/1/1
- Local Port : 1/1/1
- Chassis Type : Mac Address
- Chassis ID : 00:04:f2:88:12:a4
- Port Type : Mac Address
- Port ID : 00:04:f2:88:12:a4
- System Name : Polycom-VVX450
- System Capabilities : Bridge, Telephone
- Enabled Capabilities : Telephone
- Management Address : 10.1.20.105
MED Information:
- MED Device Type : Endpoint Class III (Communication Device)
- Capabilities : Network Policy, Extended Power via MDI, Inventory
Network Policy for Application Voice:
- Policy Tagged : Tagged
- VLAN ID : 20
- L2 Priority (CoS) : 5
- DSCP Value : 46 (Expedited Forwarding)
Power via MDI:
- Power Type : PD Device
- Power Source : From PSE
- Power Priority : High
- Power Required : 5.8 Watts
Inventory:
- Manufacturer : Poly
- Model Name : VVX 450
- Hardware Rev : 1.0
- Firmware Rev : 6.4.2.1023
- Serial Number : 0004F28812A4
This command confirms that the IP phone successfully learned VLAN 20, is tagging its traffic with CoS 5 and DSCP 46, and requested 5.8 Watts via LLDP-MED.