Switch Stacking and Redundancy

In theory, a hardware failure on one member of a switch stack will only cause the physical interfaces of that member switch to go down. Uplinks and access ports on other switches will remain online. The “failover” may be faster than a redundant spanning-tree failover. The single spanning tree instance can also prevent outages, particularly in desktop networks where people are plugging in desktop switches.

I encountered two types of problems with redundant switch stacks in production (although most of this was with the VSS cat6k feature, or with Juniper SRX firewall clusters).

1. The switch stack failover software itself is complicated, and can fail. In effect you have a single control plane. It tries to never fail. It is not always successful.
2. Software upgrades are particularly dangerous. I’ve run into several “clustered switch” implementations where the upgrade procedure was exceedingly complex (In some cases you had to “break the cluster” as part of the procedure) or where you had to simultaneously reboot both members. Sometimes these upgrade issues only applied to major version number changes but not minor version number changes.

So switch stacks improve redundancy for some types of failures, but increase complexity and impair redundancy for other situations (most notably upgrades).

I personally found switch stacks very helpful in desktop networks (where obtaining a scheduled outage for an impacting upgrade after-hours was not a problem). In the datacenter, where obtaining impacting change windows was almost impossible, I avoided using switch stacks (at least if a server had redundant Ethernet nics, have the two interfaces go to fully independent switches).