ArubaOS-CX VSF Stacking: Roles and VSF Links

VSF turns a group of ArubaOS-CX access switches into a single logical device with one control plane, one configuration file and one management IP. Unlike VSX, which virtualizes the control plane of two aggregation switches while keeping their data planes independent, VSF is a genuine stack: one member is the conductor, the rest are effectively line cards. The design decisions that cause trouble later are made at the very start — member IDs, link assignment, ring versus chain, and whether you let auto-stacking do the work. Here is the whole sequence, plus what the roles actually mean.

Roles: primary, secondary, conductor, standby

Two sets of terms describe the same stack, and the CLI uses both. The primary member is always member 1 and normally holds the conductor role; the secondary is any other member ID you nominate, and it normally holds standby. The conductor owns the configuration database, the software images and the control plane. The standby keeps a synchronized copy and takes over if connectivity to the conductor is lost. Every other member runs no protocols at all — its interfaces are programmed directly by the conductor.

Building the stack manually

Manual link configuration gives you a deterministic result and is the sane choice for anything beyond a two-switch bench test. Links are defined per member, and the port numbering is member/slot/port.

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

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

switch(config)# vsf secondary-member 2
switch(config)# exit
switch# write memory
switch# boot system

Two ordering rules matter. The VSF link on member 2 points at its own physical ports — the numbering is local to each member, not to the conductor — and the secondary member should be nominated before the members reboot, otherwise the standby election happens by default priorities and you get a different member than intended.

Designating a member that is already in the stack as secondary forces it to reboot and rejoin in the standby role; designating an absent member means it joins straight into standby without an extra reboot. Removing the designation from a present secondary also triggers a reboot.

Ring or chain

A ring gives every member a VSF link to two neighbours, so a single link or member failure does not partition the stack. A chain is simpler and cheaper in ports but any break splits the stack into two independent islands. Aruba recommends ring topology wherever the hardware allows. Ring also matters for in-service software upgrade, which depends on the stack being able to reach every member through an alternate path while one member reboots.

Auto-stacking versus manual

Auto-stacking provisions members with a single command and is fine for a rack of identical switches that are being deployed together. The catch is that member IDs are assigned in the order switches are discovered, so two stacks built from the same template can end up with different member numbering. If your monitoring, port naming or configuration snippets reference 1/1/x and 2/1/x, that inconsistency becomes a support call. Manual configuration costs a few minutes and removes the ambiguity.

Verification

switch# show vsf
switch# show vsf detail
switch# show vsf link
switch# show vsf topology
switch# show vsf member configuration

show vsf gives the summary — role, member IDs, software versions. show vsf link confirms both directions of every VSF link are up; a link that is up on one member and down on the other is almost always a mismatched port assignment rather than a bad cable. show vsf detail exposes the conductor and standby election state, and after a member failure the stack reports the reason. Before declaring the build complete, confirm that all members run the same firmware: a version mismatch prevents members from joining, and the stack logs the reason more clearly than the CLI banners do.

Where VSF ends and VSX begins

VSF applies to the access layer (4100i, 6100, 6200, 6300 families within the supported releases), while VSX is a two-chassis aggregation construct with independent control planes and an inter-switch link. Cloud-managed environments use the same terminology but configure both through Central profiles rather than local CLI. If you are working at the aggregation layer or need hitless upgrade of two large chassis, the MC-LAG approach in ArubaOS-CX VSX configuration is the right starting point rather than a stack. On the access switches, once the stack is up, apply the usual hardening: queue profiles and trust boundaries as described in ArubaOS-CX QoS trust and queue profiles, and port authentication per ArubaOS-CX 802.1X port access.

原文链接：https://arubanetworking.hpe.com/techdocs/AOS-CX/10.16/PDF/vsf.pdf