Cisco Catalyst 9300 StackWise vs VSS: Which Stacking Technology

When you design the access layer with Cisco Catalyst 9300 switches, the stacking question comes up immediately: do you use StackWise or VSS? The short answer is that Catalyst 9300 uses StackWise (including the newer StackWise Virtual), while VSS is a legacy virtual switching technology designed for Catalyst 6500/4500 chassis. This article explains what each technology actually is and then walks through the practical part — cabling, priorities, member numbering, verification and the day-two operations that a stacking design forces on you. For the full feature-by-feature comparison and platform selection matrix, see our companion article on StackWise vs VSS vs StackWise Virtual; this page is about configuring and verifying a stack that already exists on the bench.

What Is StackWise?

StackWise is Cisco's physical stacking technology: multiple switches are connected with dedicated stack cables into a ring, forming a single logical switch with one management plane, one IP address and one configuration. Catalyst 9300 supports:

• StackWise-1: 80 Gbps stacking bandwidth per switch (16 Gbps per port direction × 2).
• StackWise-480: 480 Gbps per switch (on 9300X), four cables, up to 8 members.
• StackWise Virtual (SVL): virtual stacking over front-panel ports (e.g., 40/100G links) for 9300X, no dedicated stack cable.

Up to 8-9 switches form one stack. One switch is elected active (master) and runs the control plane for the whole stack; a standby takes over on failure.

What Is VSS?

VSS (Virtual Switching System) combines two physical chassis into a single logical switch. It was built for Catalyst 6500 and 4500 E-Series: two supervisors are paired over a Virtual Switch Link (VSL), one becomes active and the other standby, and the two chassis share a single control plane. VSS 144/480 refers to the VSL bandwidth (144 Gbps / 480 Gbps).

Catalyst 9300: StackWise, Not VSS

The Catalyst 9300 platform does not support VSS - it uses StackWise and StackWise Virtual. If you are coming from a 6500 VSS environment, the 9300 equivalent is StackWise Virtual on the 9300X models, which virtualizes two switches over high-speed front-panel ports without dedicated stack cables. The configuration habits transfer, but almost none of the commands do: the VSS switch virtual domain and switchport mode virtual syntax does not exist on IOS-XE stacking, which uses switch <n> priority and stackwise-virtual domain instead.

Comparison Table

Pre-Deployment Checks

Before cabling anything, confirm four things on each chassis. Getting them wrong is the usual reason a new stack never forms:

Switch# show version | include Model|Version|SW Version
Switch# show license summary
Switch# show switch
Switch# show switch stack-ports summary

• Model and stack module. A C9300-48P with an installed C9300-NM-8X or C9300-NM-2Q module supports StackWise-480; the same switch without the module runs StackWise-1 at 80 Gbps.
• Matching IOS-XE version. Members must run the same software release. A new member with a different release joins only after you run install add file flash:<image>.bin activate commit or boot it into the same image. show switch shows the version per member once the stack is up, and the standby's version is the one to match.
• Domain number. All members carry the same domain ID (default 1). A mismatch keeps a member out of the stack even when the cables are correct.
• Cable type. The 9300 uses 0.5 m and 3 m StackWise cables; 9300X uses StackWise-480 cables and the QSFP-based StackWise Virtual links. Mixing the two families in one stack is the most common physical-layer failure.

Building the Stack: Cabling and Power-Up Order

Stack cables are directional. Each switch has two stack ports, and the ring is built by connecting port 1 of member n to port 2 of member n+1, closing back to member 1. The C9300's stack ports are polarity-agnostic at the connector level, but you still want the ring closed: a stack running on a single link has no protection against a cable failure, and a break in a ring simply halves the bandwidth of the path between the two switches adjacent to the break.

For a fresh deployment, follow this order:

1. Power up the switch you intend to be the active member first, and let it finish booting on its own with no cables attached.
2. Connect the stack cables in a ring while all switches are powered off except the first.
3. Power on the remaining members one at a time, waiting for each to join before starting the next.
4. Give the stack a few minutes; members that were powered up later become standby and members in priority order below that.

A stack with a member that was already configured will normally reload into the stack, and its stack-member number is assigned in the order it joined. The console output during a join is the clearest signal that the cabling is right:

%STACKMGR-6-STACK_LINK_CHANGE: Stack port 1 on switch 2 has changed state to UP
%STACKMGR-4-SWITCH_ADDED: Switch 2 has been ADDED to the stack
%STACKMGR-4-STANDBY_ELECTED: Switch 1 is the ACTIVE and switch 2 is the STANDBY

Setting Priority and Renumbering Members

Election is decided first by priority (1-15, default 1), then by MAC address. Never leave the active election to the MAC tiebreak: set an intentional priority so the switch with the most uplinks or the most convenient console access becomes active.

Switch(config)# switch 1 priority 15
Switch(config)# switch 2 priority 14
Switch(config)# switch 3 priority 1

Switch# show switch
Switch/Stack Mac Address : 000c.29e4.8f80 - Local Mac Address
                                           H/W   Current
Switch#  Role        Mac Address     Priority Version  State
------------------------------------------------------------------
 *1       Active      000c.29e4.8f80  15        V07     Ready
  2       Standby     000c.29e4.ab00  14        V07     Ready
  3       Member      000c.29e4.7d80  1         V07     Ready

Priority changes take effect at the next election, not immediately — plan a maintenance window or use switch <n> renumber <m> and reload to make the change stick. Renumbering is the operation that catches people out, because the stack-member number is baked into the interface naming (GigabitEthernet1/0/1, GigabitEthernet2/0/1), and renaming a member rewrites those interface names in the running and startup configuration:

Switch# switch 3 renumber 4
WARNING: Changing the switch number may result in a configuration change for that switch.
The interface configuration associated with the old switch number will remain as a provisioned configuration.

Shut down the interfaces on the member you are renumbering first, move the configuration, then reload the member. If you skip the shutdown, the interfaces come back up with the old configuration still attached to the old interface names, and the ports stay dark.

Verifying the Stack

A healthy stack answers all of these cleanly. Run them after initial build, after any cable work, and after every software upgrade:

Switch# show switch
Switch# show switch detail
Switch# show switch stack-ports
Switch# show switch stack-ring speed
Switch# show switch neighbors
Switch# show switch stack-bandwidth
Switch# show switch stack-port counters
Switch# show platform software fed switch active ifm mappings

show switch detail shows each member's role, state, MAC and both stack ports. Look for "OK" on both ports of every member: a single link in a stack normally shows "OK" on one port and "Down" on the other, and the rest of the report will not tell you that a ring is broken. show switch stack-ring speed should report the ring at the full rate in both directions.

Switch# show switch detail
Switch/Stack Mac Address : 000c.29e4.8f80 - Local Mac Address
                                           H/W   Current
Switch#  Role        Mac Address     Priority Version  State
------------------------------------------------------------------
 *1       Active      000c.29e4.8f80  15        V07     Ready
  2       Standby     000c.29e4.ab00  14        V07     Ready
  3       Member      000c.29e4.7d80  1         V07     Ready

        Stack Port Status             Neighbors
Switch#  Port 1   Port 2           Port 1   Port 2
------------------------------------------------------
  1       OK       OK               3        2
  2       OK       OK               1        3
  3       OK       OK               2        1

Console Access to Other Members

One of the operational wins of a stack is that you can reach any member's console from the active switch without a serial cable. Two commands do it, and the difference matters in automation:

Switch# remote command switch 2 show version
Switch# session switch 3
Switch# show switch detail | include Role|Member

remote command switch <n> <command> runs a single command on another member and returns its output to your session. session switch <n> opens a full CLI session on that member, which is useful for a brownfield member whose ports behave differently; exit returns you to the active switch.

Adding a Member to a Live Stack

Hot-add is supported and does not reboot the existing stack, provided three conditions hold: the new switch runs the same IOS-XE release, its interface configuration is empty or provisioned, and its priority is not higher than the current active member. Bring the new switch up standalone first and wipe its configuration:

Switch# erase startup-config
Switch# reload

! Then cable it into the ring, with the stack powered on
Switch# show switch
! State should go from "Waiting" to "Ready" within a few minutes

Switch(config)# switch 4 priority 1
Switch(config)# interface range GigabitEthernet4/0/1 - 48
Switch(config-if-range)# shutdown

Shut the new member's interfaces before you start configuring them. A freshly joined member inherits the stack's global configuration (VLANs, STP settings, AAA) but not interface-level configuration, so the ports stay administratively down until you configure them — which is the correct and safe default.

Removing or Replacing a Failed Member

If a member fails outright, the stack keeps forwarding through the remaining members and the failed switch's interfaces go down. Protocol-wise there is a brief reconvergence; data-plane traffic on the surviving members is unaffected. Replace it with these steps:

1. Record the old member's interface configuration: show run interface GigabitEthernet3/0/1 for each port, or show run | section ^interface GigabitEthernet3/.
2. Remove the failed member from the stack in the configuration with no switch 3 provision if it was provisioned.
3. Cable the replacement, let it join, assign the priority, then paste the interface configuration back under the new member number.

Because the member number in the interface name is positional, replacing member 3 with a switch that joins as member 4 means either renumbering the new member to 3 (cleaner) or reconfiguring the ports with a different prefix. Renumbering is usually faster. Stack split-brain, dual-active and recovery scenarios are covered in depth in our Catalyst 9300 split stack troubleshooting guide.

Software Upgrades in a Stack

In install mode, the upgrade is a four-step operation and the stack keeps forwarding throughout the activate step where ISSU is supported. Always copy the image to every member — the file system is per-member, and the stack does not replicate it:

Switch# install add file flash:cat9k_iosxe.17.09.04a.SPA.bin activate commit
Switch# install commit
Switch# show install summary
Switch# reload

Before any upgrade, note the current state of show switch and show switch stack-ports. If a stack link is already degraded, fix the cable first: an upgrade that triggers a failover on a stack with one working link can leave members isolated.

Configuring StackWise Virtual on 9300X

StackWise Virtual is built for the two-switch case and uses front-panel high-speed ports for the SVL instead of a dedicated stack cable. Configure it as follows on both switches, differing only in the domain interface IPs:

Switch1(config)# stackwise-virtual
Switch1(config-stackwise-virtual)# domain 1
Switch1(config-stackwise-virtual)# exit
Switch1(config)# interface range FortyGigabitEthernet1/1/1 - 2
Switch1(config-if-range)# stackwise-virtual link 1

Switch1(config)# interface GigabitEthernet1/0/1
Switch1(config-if)# stackwise-virtual dual-active-detection

Four rules matter more than the syntax. The domain number must match on both switches. Both members need at least one physical link marked stackwise-virtual link and each must be a QSFP/QSFP28 port. Dual-active detection needs its own dedicated physical link — never share it with ordinary data VLANs, because a DAD failure during a split is what causes both halves to believe they are active. And configure the DAD link on both members, not just one.

Switch1# show stackwise-virtual
Switch1# show stackwise-virtual link
Switch1# show stackwise-virtual dual-active-detection
Switch1# show stackwise-virtual neighbors

During a split, the secondary member's SVL links go down and DAD triggers over the dedicated link. The secondary enters recovery mode and shuts its interfaces except the DAD-capable ones, which is why uplinks must be distributed across both members: if every uplink is on the member that enters recovery, the network loses its path even though the failover "worked".

Design and Operational Best Practices

• Use stackwise-virtual dual-active detection on SVL deployments to detect split-brain, and always on a dedicated link.
• Distribute uplinks across members - never terminate all uplinks on the active switch.
• Set explicit priorities rather than relying on the MAC-address tiebreak; document which member is intended to be active.
• Run a full ring, not a single cable run, and keep one spare stack cable per closet.
• Upgrade software with install add and ISSU where supported to avoid whole-stack reloads.

Which One Should You Use?

• Access layer with many closets → StackWise (up to 8 members, one management point).
• Two high-end access switches with 40/100G uplinks → StackWise Virtual.
• Legacy 6500/4500 core → VSS (only if you still run those platforms).

The bandwidth differences between StackWise generations and the upgrade paths between them are broken down in Catalyst 9300 StackWise: 320, 480 and 1T bandwidth explained.

FAQ

Can a Catalyst 9300 run VSS? No. VSS is a Catalyst 6500/4500 feature. On 9300 and 9300X use StackWise or StackWise Virtual.

What happens to traffic when the active switch in a stack fails? The standby takes over the control plane in under a second; the remaining members keep forwarding and their MAC address tables stay populated, so most sessions survive.

Can I mix C9300 and C9300X in one stack? Yes for StackWise-480 if the hardware supports it, but you lose the benefit of the faster link for older members and you must run a software release supported by both. In practice, keep a stack homogeneous.

Do I need a stack cable on every switch? Yes for a ring. Configure a ring whenever possible; a daisy chain leaves the stack with a single point of failure between adjacent members.

Related: Cisco Nexus vPC failover scenarios and H3C IRF stacking configuration and troubleshooting.

原文链接：https://www.cisco.com/c/en/us/support/docs/switches/catalyst-9300-series-switches/216214-understand-stackwise-480-technology-on-cata.html