ArubaOS-Switch Stacking - Backplane and VSF

- networking aruba ospf

Backplane Stacking

Backplane stacking works like any other vendor, connect multiple switches to manage them as one logical device. Supported models are listed below. Generally, a stacking module is an add-on and not included in the base config. The maximum stacking cable length is 3m - this can have design/architecture implications, as you can’t backplane stack between closets.

Stacks can be cabled in up to 3 ways, depending on the device type: mesh, ring, or chain.

When the stack is formed, the commander generates a stack ID and informs all stack members of this ID. If the commander is replaced later, this stack ID remains the same.

Basic Stack Configuration

Sometimes it is necessary to enable stacking (if the switch was configured before a stacking module was installed).

switch(config)# stacking enable

Devices in stacks have three roles: commander, standby member, and member. The commander manages the stack and runs all routing switching protocols. There should only be one commander at any time. The standby member is the next-in-line to become commander if the commander fails. During a failure, a new standby member will be elected. All other switches are member switches.

If you’d like the same member to always be commander, you can set a priority. Highest priority wins. To find IDs of members, run ‘show stacking’.

switch(config)# stacking member 1 priority 255

When all switches are rebooted at the same time, the following member election process occurs and a commander is selected based on the following criteria.


When stacked, all console ports on member switches redirect to the commander’s console port. Each switch still can have its own OOBM IP and an additional Global OOBM IP for the stack. It is best practice to configure all of these, to assist recovery in a split-brain scenario.

Failure Modes

When a switch fails and breaks the stack, the segment with fewer members automatically disables itself. If the stack fragments are equal and OOBM is enabled, the fragment with the commander will remain active and the other will be disabled. If OOBM is not enabled/configured, both fragments will remain active and attempt to use the Global OOBM IP configured on the stack. This can cause even more issues than were occuring. Once the fragments are reconnected, the switches in the inactive segment reboot and assume their assigned roles in the stack.

Renumbering a stack member

To swap switch 2 and 3:

switch(config)# stack member 3 remove 
switch(config)# stack member 2 remove
switch(config)# stack member 2 type <type> mac-address <MAC address>

Remove a stack member

switch(config)# stack member <#> remove 

If removing the commander, it is a good idea to force failover to the standby first:

switch(config)# redundancy switchover
switch(config)# stack member <#> remove 


VSF stands for Virtual Switching Framework. VSF virtualizes multiple physical devices into one virtual fabric for HA and fast recovery. VSF switches are connected through Ethernet connections. The currently supported models are below. One of the advantages of VSF is it just 10GbE ports, allowing for VSF clusters to be stretched within a campus.

“Plug-and-play” VSF

For the “plug-and-play” VSF installation method, first configure the commander, then connect (factory default) standby members. During the boot of the standby members, they should auto-join the stack. Some priotips:

The switch will then reboot. Now, connect the standby member (set to factory default) to the VSF ports and power the standby switch up. It will automatically get its VSF configuration and settings from the commander.

Manual Provisioning VSF

If you have multiple switches of the same model in your environment and you want to be sure the correct switches join the correct VSF, manual provisioning is the way to go. Manual provisioning of VSF has two modes - loose and strict. WIth loose provisioning, the model number is set in the configuration. In strict provisioning, the model type and mac-address is specified.

loose - 
switch(config)# vsf member 2 type j9850a
strict - 
switch(config)# vsf member 2 type j9850a beefbe-efbeef

When manual provisioning is completed, the new device’s interfaces are available to configure in the command line. This allows pre-configuration of ports on the new member switch before it has joined the VSF.

VSF - Split Brain & MAD

MAD stands for multiple active detection. When the VSF devices lose their VSF link, they attempt to determine if the other member is still active. If so, the standby member shuts down all of its ports to prevent mulptiple active switches. There are three types for VSF - OOBM, LLDP, and VLAN.

OOBM MAD is supported by the 5400R zl2 platform. Each device needs its own OOBM IP outside of the global IP. These OOBM IPs need to be able to talk to each other, either on a dedicated link or an OOBM management network. In a failure scenario, the devices use the OOBM connection to determien if the other member is still alive. If it is, the standby member shuts down all ports.

LLDP MAD is supposed by the 5400R zl2 and 2930F. It utilizes a switch that has an LACP port group that connects to both switches. This helper switch must have an IP address that the VSF members can reach. Additionally, it needs to have an SNMPv2c read community configured and SNMP enabled. The LLDP MAD configuration specifies the helper switch’s IP address. When the VSF link fails, the standby sends an SNMP query to the helper switch, reading LLDP information to see if the helper switch is still connected to the VSF commander. Based on the response, the standby device does one of the following:

VLAN MAD is supposed by the 2930F. This MAD type uses a dedicated VLAN for MAD that is set as untagged on 1 port on each member, connected to an intermediary switch. When there are more than 2 VSF members, all members must have an untagged port on this VLAN. This VLAN must have an IP address assigned. The VSF members will then ensure reachability to other members on this VLAN and provide similar logic to LLDP MAD in a VSF link failure scenario.

VSF vs Backplane - Traffic forwarding and flooding

Unicast Forwarding

Flooded Traffic

Fast Software Update (FSU)

VSF switches support fast software update to minimize outages during update windows. With FSU, the software is downloaded onto the VSF and the standby is updated first, then rebooted. After it comes back online, the standby updates and reboots the commander, becoming the commander itself in the process. The former commander reboots and becomes standby upon re-joining the VSF.