Study guide
3.3 Virtual Switching Extension (VSX) Architecture and Operations
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
3.3 Virtual Switching Extension (VSX) Architecture and Operations
Key Takeaways Explain This Topic AI
Virtual Switching Extension (VSX) is a dual-control-plane virtualization technology designed for campus core and aggregation switches (AOS-CX 6400, 8100, 8325, 8360, 8400).
VSX nodes maintain independent operating systems and control planes, eliminating single-point-of-failure vulnerabilities and enabling zero-downtime In-Service Software Upgrades (ISSU).
The Inter-Switch Link (ISL) is a dedicated Layer 2 LAG that synchronizes MAC tables, ARP caches, and state information, while carrying transient data traffic.
The VSX Keepalive link operates over an independent Layer 3 path using UDP port 7678 to prevent split-brain conditions if the ISL experiences a link failure.
Multi-Chassis Link Aggregation (VSX-LAG) presents dual physical switches as a single logical LACP entity to downstream access switches, eliminating Spanning Tree blocking.
Last updated: October 2026
3.3 Virtual Switching Extension (VSX) Architecture and Operations
While Virtual Switching Framework (VSF) provides an ideal stacking solution for campus wiring closet access switches, enterprise core and aggregation layers demand higher levels of resiliency. At the campus core, a single centralized control plane represents an unacceptable single point of failure: an operating system crash, memory leak, or control-plane software fault on the Conductor would impact the entire core network. A standard firmware upgrade of a single-control-plane stack also reboots every member, although the CX 6300 adds VSF ISSU for minor-release upgrades.
To overcome these limitations, Aruba architected Virtual Switching Extension (VSX) . VSX is a dual-control-plane virtualization technology engineered specifically for high-availability aggregation and core switches in the AOS-CX portfolio, including the CX 6400 , CX 8100 , CX 8325 , CX 8360 , CX 8400 , and CX 10000 series.
Dual Control Plane vs. Single Control Plane
The fundamental architectural distinction between VSF and VSX lies in control plane independence: +------------------------------------+ +-----------------------------------+
- | VSF ARCHITECTURE | | VSX ARCHITECTURE |
- | (Single Control Plane) | | (Dual Control Plane) |
- | | | |
- | +------------------------------+ | | +-------------+ +-------------+ |
- | | UNIFIED CONTROL PLANE | | | | CONTROL PL. | | CONTROL PL. | |
- | | (Conductor Only) | | | | Primary | | Secondary | |
- | +--------------+---------------+ | | +------+------+ +------+------+ |
- | | | | | | |
- | +--------------+---------------+ | | +------+----------------+------+ |
- | | DISTRIBUTED DATA PLANE | | | | DISTRIBUTED DATA | |
- | | (Member ASICs Forward) | | | | PLANE FORWARDING | |
- | +------------------------------+ | | +------------------------------+ |
- +------------------------------------+ +-----------------------------------+
In VSF , all physical members share one control plane managed by the Conductor. If the Conductor fails, the entire stack must execute a switchover or reload.
In VSX , two physical switches run completely independent control planes , independent operating system kernels, and separate management instances. A failure or crash on one switch has zero impact on the peer switch's control plane.
Live Upgrades: VSX supports sequential upgrades of the two peers (for example with vsx update-software ): one peer is upgraded and rebooted while the other forwards production traffic, then the roles swap. Dual-homed (VSX-LAG) devices stay connected throughout.
Core Components of VSX Architecture
A functional VSX pair relies on four fundamental architectural building blocks: +-------------------------------------------------------------------------+
- | VSX PEER PAIR |
- | |
- | +-----------------------+ +-----------------------+ |
- | | VSX PRIMARY | ISL (LAG) | VSX SECONDARY | |
- | | Control Plane 1 (Indep)|<============>| Control Plane 2 (Indep)| |
- | | Config / Sync Master | State Sync | Config / Sync Slave | |
- | +-----------+-----------+ +-----------+-----------+ |
- | ^ | \ / | ^ |
- | | | \ Keepalive (L3) / | | |
- | | | + - - - - - - - - - + | | |
- | | | UDP Port 7678 | | |
- | | | | | |
- | | +------------------+ +-----------------+ | |
- | | | | | |
- | | +======+=+======+ | |
- | | | VSX-LAG | | |
- | | | (LACP Bundle) | | |
- | | +=======+=======+ | |
- | | | | |
- | | v | |
- | Orphan Port +-----------------+ Orphan Port |
- | (Single-homed) | Downstream Switch| (Single-homed) |
- | | (e.g., CX 6300) | |
- | +-----------------+ |
- +-------------------------------------------------------------------------+
- 1. Inter-Switch Link (ISL)
A dedicated Layer 2 Link Aggregation Group (LAG) directly connecting the two VSX switches.
Best practice requires configuring the ISL across at least two high-speed physical interfaces (e.g., 40G, 100G, or 25G) spanning different line modules on modular chassis to guarantee link-level redundancy.
The ISL carries VSX control synchronization traffic , continuously replicating Layer 2 MAC address tables, ARP/ND tables, and STP topology information between peers.
In the data plane, the ISL forwards transit traffic between peers when an asymmetric path exists or when an uplink on one switch fails.
2. VSX Keepalive Link
A dedicated point-to-point Layer 3 connection running between the two VSX peers over an isolated management network or a direct routed link between front-panel interfaces.
Transmits periodic UDP hello packets on UDP port 7678 by default ( keepalive udp-port can change it). The default hello interval is 1 second and the default dead interval is 3 seconds (AOS-CX 10.14 CLI Guide).
Carries no user data traffic and no configuration synchronization.
Serves exclusively as a health witness: if the ISL fails, the Keepalive link allows peers to distinguish between a peer hardware crash and an ISL cable disconnection.
3. VSX Synchronization (VSX-Sync)
An automated configuration daemon that synchronizes operational parameters from the Primary switch to the Secondary switch over the ISL.
Administrators enable vsx-sync for selected features (globally or on objects such as VLANs, ACLs, and interfaces) on the Primary switch, and AOS-CX replicates that configuration to the Secondary peer.
Prevents human error and configuration drift across core switches.
4. Multi-Chassis Link Aggregation (VSX-LAG)
Allows downstream switches (e.g., CX 6300 access stacks) or servers to connect to both VSX peers simultaneously using standard IEEE 802.3ad Link Aggregation Control Protocol (LACP).
Downstream devices perceive the two distinct physical core switches as a single logical switch.
Eliminates Spanning Tree blocked links: both uplinks actively forward traffic, delivering active-active Layer 2 throughput and instantaneous failover if one link or switch fails.
Device Roles and Split-Brain Mitigation
In a VSX pair, one switch is explicitly configured as role primary and the other as role secondary . Both switches actively forward traffic and process routing protocols concurrently. The roles define synchronization hierarchy (Primary synchronizes to Secondary) and govern split-brain behavior.
Scenario 1: ISL Link Failure (Keepalive Remains UP)
If all physical cables in the ISL LAG are cut while the Keepalive link remains healthy:
Both switches detect that the ISL is DOWN, but Keepalive heartbeats confirm that the peer is alive.
To prevent Layer 2 forwarding loops, MAC address flapping, and duplicate default gateway responses, the Secondary switch initiates self-isolation .
The Secondary switch disables all of its VSX-LAG member ports .
All downstream client traffic is forced to use the Primary switch's links in the VSX-LAGs.
Crucially, orphan ports (interfaces connected to single-homed devices attached only to the Secondary switch) remain operational, ensuring single-homed hosts maintain connectivity.
Scenario 2: Complete Peer Hardware Failure (ISL Down, Keepalive Down)
If the Primary switch loses total power:
The Secondary switch detects that both the ISL and the Keepalive link have gone DOWN simultaneously.
The Secondary recognizes that the Primary switch is no longer reachable by either path.
With split recovery enabled (the default), the Secondary keeps or restores its VSX-LAG ports so it can carry the traffic. If split recovery were disabled, the Secondary would keep its VSX-LAGs down after the ISL had gone out of sync.
- Basic VSX Configuration Workflow ! --- VSX Primary Switch Configuration ---
- switch-A(config)# vsx
- switch-A(config-vsx)# role primary
- switch-A(config-vsx)# inter-switch-link lag 256
- switch-A(config-vsx)# keepalive peer 192.168.100.2 source 192.168.100.1 vrf mgmt
- switch-A(config-vsx)# system-mac 02:00:00:00:00:01
- ! --- VSX Secondary Switch Configuration ---
- switch-B(config)# vsx
- switch-B(config-vsx)# role secondary
- switch-B(config-vsx)# inter-switch-link lag 256
- switch-B(config-vsx)# keepalive peer 192.168.100.1 source 192.168.100.2 vrf mgmt
- switch-B(config-vsx)# system-mac 02:00:00:00:00:01
The shared system-mac ensures that both switches present the exact same LACP System ID to downstream devices on VSX-LAG bundles.