Switch Stacking and Redundancy Playbook

What stacking gives the client

On supported platforms, stacking can provide one management/control plane, higher port density and resiliency. Cisco documents StackWise stacks as a unified system and supports full-ring topologies that preserve a second stack path if one stack link fails.

Before adding a member

• Check exact model stacking compatibility.
• Check software version compatibility.
• Check license level.
• Check install/bundle mode where relevant.
• Plan stack member numbers and priorities.
• Use the correct stack cable and respect its bend radius.

Cisco's current StackWise troubleshooting guidance warns against connecting a powered-on new member into a powered-on stack because stack merge behaviour can cause reloads. Follow the exact platform procedure.

Ring state matters

A half-ring can still operate, but it has lost the redundant stack path and may have lower available stack bandwidth. Verify the stack ring after any cabling change.

Typical verification

show switch
show switch stack-ring speed
show redundancy states
show version

Do not confuse stacking with uplink redundancy

A healthy stack still needs resilient uplinks, power and upstream design. Two stack members connected to the same single upstream switch and same power circuit still share those failure domains.

Replacement procedure

Document the failed member number, interface configuration and cabling before removal. Prepare the replacement software/license state and follow the vendor procedure so port numbering and stack role do not surprise the network.

Acceptance checklist

• All expected members visible.
• Full ring state where designed.
• Active and standby state healthy where supported.
• Member software/licensing consistent.
• Uplink/LACP paths tested across member failure.
• Stack and uplink cables labelled at both ends.

Power redundancy

Stack redundancy is incomplete when every member depends on one electrical circuit. Map each switch power supply to its PDU and upstream UPS/circuit. Where dual supplies are used, verify that the two feeds are genuinely independent if the design claims power-path resilience.

Uplink placement

Distribute uplinks across stack members where the platform/design supports it. This can keep upstream connectivity available if one member fails. Verify the logical port channel still has active members after the selected chassis is removed or powered down.

Replacement preparation

Keep a record of stack model compatibility, software image, member number, license and uplink/patch mapping. An emergency replacement is faster when the spare can be prepared before it reaches the rack.

Stack member numbering

Persistent member numbers make cabling and port references predictable. Before adding a replacement switch, confirm whether the platform preserves the removed member's number and configuration or whether manual renumbering is needed. Record this in the replacement runbook.

Software upgrade planning

A stack upgrade is a system change, not several unrelated switch upgrades. Confirm supported versions, boot mode, free flash, upgrade method, expected reload behaviour and rollback plan. Keep console access available because a failed upgrade can affect the whole logical switch.

Stack split risk

If the stack ring is incomplete and another stack link fails, members can become partitioned. The practical lesson is to treat a half-ring alarm as a resilience fault even while user traffic still works.

Port-channel design across members

Where the platform supports cross-stack EtherChannel, place member links on different stack switches so one member failure does not remove the entire uplink. Then test the actual member failure, not only a single cable pull.

Operational documentation

• Member number and serial number.
• Rack U position.
• Stack cable A and B destinations.
• Power feed/PDU.
• Uplink member ports.
• Software version and boot mode.