Chassis Virtualization


What’s better than having two high-performance core switches in your network environment?  How about having just one!  Wait a minute… that seems backwards, right?  Well, certainly from a hardware redundancy standpoint, having more than one is better, but there are a lot of perspectives from which two aren’t necessarily better than one.  Most of these perspectives are administrative.  For one, the more switches you have, the more switches you have to manage.  Not only does that increase the demand on Network Engineers, but it makes more room for administrative error.  (Yes, contrary to popular opinion, Network Engineers DO make mistakes)  Further, spanning-tree can be a little bit evil.  Rather than running STP between a pair of switches, there are situations where we have the option of running the switches as a single chassis and no longer needing to run STP between them.  Finally, if you virtualize two Cisco switches into a single one, Cisco will sell them to you for the price of one.  Ok, that last one is a lie.  (Just making sure you’re paying attention!)  But the others are still pretty darn good reasons to virtualize our chassis when we can!  Here’s our Exam Blueprint topics:

2.1.h Describe chassis virtualization and aggregation technologies
2.1.h [ii] VSS concepts
2.1.h [iv] Stackwise

VSS Concepts

First off, Virtual Switching System (VSS) is very platform-specific.  Currently, it can only be run on certain 6500, 6800 and 4500 series switches.  There will be exactly two switches in a VSS domain.  VSS works by bundling links into a port-channel and dedicating this port-channel to the purposes of communicating between the two switches in the VSS domain, and for forwarding data traffic flowing between chasses.  This port-channel is call the Virtual Switch Link (VSL).  These port-channel links are not physically separate ports dedicated to VSS functions.  Rather, they are used from the actual interfaces on the switch, and it is by configuration that they are considered VsL links.

To configure VSS, first start by configuring both switches to be in the same VSS domain with the switch virtual domain # command.  This brings you into VSS domain config mode.  From here, configure one of the switches with the switch 1 command and the other with the switch 2 command.  Next, find two different port-channel numbers that are currently unused on BOTH switches.  On a production switch, it’s easy to grab a port-channel number that’s available in one switch, but forgetting to check to see if that interface number is available on the other switch as well.  This becomes important when the two chasses merge and become one.  After you have two port-channel numbers available, create them and dedicate them to the VSS domain.  Do this by creating a port-channel as you normally would with the interface port-channel # command, and then, in port-channel configuration mode, use the switch virtual link # command, where link # is the same as the switch # that was assigned in the VSS domain config.  Lastly, add physical interfaces to the port-channels as you normally would.

At this point, the minimum configuration is done and you can now activate VSS with the switch convert mode virtual command.  This command needs to be run on both switches.  The switches will reboot and upon doing so, will be running as a single virtual switch.

A few key show commands to keep in mind are the show switch virtual command, the show switch virtual role command, show switch virtual link command, and show switch virtual link port-channel commands.  Unfortunately, I don’t happen to have a pair of 6509s sitting in my living room, so I can’t provide any examples here, but Cisco’s VSS Configuration guide has plenty of examples and details if you want to learn more about VSS:


After reading the VSS section, Stackwise is going to seem like a breeze!  First, Stackwise has dedicated physical interfaces and cables.  After you plug them in… they just work.  Seriously, it’s that easy!  You can verify Stackwise operation with the show switch command, the show switch stack-ports command, and the show switch neighbors command.  If you need to reload an individual stack member, you can do so with the reload slot # command.  You can also manually renumber the switches with the global config switch # renumber new-# command.  It is common to let the top switch (as in physically on top of the others) as #1 and just count on as you go down the switch.

When the switches in the stack come up, they will elect a master switch to run the stack.  If you prefer to set this, you can do so with the switch # priority # command.  The default is 1 and potential values range from 1 to 15, with higher values being better.  Again, I don’t have a stack sitting around to provide examples, but Cisco’s documentation is pretty solid here again:


We’re getting closer every day to the end of our Layer 2 discussions!  Thanks again for stopping by, and please stay tuned – there are some exciting things coming down the pipe for the HAT community, and some great topics for discussion ahead as we he our stride with Layer 3!

Leave a Comment

Your email address will not be published. Required fields are marked *