3.1 Virtual Switching Framework (VSF) Architecture and Topologies

3.1 Virtual Switching Framework (VSF) Architecture and Topologies

In modern enterprise campus networks, managing dozens or hundreds of standalone access switches introduces significant administrative overhead and operational complexity. Traditional designs require network engineers to configure independent management IP addresses, manage isolated configuration files, and rely on Spanning Tree Protocol (STP) to block redundant uplinks to prevent Layer 2 loops. Virtual Switching Framework (VSF) solves these operational bottlenecks by virtualizing multiple physical switches into a single logical chassis.

VSF operates on a single control plane and distributed data plane model. All switches participating in a VSF stack share a single configuration file, a single operational state database, and a single management IP address for SSH, REST API, Web GUI, and Aruba Central management. From the perspective of network administrators and neighboring devices, the entire stack functions as one high-capacity modular switch.

---

AOS-CX Hardware Portfolio and VSF Support

Not all switches in the Aruba CX switching portfolio support VSF stacking. Stacking capabilities are architected into access-layer platforms designed for flexible wiring closet aggregation:

• Aruba CX 6300 Series (CX 6300F and CX 6300M): High-performance campus access and aggregation switches supporting up to 10 members in a single VSF stack. They support 10G, 25G, and 50G transceiver options for high-bandwidth stacking interconnects.
• Aruba CX 6200F Series: Enterprise access switches supporting up to 8 members in a single VSF stack. Stacking interconnects use the SFP+ uplink ports, and the VSF guide notes that 12-port 6200 models cannot stack with 24- or 48-port models.
• Aruba CX 6000 and CX 6100 Series: Entry-level Layer 2 access switches that do not support VSF stacking. These devices operate strictly as standalone switches.
• Aruba CX 6400, CX 8100, CX 8325, CX 8360, and CX 8400 Series: Core and aggregation platforms that use Virtual Switching Extension (VSX) rather than VSF, providing independent dual control planes.

---

VSF Member Roles and Responsibilities

Within every VSF stack, each physical switch is assigned one of three operational roles: Conductor (called Commander or Master in older material), Standby, or Member (AOS-CX 10.14 VSF Guide).

+-----------------------------------------------------------------------+
|                           VSF LOGICAL CHASSIS                         |
|                                                                       |
|  +--------------------+  +--------------------+  +-----------------+  |
|  |    Member 1        |  |    Member 2        |  |    Member 3..N  |  |
|  |   CONDUCTOR        |  |    STANDBY         |  |     MEMBER      |  |
|  | Active Mgmt/Ctrl   |  | Synchronized State |  | Local Forwarding|  |
|  | STP/OSPF/LACP Engine| | Ready for SSO      |  | ASIC Data Plane |  |
|  +---------+----------+  +---------+----------+  +--------+--------+  |
|            |                       |                      |           |
|            +====== VSF Stacking Interconnect Links =======+           |
+-----------------------------------------------------------------------+

1. The Conductor (formerly Commander / Master)

• Runs the unified AOS-CX operating system control and management planes.
• Manages all active network protocols, including Spanning Tree Protocol (STP), Link Aggregation Control Protocol (LACP), Open Shortest Path First (OSPF), Address Resolution Protocol (ARP), and Dynamic Host Configuration Protocol (DHCP) snooping.
• Processes all inbound management sessions (console, SSH, HTTPS, SNMP, and network telemetry agents).
• Maintains the stack configuration and software images and synchronizes the configuration database to the Standby switch.
• Programs forwarding tables (MAC address tables, ARP tables, and IP route tables) into local and remote switch hardware Application-Specific Integrated Circuits (ASICs).

2. The Standby (Warm / Hot Standby)

• Operates as the backup control plane engine for the stack.
• Maintains a synchronized copy of the Conductor's configuration database over the VSF links.
• Does not process active control protocols or respond to external management queries while in Standby status.
• Automatically assumes the Conductor role if connectivity to the existing Conductor is lost through a hardware or link failure, so the remaining members keep forwarding without a full stack reload.

3. The Member (Line Card)

• Operates functionally as an intelligent line card within a modular chassis.
• Does not run independent control plane or management plane processes.
• Uses its local switch ASICs to forward traffic at wire speed; its interfaces are directly controlled and programmed by the Conductor.
• If local destination ports are unavailable, Member switches forward packets across VSF stacking links to reach target interfaces on adjacent members.

---

Primary, Secondary, and How Roles Are Assigned

AOS-CX VSF does not elect the Conductor by a configurable priority value. The rules in the AOS-CX 10.14 VSF Guide are deterministic:

1. Primary member = member 1. This is not configurable; a factory-default switch boots as VSF member 1. During normal operation the primary member is the Conductor.
2. Secondary member = your choice. Any member ID other than 1 can be configured as the secondary with vsf secondary-member <id>. During normal operation the secondary is the Standby. Auto-stacking assigns member 2 as the secondary.
3. Nobody else qualifies. Members other than the primary and secondary can never become Conductor or Standby.
4. Unique member IDs. Each switch needs a unique member ID; a member ID conflict stops the new switch from joining.

switch# configure
switch(config)# vsf secondary-member 2
switch(config)# vsf member 2
switch(vsf-member-2)# type jl666a
switch(vsf-member-2)# link 1 2/1/25
switch(vsf-member-2)# link 2 2/1/26

Best practice is to configure a secondary member (a stack without a Standby has no control-plane redundancy), take uplinks from both the primary and secondary members, and connect both members' management ports to the management network.

---

Interface Numbering and VSF Links

In standalone switches, physical interfaces follow a two-tier syntax (slot/port, such as 1/1 or 1/48). In a VSF stack, interfaces adopt a three-tier syntax to identify member location:

$\text{member} / \text{slot} / \text{port}$

For example, interface 1/1/48 represents Member 1, Slot 1, Port 48. Interface 3/1/12 designates Member 3, Slot 1, Port 12. This numbering convention provides uniform port addressing across the entire unified stack.

Every VSF stack member supports up to two logical VSF links, designated as Link 1 and Link 2 (link <1-2> <interface-range> under vsf member <id>):

• Each VSF link can contain multiple physical ports, and all VSF links in a stack should operate at the same speed. Once a port is added to a VSF link, its previous configuration is removed and it can connect only to another VSF port.
• Combining multiple physical ports into a single VSF link forms an internal link aggregation group, increasing inter-switch backplane throughput and eliminating single points of physical cabling failure.

---

VSF Topologies: Ring vs. Chain

Stack members interconnect using either a Ring topology or a Chain (linear) topology. The physical interconnection scheme directly dictates stack survivability.

In a Ring topology, each member switch connects to two immediate neighbors. If a single stacking cable fails or a port encounters an SFP transceiver fault, the VSF ring gracefully degrades into a functional chain topology. All members retain connectivity to the Conductor and Standby, avoiding a stack split and maintaining network service.