A fairly common design choice to be faced with during deployments, is whether to use Stacking, Standalone, or vPC/VLT (a dual control plane implementation of MLAG) model, in the different layers of the switching infrastructure. This post draws a comparison between Stacking and Standalone models. A different post draws the comparison between stacking and VLT/vPC models.
|STACKED CONFIGURATION||STAND-ALONE CONFIGURATION|
|a||Aggregate Channel groups can be created across the stack. This will add to the resilience of the blade chassis I/O design||Aggregate Channel groups cannot be split across the standalone switches. Thus, these must terminate on a single switch.|
|b||Any downtime resulting from a master failure, scheduled maintenance or firmware upgrade would cause the entire stack to go down. In a 24/7 environment or where maintenance windows cannot be provisioned, this can become significant as communication across either the entire data or iSCSI backplane is lost for the duration.||Loss of a either of the switches dedicated to a function ( Data or iSCSI) will not take down the entire data or iSCSI path, as the other switch providing the same functionality remains available. Thus, firmware updates or maintenance can be performed in isolation on each switch while retaining the path for the data or iSCSI function through the other switch.|
|c||Since the stack is a single logical chassis, it allows for easier, unified management of the stack via a single IP address.||Switches have to be managed individually.|
|d||Where dedicated stacking ports are used, Stacking speed is 24gb/s (Full Duplex).||Port trunk max speed is 8gb/s.|
|e||With a stacked configuration, the channel between stacked blades & any upstream (Core/Storage/Separate Tier) stacked switches, becomes a single channel between two logical chassis. Thus STP considerations are minimal as only two end-points are involved, and uplinks are LAGged.||In stand-alone configuration, with the external switches stacked, each blade switch dedicated to one function (Data or iSCSI) uplinks individually to the external switch stack. STP would remain a consideration. The two blade switches for any one function cannot be interconnected, as this would form a closed loop and cause STP to potentially block one of the uplinks from either of the two switches.|
When it comes to Stacking, there are a few things to be mindful of.
- First, in a stack, the fabric control panel is active only on the master, while the data plane is active on all units.
- Second, Only the master retains and controls configuration, route tables, ARP mappings etc. It synchronizes this with the backup switch if one is present, every two minutes, but any other member switches will not be synched.
- Lastly, during any master failover, all ports on all units in the stack are effectively recycled to avoid possible loops, owing to topology change, and ensure consistent config on the new master. All communications across the data plane on the switches are affected because of this.
When stacked, the configuration for the stack is stored on the Master switch. When a standalone switch is added to the stack, its standalone configuration is hidden from the stack and it must be configured on the Master. When a switch is removed from the stack, it will once again regain its standalone configuration. If a stackport link went down, the immediate result would be the switch reverting to standalone mode. (If a switch cannot detect a stacking partner on a port enabled for stacking, the switch will operate as standalone. If a stacking partner is detected, the switch will always operate in stacking mode). The “standalone” config is effectively the default config, may well be a blank config. If, then, the switch regains communication on the stackport, or is joined back to a stack, it will immediately try and transition to stacking mode once it has detected the carrier on the stackport and negotiated parameters ( stackport itself must be in stacking mode, ofcourse).
You can insert and remove switches to/from the current stack without cycling the power. The entire network may be affected when a topology change occurs, as a stack reconfiguration will take place. A new Master Switch will not be re-elected, unless the Master Switch was removed from the stack. Stack reconfiguration takes a maximum of two minutes in a stack of twelve switches, less time for smaller stacks.
Resync of the stack is by design. When the stack renegotiates after a Master failure/reset, the slave switch then “resets” itself to become the master. This stops ALL communication between any hosts/devices connected to this switch (every LED goes out like it is being reset). The communication then comes back once the switch becomes the Master. If you Master fails, you’ll lose connectivity for about a little more than a minute which may be too long in a redundant environment.
You can manage the entire stack through the IP address of the Master Switch. During the stack formation process, every switch is assigned a Stack ID. Once Stack ID assignment is complete, each switch saves its Stack ID into the nonvolatile FLASH memory. Following Stack ID assignment, the Master Switch performs a consistency check to make sure that all switches are running the same firmware version. If not, then the ports on the member switch will not become valid for operation. This is known as the Suspended Stacking Mode. If the Master Switch determines that all switches are running the same firmware, the switch will be initialized for Stacking Mode.