Cisco Virtual Switching Systems (VSS)

Last week I converted our new distribution to VSS. If you haven’t heard anything about Cisco VSS yet, you should check it out. VSS is used on the 6500 chassis if you have the new VS-S720-10G-3C supervisor. The concept of VSS is pretty easy to understand. If you are familiar with stacking 3750 switches, you will understand VSS. Basically, you take two 6500s and make them look like only a single switch to anything that connects to them.

Some reasons to use VSS are to get rid of spanning-tree between the distribution and access layers. You also no longer need to use HSRP. For example, an access switch connecting to your distribution would usually be dual-homed, meaning connecting to two separate distribution switches. With spanning-tree, in most cases, one of the uplinks will be unused for a given vlan. That means if you use 10 Gig uplinks, one is unused and only for redundancy (you can balance vlans to even things out, but that has to be configured). With VSS your access switch would have only one port channel that would actually connect to both distribution switches. From the perspective of the access switch, it’s only connecting to a single switch (even though it’s physically two separate switches). Since we only have one port-channel to the distribution, HSRP or VRRP is not needed. One vlan IP is assigned to the VSS distribution switch, and clients use that as default gw. Load balancing across links is done using the traditional etherchannel hashing algorithm.

Check out

Converting the two switches to VSS is pretty easy actually. The Cisco config guide is a good reference.

Here’s a high-level diagram of VSS being connected to core using multi-chassis etherchannel (MEC).

VSS diagram

I’m using the latest IOS available for the VSS supervisor (SXI release). I’m using the two 10 gig connections between supervisor modules for the VSL link. You can combine that with additional ports on the 10gig line cards as well. I decided to stay with two connections because we have 16 port 10 gig line cards (6716). If you choose to use the 16 port line cards for VSL links, there are some caveats. First, you have to be running the module in performance mode, meaning it now becomes an 8 port card (no over subscription of ports for VSL). Secondly, you have to be running the new SXI code.

The other thing to configure after converting to VSS is the Dual-active protection. Dual-active protection prevents a condition where both switches think they are active. This could happen as a result of a complete VSL link failure. There are three things you can configure for dual-active protection, and I only see the need for two of them. The first is enhanced PAGP, which is enabled by default. This allows the two switches to see each other over a port channel in the event of VSL failure (the device the VSS is connected to via a port channel becomes the pass through device in a sense). The other option is dual-active fast hello packets. To configure this, you can use up to four directly connected links between switches (links become dedicated for this feature).

Here is a screen output of a walk-through for converting the two switches to VSS, using dual-active protection, and creating a MEC between VSS and core1.

VSS upgrade steps


Ted Romer
CCIE No. 21785

8 Responses to “Cisco Virtual Switching Systems (VSS)”

  1. Bryce Trapier says:

    Thank you for posting this. I work in a smaller network, with only a few 6500’s and not enough money for two 6500’s in the lab, so the upgrade scripts and output are really nice to see. Gives a real good idea of what to expect and when to do what. Thanks!

  2. Jim H says:


    I’ve just started testing VSS on two lab switches, to evaluate deployment into our production network, and thought I’d share my experience.

    I started with a config similar to yours, and built a port-chan, though I only put one link into it initially, and planned to add a second later (mainly just so I didn’t have to walk down to the lab to connect the second cable). That was probably a mistake, and I should have just setup from the beginning with the final planned link even though it wasn’t connected yet.

    After first reset from the conversion, things were looking good, and I decided to go ahead and add one more link to the port-channel, but the system gave me an error because I had forgotten to ‘no switchport’ one of them but not the other, and it all went downhill from there. Somehow the two switches got out of sync on what ports they thought were VSL, and I could no longer change the second port that was in L2 mode because it thought it was protected from changes as a VSL, even though it wasn’t in the port-chan yet.

    I thought I’d resolve it by simply powering off the slave chassis, fixing the port-chan and interface changes, and letting it sync to the slave when it rebooted, but then it complained at boot that VSL link counts didn’t match, and the slave stopped at boot in RPR mode, and wouldn’t sync the interface changes I’d made from the primary about VSL ports. Ok, I thought, how about I just shutdown all the ports from the primary so I can get the slave to boot, then manually copy over the config change? Nope, even worse decision that trying to change the ports in the first place.

    I did get the configs to be identical, as far as I could see from the ‘show run’, but something must be getting stored somewhere outside the normal config (like the way it knows which chassis is 1 and which is 2, even though the config sync is identical). The best I could get them to do after this was go active/active simultaneously, and as standard procedure, when an active sup realizes it should go to standby, it reloads. then it reloads again, and again. Once I even had the primary crash with a bug check when the slave started its VSS links.

    So, as best I can tell, you should never EVER, touch the configs if you go active/active, until the slave is back to normal. And probably should be extra careful to double check every port config if trying to add an additional VSL to a working system.

    I ended up just blowing it all away, and reverting to standalone mode, then starting from scratch. So glad I had a pair in the lab to work on first.

  3. Mark Combs says:


    Good article. One questions regarding VSS. We are running VSS throughout our enterprise. One question I had regarding dual-active detection and issue that I have seen. The third option that you did not mention is having an IP BFD link between the two switches in case the VSL links go down. This also allows you not to depend on any other switches outside your core especially since they might not support pagp. I have not been able to get the IP BFD link to work. I have the link configured and excluded from being shutdown in a dual active situation but one switch is suppose to start recovery mode and it doesnt. I might need a code upgrade but not sure. Im running 12.33 SXH3a. Any help or insight you could provide would be great.

    Mark Combs

  4. ted says:


    You’re right, PAGP is not enough by itself (imho). I’m using Dual active fast hello packets along with PAGP. These two should be enough which is why I didn’t go with IP BFD. I’m running 12.33SXI release.


  5. ted says:


    Thanks for sharing your experience. That sounds like a PAIN!

    If I ever add more links to the VSL bundle, I’ll be sure their configs are correct! Did you ever open a case with Cisco to figure out their best practice for adding interfaces?


  6. Jason says:

    Quick question…can you run the VSL etherchannel over say 1 of the sup720 10GB ports, and one off of a 6708 10GB line card port. Thus essentially having 1 port off each sup module, and 1 off of each 6708 line card to make the VSL link?


  7. Juno says:

    I have an operation 6509 chassis with a SUP 720 and WS-X6708-10GE module. I have just added a second 6509 with the same characteristics. My intention is to go with VSS. I added one link from the SUP and one link from the Module from both 6509. I am about to configure the vss but firstly i wanted to make sure that this setup is ok and working. If someone has some previous experience please post.

  8. Scott Vieth says:

    “If you choose to use the 16 port line cards for VSL links, there are some caveats. First, you have to be running the module in performance mode, meaning it now becomes an 8 port card (no over subscription of ports for VSL).”

    1. If you change the entire WS-X6716-10GE to performance mode, it turns into a 4 port card:

    no hw-module switch 1 slot 4 oversubscription

    2. If you change just port group 4 [ports 13-16] to performance mode, it turns into a 13 port card:

    no hw-module switch 1 slot 4 oversubscription port-group 4

    3. If you change two port groups to performance mode, it turns into a 9 port card:

    no hw-module switch 1 slot 4 oversubscription port-group 4
    no hw-module switch 1 slot 4 oversubscription port-group 3

    4. If you change three port groups to performance mode, it turns into a 5 port card

    no hw-module switch 1 slot 4 oversubscription port-group 4
    no hw-module switch 1 slot 4 oversubscription port-group 3
    no hw-module switch 1 slot 4 oversubscription port-group 2

    5. Changing all four of the port groups to performance mode one-at-a-time is the same as changing the whole card with one command (you end up with a four-port 10Gig card).

Leave a Reply

You must be logged in to post a comment.