1

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
2

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:
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/
guide/book/vss.html

Stackwise

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:  http://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series-switches/
71925-cat3750-create-switch-stks.html

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!