Time to discuss some technologies I had the chance to work with: StackWise and StackPower.

Stackwise in theoryStackwise Cable

First StackWise. It is supported on the 3750 series of switches: 3750v2, 3750E and 3750X. On the rear side of these models, there are two stack ports. By connecting several switches together using these stack ports, one big logical switch is created. It’s possible to connect up to nine switches, and for once, you can do a ‘loop connect’ with the stack cables.StackwiseBandwidth

In each direction, a stack cable gives 16 Gbps bandwidth, making for a total bandwidth of 32 Gbps. Since the stack creates one logical switch, the stack ‘ring’ does not participate in spanning-tree and no stack port is ever put in blocking state, and the stack is manageable through one single management IP. Yes, it shows a whopping 432 ports for a stack of nine 48-port switches. Another benefit is that port-channels can be terminated over multiple physical switches in the same stack (I’ve already written about that).

The switches choose a stack master among themselves. This one is the ‘master’ switch, in control of everything. Master switches are chosen on various factors, but in practice, switch priority (configurable) and the first to boot are usually key to the master election process.

The 3750E and 3750X series support StackWise Plus. This is an enchancement on StackWise with better switching decisions, making less intensive use of the stack cable bandwidth. Cisco claims up to 64 Gbps backplane switching with this, but I haven’t found any solid evidence if it can really reach this speed and what would be the actual technique to reach that speed. Different switch models can be mixed in one stack, but if a 3750v2 is present, the entire stack will not use StackWise Plus anymore.

Stackwise commands
There are some useful commands for a stack, especially for the initial setup. ‘show switch’ is the first and most useful: it shows which switches are present in the stack and their priority. ‘show version’ shows the IOS version of each switch. Best practice is to keep them the same. Also, next to the usual ‘show flash:’ you can also use ‘show flashx:’, where x is the number of the switch in the stack to show an individual flash. The running config is stored on each flash, but the flash by itself does not synchronize and thus may differ.

For configuration: ‘switch x priority y‘ sets the switch’s priority for the master election, with y a number between 1 and 15, where 15 is the highest priority. ‘switch x renumber y’ changes switch numbers, so you can make the numbering the same as the physical layout (e.g. the top switch is number 1, the one below that 2, and so on). Unfortunately, both these commands require a reboot of the stack to apply the changes. Best practice would be to do this during the initial setup so you don’t have to fiddle around later.

Stackwise in practice
I have to admit that Stackwise is less impressive in the real world than on paper. Port-channel over multiple switches works, the backplane has plenty of bandwidth, management is easy through one IP, that’s true. But the design of Stackwise is made so the loss of one switch in the stack or a stack cable will not bring down the entire stack or port-channels. But the stack-cables are of good quality and I’ve never heard of one failing so far, and while switches do go down sometimes due to power failures, it’s not the only cause. If the stack is down on his knees due to a bug, a bridging loop somewhere in the network, or anything else that makes it top to 100% CPU, it tends to react bad, flooding the backplane at times, through the stacking cables, making a loop with itself. While this does not cause any trouble in a working network, it does amplify existing issues. The chassis-based switches like 4000 and 6500 series, while vastly more expensive, do not have this behaviour. And similar to the chassis-based switches, upgrading the IOS does require the entire stack to reboot. Upgrading the IOS can also be a pain because the stack needs to have enough free space on all flash or upgrading does not work, so you have to check (and clean) this manually on each flash before proceeding. Even then, the actual upgrade takes significantly longer in a stack, with the CPU spiking to 100% during IOS install.

StackPower in theory
StackPower is relatively new. It’s a feature on the 3560X and 3750X series of switches.

StackPowerSetupBy connecting them together with special StackPower cables, they share their power supplies into one big pool. You can connect up to four switches together this way, and they don’t necessarely have to be connected bij StackWise. Since the 3560X and 3750X series both support PoE+ and redundant, hot-swappable power supplies, it’s a serious advantage in the design. Should the power supply of one of these switches fail, then power can be drawn from other power supplies in the stack to keep the switch running, assuming there’s enough power left to do so. The switches support two power supplies with up to 1100W per power supply, so a fully loaded stack of four switches can power up to 8800W. If the switches are deployed in an office environment depending heavily on PoE for IP Phones, access points, and so on, then the added power redundancy is welcome. It also requires less backup power supplies to be present: one extra power supply per four switches, instead of per switch, still guarantees redundancy.

StackPower commands
It’s relatively easy to configure: plug in the cables, create a common group name, activate the ports. Creating a group name is done with ‘stack-power stack name‘. The name has to match of course. After entering the command, the CLI allows you to set the power sharing mode: ‘mode power-shared strict’ or ‘mode power-shared non-strict’. Non-strict allows the switches to exceed the power budget if deemed necessary in case of failures, strict does not do this. I personally prefer strict to play safe.
Activating the StackPower ports is not that clearly explained by Cisco. First type ‘stack-power switch x‘, and in this configuration mode, type ‘no standalone’.
Because these are PoE switches, if there’s not enough power left to power every switch in the stack, the switches will stop giving power to PoE devices up to the point where there’s enough power to keep all switches running. It’s possible to influence the decisions made in this process: in interface configuration mode, ‘power inline port priority high’ will assign a higher priority to a PoE port, which will make sure PoE is not taken away from this port until there are no other PoE ports left.

Troubleshooting commands are ‘show env power all’, ‘show stack-power’, and ‘show power inline’. These contain all info that is needed.

StackPower in practice
There’s only one downside in practice: the switches need an IP Base or IP Services IOS licence. LAN Base does not support it. I’ve only had limited experience with it so far, but it seems to do what it promises: failure of a power supply does not cause any disruptions.