ArubaOS-CX VSF Stacking: Link Setup and Member Provisioning

2026年9月5日 LOG admin

Virtual Switching Framework (VSF) is ArubaOS-CX stacking: up to ten 6300 (or eight 6200) switches interconnect through standard Ethernet ports and operate as a single logical device with one management plane. The first member becomes the conductor, a manually designated member becomes the standby conductor, and the rest join as ordinary members. This guide covers manual VSF provisioning with CLI commands, auto-stacking, member renumbering and the show commands that validate a healthy stack.

Why stack at all? The obvious answer is port density and a single management IP, but the operational win is simpler than that. A VSF stack presents one control plane, so a spanning-tree domain, a routing adjacency, a link-aggregation group and an 802.1X policy are all configured once and enforced across every physical chassis. Adding a member adds ports without adding a network to manage, and a single VSF link failure does not split the fabric as long as the stack is cabled in a ring.

What VSF Gives You — and What It Does Not

VSF is a single logical switch, which means all members share one running configuration, one IP address for management, one MAC address range for the stack and one software image. That is very different from a pair of switches running first-hop redundancy: there is no VRRP, no active/standby forwarding decision and no half the ports being idle. Every member forwards traffic actively; the conductor's role is control-plane leadership, not traffic forwarding.

What VSF is not is a replacement for a routing protocol or for redundancy between two separate stacks. Two stacks in the same closet are still two devices and need a link between them, typically an aggregation with LACP and spanning tree or a routing adjacency — that is the space where ArubaOS-CX VSX or an MLAG equivalent belongs. VSF also does not make a stack immune to failure: it removes a single point of management-plane failure, and it survives one link break in a ring, but a member that loses power is still a member that loses power, and its ports go down until the stack reconverges.

VSF Topologies and Roles

VSF supports ring and chain topologies. Two VSF links per member are recommended so the stack survives a link failure; a chain has no redundancy. Use DAC cables for the VSF links (50G on the 6300 series, 10G on the 6200 series) and keep every VSF link port at the same speed. All switches in a stack must be the same series.

Ring is the only topology worth deploying in production. In a ring, every member has two paths to every other member; losing one link costs bandwidth on the surviving path but not connectivity. In a chain, a single link failure divides the stack into two independent fragments — each with its own conductor if split detection is not configured — which is precisely the scenario the MAD (multi-active detection) mechanisms described below exist to handle. If the physical layout genuinely cannot be cabled as a ring, accept the chain and configure split detection deliberately rather than discovering it during an outage.

Roles are assigned in a fixed hierarchy. The conductor is the control-plane leader; by default it is member 1, or the member with the lowest ID that is up. The standby conductor is chosen from the vsf secondary-member configuration and takes over if the conductor fails. Every other member is a normal member; all of them forward traffic identically. Because the conductor carries the management plane, its health matters more than its data-plane capacity, which drives two best practices: use identical models for conductor and standby, and power them from different circuits so a single breaker or PDU failure cannot take both leadership roles down at once.

Physical considerations that catch people out: VSF link ports must be capable of the required speed without a split cable or breakout, and mixing 10G and 50G links in the same stack is not supported — every VSF link should run at the same speed so that failover to the surviving path behaves predictably. Stacking a 6200 with a 6300 is not supported at all; the firmware families differ even though the CLI looks identical. Check the model and the supported VSF link count before ordering cables, because the last two ports on a 24-port model are not always available for stacking on every SKU.

Manual VSF Configuration on the Conductor

Member 1 is the conductor by default. Enter the VSF member context and assign the physical ports that carry VSF traffic:


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

Configuring a port as a VSF link removes all existing interface configuration (VLANs, ACLs, QoS, MTU) — that port can only connect to another VSF link. On the second switch (also numbered 1 out of the box), configure its links and then renumber it; the switch reboots with the new member ID:


switch(config)# vsf member 1
switch(vsf-member-1)# link 1 1/1/25
switch(vsf-member-1)# link 2 1/1/26
switch(vsf-member-1)# exit
switch(config)# vsf renumber-to 2

Once the physical VSF links are connected, member 2 reboots and joins the stack automatically, taking the standby (VSF-Standby) role because it was designated with vsf secondary-member 2.

The order of operations matters more than the commands. Configure the VSF links before physically connecting the stack: connecting a link between two switches that both still believe they are member 1 produces a duplicate-ID condition that resolves only by clearing one side. Renumber a joining switch while it is standalone, not after it has joined, because changing the member ID of a live member causes that member to reboot and briefly removes its ports from the stack. If a switch was previously part of another stack, wipe it first — 'erase startup-config' plus 'boot system flash' to the primary image — so it cannot carry stale member IDs or a mismatched configuration revision into the new stack.

On the joining switch, the renumbering command triggers a reboot; the stack configuration itself is not stored locally in the way a standalone config is, so a member that boots without a VSF link to the conductor comes up as a standalone device with the stack's configuration but no peers — a state worth recognising on sight because it looks like a working switch with no uplinks.

Auto-Stacking with the CLI

For factory-default switches wired in a ring on the reserved VSF ports (25/26 on 24-port models, 49/50 on 48-port models), stacking can be fully automatic:


switch(config)# vsf start-auto-stacking

The members reboot one by one and join the stack; the command also provisions member 2 as the standby.

Auto-stacking depends on every switch being at factory defaults with no startup configuration — the feature is blocked on a switch that has been configured, precisely to stop a working device from being absorbed into an unexpected stack. The member IDs are assigned by topology discovery, so the first switch is member 1, its neighbour member 2, and so on around the ring; the numbering therefore follows the cabling, which is convenient in a greenfield deployment and inconvenient when you want a specific switch to be the conductor. Renumber after the stack forms if the IDs do not match your documentation, accepting a reboot per change.

Auto-stacking is also the mechanism zero-touch provisioning uses when a replacement switch arrives, so it is worth knowing that a spare connected to the reserved ports will join the stack on its own. Keep spare switches configured (not at factory default) if you do not want that behaviour, or label the reserved stacking ports so cabling them is a conscious decision.

Member Renumbering and Pre-Provisioning

Member IDs are not just labels — they appear in every interface name (1/1/25 is member 1, slot 1, port 25), so renumbering a member rewrites the interface naming for all of its ports and invalidates any configuration that referenced them by number. Decide the numbering scheme before the first cable is plugged in: the common convention is conductor as 1 and subsequent members in rack order, which makes show vsf readable and physical troubleshooting fast.

Pre-provisioning lets you configure a member that has not arrived yet. On the conductor, you can create the member's VSF links and add interface configuration under its member ID, then leave it alone until the hardware is installed. The switch joins, adopts its ID and inherits the waiting configuration, which turns an overnight replacement into a five-minute job. The requirement is that the pre-provisioned ID must be free and the joining switch must be at factory defaults.

Split Detection and Failure Behaviour

The failure mode to design against is a split stack: two fragments that each elect a conductor and each start answering for the same management IP, the same SVIs and the same LACP system MAC. ArubaOS-CX handles this with multi-active detection, which can use the front-plane VSF links, a dedicated MAD link, or an upstream device such as a switch running the MAD proxy. When a fragment is detected as non-conductor it is placed into a restricted state and its ports are disabled, which preserves the network at the cost of half the stack's data plane. The exact configuration, recovery procedure and the show commands that prove which fragment is active are covered in our VSF split detection and split-brain recovery guide; every production stack should have it configured, because without it a broken ring link quietly becomes two switches fighting over one IP address.

Software Upgrades on a Stack

VSF and feature upgrades on a stack follow a defined sequence because all members must run the same software version. Stage the image into the flash of every member, verify the file size and checksum on each with show images, then either reboot the whole stack at once during a maintenance window or use the supported rolling sequence, which reboots members in an order that keeps the conductor available. A stack that ends up with mixed versions will not form cleanly, and the symptom is members stuck in a rebooting or unjoined state rather than an explicit error — check the version column in show vsf first when a member refuses to stay in the stack.

Verifying and Operating the Stack


switch# show vsf
switch# show vsf link
switch# show vsf member
switch# show vsf detail
switch# show running-config vsf

Read show vsf as a health summary: it lists the member ID, the role (Conductor, Standby, Member), the status (Active, Standby, Booting, Not Joined) and the MAC address of each switch. Every member should read Active except the standby, which reads Standby — a member that stays in Booting or Not Joined has a VSF link problem, a version mismatch or a duplicate member ID. show vsf link proves the links from the topology's point of view, showing both ends and the link state; a link that is physically up but absent from this output means the ports are not configured as VSF links on both sides. show vsf detail adds the timers, the sequence numbers and the topology information that make a split or a slow convergence diagnosable rather than mysterious.

Best practice: use identical models for conductor and standby, power them from different circuits, and never add a new member to a live stack until its configuration revision is reset. Spanning tree prevents loops on VSF link ports while a stack is being provisioned.

The day-two habits that keep a stack healthy are worth stating explicitly. Document the member ID to physical location mapping and keep it next to the rack, because every interface name in a customer ticket references a member number. Monitor the VSF link ports for flap counters — a marginally seated DAC cable produces exactly the kind of intermittent member event that is impossible to diagnose later. Keep the standby's power and uplinks independent of the conductor's so that a rack-level fault cannot remove both leadership roles. And test failover deliberately: pull one VSF link in a maintenance window and confirm that the stack stays together and that show vsf still reports a single conductor, because discovering a split-detection misconfiguration during an incident is far more expensive than finding it on a quiet Tuesday.