ArubaOS-CX VSX Configuration: Active-Active Switch HA

Aruba Virtual Switching Extension (VSX) is HPE's active-active high-availability technology for AOS-CX aggregation and core switches. Instead of stacking into a single control plane, two VSX peers keep independent data planes and synchronize key state such as MAC and ARP tables over a dedicated control link, presenting themselves as one virtual switch where it matters. Because configuration is synced from the primary to the secondary, VSX also gives a pseudo single-pane-of-glass management model. This article walks through a minimal two-switch VSX deployment with a multi-chassis LAG (MC-LAG) downlink.

Why VSX Instead of Stacking?

ArubaOS-CX offers two ways to make several switches behave as one: VSF stacking and VSX. VSF merges members into a single logical switch with one control plane, one management IP and one configuration file. That is simple to operate, but all members share fate: a control-plane fault or a firmware upgrade affects the whole stack, and the stack itself is limited by the physical layout of the dedicated stacking links.

VSX takes the opposite approach. The two peers keep independent control planes, independent management addresses and independent forwarding tables, then synchronize the state that must match — MAC address entries, ARP/ND entries, and (optionally) parts of the configuration. Both switches forward traffic at all times, so uplinks and downlinks can be spread across the pair and no link sits idle in an STP-blocked state.

That difference is what you gain in practice:

• Active-active forwarding. Every MC-LAG member link carries traffic. There is no blocked standby link waiting for a failure.
• Hitless maintenance. You can reboot or upgrade the secondary while the primary carries the whole load, then repeat in the other direction — far less disruptive than reloading a whole stack.
• Standard cabling. The ISL is an ordinary Ethernet LAG, so you are not tied to proprietary stacking ports or specific cable lengths.
• Independent troubleshooting. Each peer keeps its own console, SSH session and logs, which makes fault isolation much easier than debugging a stack that has already lost its conductor.

The price you pay is design discipline: the inter-switch link has to be sized for the failure case, the two configurations must stay consistent, and you have twice as many devices to monitor and patch. As a rule of thumb, use VSX at the aggregation and core layer where downstream devices need an active-active bundle, and use VSF stacking in access closets where a single management plane matters more than per-member resilience — our ArubaOS-CX VSF stacking guide covers that model.

VSX Building Blocks

• Roles: one switch is primary, the other secondary; the primary owns configuration synchronization.
• Keepalive: a Layer 3 path (usually a dedicated link or the management network) used to detect peer health.
• Inter-Switch Link (ISL): a high-bandwidth link (physical or LAG) between the peers carrying control traffic and, when needed, data.
• Multi-Chassis LAG: a LAG whose member ports are split across both peers, seen by the downstream device as a single LACP bundle.

Prerequisites and Port Planning

VSX will form with surprisingly little configuration, which is exactly why it is worth planning before you type anything. Work through this list first.

• Matched firmware. Both peers must run the same AOS-CX release. Configuration synchronization and the keepalive protocol are version sensitive, so plan the upgrade window before the deployment, not after.
• Two identities. Each switch keeps its own hostname and management address. Do not try to make them share one.
• A reliable keepalive path. Use a dedicated Layer 3 link or a path that does not traverse the ISL. If the keepalive rides the same physical links as the ISL, a single fibre break can take out both the data path and the peer health check at the same time.
• ISL capacity. The ISL carries control traffic in normal operation, but after a peer failure it can be asked to carry the failed peer's traffic through the surviving switch. Size it for that case: if one peer has 2×100G of uplink, give the ISL at least 2×100G as well, otherwise you have introduced an oversubscription point that only appears during a failure.
• Consistent MTU and spanning tree. Set the same MTU on the ISL, the MC-LAG and the edge ports, and run the same spanning tree mode on both peers. RPVST is the usual choice: with an MC-LAG the bundle is a single logical link, so you are not relying on blocking to break loops.
• LACP in active mode. Multi-chassis LAGs use LACP, and both peers must have the same LAG ID, member count and VLAN configuration.
• Time. Point both switches at the same NTP source so logs, and any time-dependent synchronization, line up.

VSX is designed to work between two standalone switches, and a single VSX peer can itself be a VSF stack. What it cannot tolerate is a peer that is split internally, so verify the stack or standalone state of each side before you enable VSX.

Configuration Example

Prepare the keepalive link and the ISL first. In this example ports 1/1/49-1/1/50 are used for the keepalive and the ISL respectively, with LAG 128 as the inter-switch link.

switch(config)# interface 1/1/49
switch(config-if)# description VSX KEEPALIVE LINK
switch(config-if)# no shutdown
switch(config-if)# ip address 1.1.1.1/30
switch(config)# interface lag 128
switch(config-lag-if)# description VSX INTER-SWITCH-LINK
switch(config-lag-if)# lacp mode active
switch(config-lag-if)# no routing
switch(config-lag-if)# vlan trunk allowed all
switch(config-lag-if)# no shutdown
switch(config)# interface 1/1/50
switch(config-if)# no shutdown
switch(config-if)# lag 128

On the peer switch, repeat the same configuration with IP address 1.1.1.2/30 on the keepalive port. Then enable VSX and set the role on each switch:

switch(config)# vsx
switch(config-vsx)# role primary
switch(config-vsx)# keepalive peer 1.1.1.2 source 1.1.1.1
switch(config-vsx)# inter-switch-link lag 128
switch(config-vsx)# exit

The secondary uses role secondary with the keepalive addresses reversed. VSX is now operational; use show vsx status to confirm both peers are up and synchronized.

Creating a Multi-Chassis LAG for a Downstream Device

An MC-LAG is a LAG created with the multi-chassis keyword, with its physical members distributed across the two peers:

switch(config)# interface lag 10 multi-chassis
switch(config-lag-if)# description DOWNSTREAM-SWITCH
switch(config-lag-if)# lacp mode active
switch(config-lag-if)# vlan trunk allowed 10,20
switch(config-lag-if)# no shutdown
switch(config)# interface 1/1/1
switch(config-if)# lag 10
switch(config-if)# exit
switch(config)# interface 1/1/2
switch(config-if)# lag 10

The same LAG ID and configuration must exist on both peers; the downstream device bundles its two uplinks through normal LACP and both links stay active, unlike an STP-blocked design. For access-port oriented deployments, review our comparison of ArubaOS-CX access vs trunk VLAN scenarios with LAG.

Synchronizing Configuration with VSX-Sync

Global and interface-level features can be synced from the primary to the secondary so operational changes apply once:

switch(config-vsx)# vsx-sync aaa sflow snmp static-routes time dns ssh
switch(config-if)# vsx-sync access-lists policies qos vlans rate-limits
switch(config-if-vlan)# vsx-sync active-gateways policies

Active gateway (virtual IP) support on VLAN interfaces is what enables an active-active default gateway without VRRP, mirroring the VLT peer-routing model on Dell OS10 VLT.

Active Gateway and Layer 3 Design

An MC-LAG solves Layer 2. Layer 3 needs its own answer, because you do not want one peer to be the only default gateway. AOS-CX provides active gateway: both peers own the same virtual IP and the same virtual MAC on their SVI, and both answer ARP and forward traffic without any VRRP election.

switch(config)# interface vlan 10
switch(config-if-vlan)# ip address 10.10.10.2/24
switch(config-if-vlan)# active-gateway ip 10.10.10.1 mac 00:00:5e:00:01:01
switch(config-if-vlan)# active-gateway ipv6 fe80::1 mac 00:00:5e:00:01:01
switch(config-if-vlan)# vsx-sync active-gateways policies

The peer uses a different SVI address in the same subnet (say 10.10.10.3/24) but the identical virtual IP and MAC. Hosts are configured with 10.10.10.1 as their gateway and reach whichever peer is closest; if that peer fails, the surviving peer answers for the same virtual MAC and the hosts never notice. Routing protocols can be run from each peer independently, or with anycast-style convergence using the same AS/area, whichever your design supports.

Active gateway pairs naturally with VSX-sync, so the virtual IP and MAC are defined once and pushed to the secondary. It also removes the VRRP timers and failover gaps that classic first-hop redundancy designs carry, which is the same idea behind ArubaOS-CX VRRP and active gateway.

Split-Brain, Failure Behaviour and Recovery

The two failure modes worth rehearsing are an ISL failure and a keepalive failure, and they behave differently.

ISL failure with keepalive intact. The pair still knows the peer is alive through the keepalive link, so there is no ambiguity about roles. The primary keeps forwarding; the secondary holds its MC-LAG member ports down so that downstream LACP bundles converge onto the primary only, and MAC/ARP entries learned over the ISL age out. Traffic continues, capacity is halved, and the two switches cannot sync configuration until the ISL returns.

Keepalive failure with the ISL intact. The ISL itself is a heartbeat path, so if the keepalive drops but the ISL survives, the pair usually keeps operating. Treat this as a warning, not a success: restore the keepalive path before you do any maintenance, because the next ISL event will have no second channel to fall back on.

Both links down: split-brain. Each switch can no longer prove that the peer exists, so each may believe it is the primary for the same addresses and VLANs. To keep duplicate traffic off the network, VSX keeps the secondary's ISL and MC-LAG links out of service until synchronization is re-established. Recovery is deliberate rather than automatic: restore the ISL or keepalive, confirm with show vsx status that the peer is reachable and the configuration is in sync, then verify the MC-LAG members are bundled again before you return to normal change windows. Our VSX split-brain recovery walkthrough covers the operational sequence in detail.

One design option deserves caution. Some deployments enable active-forwarding on an MC-LAG so the secondary continues forwarding traffic for that bundle while the ISL is down. That keeps a service up during a fibre fault, at the cost of losing the "one active path" guarantee while the fabric is split. Enable it only where you understand the topology and can accept transient duplicate delivery.

Verification

show vsx status
show vsx brief
show vsx configuration
show lacp 10
show mac-address-table

Check that the ISL and keepalive are up, the role matches the intended primary/secondary, and the MC-LAG shows its members bundled on both peers. Before upgrading or rebooting one peer, confirm VSX sync is complete so the remaining switch can carry traffic; the initial AOS-CX bring-up procedure is covered in our HPE Aruba AOS-CX initial configuration guide.

Upgrades and Maintenance

VSX is one of the few designs where a firmware upgrade can be genuinely low impact, provided you respect the sequence:

1. Confirm sync is complete on both peers (show vsx status, show vsx configuration) and no configuration errors are reported.
2. Upgrade the secondary first. The primary carries all traffic while the secondary reloads; MC-LAG members on the secondary come back and are bundled again automatically.
3. Wait for configuration and state synchronization to finish before touching the other peer. Peak MAC/ARP tables take a moment to converge.
4. Upgrade the primary. Traffic now rides on the freshly upgraded secondary.
5. Verify forwarding on both peers once the pair is back in sync, including that the downstream bundle shows both members bundled.

Avoid changing the ISL or keepalive parameters in the middle of a change window, and never clear the VSX configuration on a live peer just to "reset" a sync problem. Most stubborn sync issues are a version mismatch or a feature that is not eligible for synchronization.

Troubleshooting Common Issues

When in doubt, gather the whole picture before changing anything: show vsx status, show vsx brief, show lacp aggregates and show running-config vsx on both peers will tell you whether you have a link problem, a role problem or a synchronization problem.

Related Reading

• ArubaOS-CX VSX Split-Brain: ISL, Keepalive, Recovery
• ArubaOS-CX VSF Stacking: Link Setup and Member Provisioning
• ArubaOS-CX VRRP and Active Gateway: First Hop Redundancy
• ArubaOS-CX Access vs Trunk Ports: VLAN Scenario with LAGs

原文链接：https://arubanetworking.hpe.com/techdocs/AOS-CX/10.14/HTML/vsx/Content/Chp_Start/get-sta-wit-vsx.htm