VSS Configuration

NetCraftsmen®

Cisco VSS Configuration – Looking to install VSS ? Well, recently I had the opportunity to install VSS in a customer’s Data Center as part of a complete network migration from an old Nortel Switch network to a new Cisco network using primarily Catalyst 6509 switches with Sup 720 – 10 G Supervisors.

Before I begin, let me point you to the Cisco docs that will serve you well. All are in the Documentation area of Cisco’s Web site under:  Products – LAN Switches – Cisco Catalyst 6500 Virtual Switching System 1440

Catalyst 6500 Release 12.2SXH and Later Software Configuration Guide
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vss.html

Cisco Catalyst 6500 Virtual Switching System Deployment Best Practices
http://www.cisco.com/en/US/products/ps9336/products_tech_note09186a0080a7c837.shtml

Replace Supervisor Module in Cisco Catalyst 6500 Virtual Switching System 1440
http://www.cisco.com/en/US/products/ps9336/products_configuration_example09186a0080a64891.shtml

It is not my intention to rewrite the Configuration Guide. My goal here is to provide you with the commands necessary to get VSS up and running. However, there are some hardware and software requirements which I will repeat. Because without them, this isn’t going to work.

Hardware Requirements/Restrictions

Chassis and Supervisor Requirements

2) 6500 Chassis capable of running VS-S720-10G supervisor engines and WS-X670X-10GE switching modules. (6704, 6708 and 6716)

2) Sup 720s. They must both be the same so either (2) VS-S720-10G-3C or (2) VS-S720-10G-3CXL

This is important. While in a Cisco lab we spun our wheels wondering why VSS wasn’t coming up. We had inadvertently put a VS-S720-10G-3C in one chassis and a VS-S720-10G-3CXL in the other. The supervisors must completely match, down to the PFCs.

Line Cards

Only 67xx Line cards that are Interface Module Class typeCEF720 are supported.  If they have a Distributed Feature Card it must be DFC3C or DFC3CXL.

Classic, CEF256 and dCEF256 cards are not supported and will remain powered off in a chassis running VSS. Any line card with a DFC3A/3B/3BXL will also remain powered off in a chassis running VSS

3C or 3CXL

As stated above, both will work. However, if the Sups and line cards are not all the same, there can be issues.

If the Sups are 3C and the line cards are 3CXL, the line cards will operate as 3C.

If the Sups are 3CXL and the line cards are 3C, the system will come up in RPR (Route Processor Redundancy) mode instead of SSO (Stateful Switchover) mode. This can be confirmed with the show redundancy command. To correct this, use the “platform hardware vsl pfc mode pfc3c” command to tell VSS to run the Sups as 3C. I have not personally seen this so this is more book knowledge than personal experience.

OK – Now on to the fun stuff.

Configuring VSS

Here is what we’ll be configuring.

The switches running VSS are 6509s with a WS-X670X-10GE supervisor in slot 5 and a WS-X6708-10GE blade in slot 1 and a WS-X6748-GE-TX in slot 2.

For the Virtual Switch Link we’ll be using the 10G ports on the supervisor cards.

Later will add an upstream switch connected to a MultiChassis EtherChannel (MEC) on the VSS pair.

 

! Switch 1

! Note:
!The switch ID is stored as a variable in
! ROMmon, not in the config

!Once VSS is up you can see this with
! switch read switch_num local

! The switch virtual domain number should
! be unique across the network.

! The priority tells which will begin as the
! active supervisor.
! Higher number gets priority
switch virtual domain 9
switch 1
switch 1 priority 110
switch 2 priority 100
exit

! Set Up the VSL link

! port-channel IDs must be unique
! on each chassis to form the VSL

! We will be using 1 and 2.
interface port-channel 1
no shut
desc VSL to switch 2
switch virtual link 1

! The etherchannel mode must be set to on.
! Best practice for etherchannel is normally
! desirable (PAgP) or active (LACP).
! But this is not a normal etherchannel.
! This is a special type of etherchannel and
! requires mode on.

! For our lab, we will use the 10G ports
! on the supervisor.

interface range T5/4 -5
no shutdown
channel-group 1 mode on

! NOTE: After VSS is enabled on both
! switches, the switches will need to be
! converted to virtual switch mode

switch convert mode virtual

! You’ll be asked if it is OK to save the
! running config and reboot the switch.
! Answer yes and then be patient.
! It takes a while for the switch to reboot.

! On the Active Switch Only.
! This command gets executed only once.

switch accept mode virtual

! Switch 2

! Note:
! The switch ID is stored as a variable in
! ROMmon, not in the config

!Once VSS is up you can see this with
! switch read switch_num local

! The switch virtual domain number should
! be unique across the network.

! The priority tells which will begin as the
! active supervisor.
! Higher number gets priority
switch virtual domain 9
switch 2
switch 1 priority 110
switch 2 priority 100
exit

! Set Up the VSL link

! port-channel IDs must be unique
! on each chassis to form the VSL

! We will be using 1 and 2.
interface port-channel 2
no shut
desc VSL to switch 1
switch virtual link 2

! The etherchannel mode must be set to on.
! Best practice for etherchannel is normally
! desirable (PAgP) or active (LACP).
! But this is not a normal etherchannel.
! This is a special type of etherchannel and
! requires mode on.

! For our lab, we will use the 10G ports
! on the supervisor.

interface range T5/4 -5
no shutdown
channel-group 2 mode on

! NOTE: After VSS is enabled on both ! switches, the switches will need to be
! converted to virtual switch mode

switch convert mode virtual

! You’ll be asked if it is OK to save the
! running config and reboot the switch.
! Answer yes and then be patient.
! It takes a while for the switch to reboot.

! You now have a single switch with a single configuration file.

! A console connection to switch 1 will show the active switch. A connection to switch 2 will show it to be the standby switch.

! The two switch configs have been merged into 1. In truth, the config on switch 1 is maintained while anything (other than VSS) from switch 2 is lost.

! For example, had you given both switches a hostname, the hostname of the merged switch would be that of switch 1.

Interfaces are now referenced by switch/module/port. So T1/1 on switch 1 is now T1/1/1. T1/1 on switch 2 is now T2/1/1.

To reference the modules on switch 1 or switch 2, the command is now show modules switch 1 or show modules switch 2.

show run will show the entire running config.
show run switch 1 will show the part of the config that is specific to switch 1.
show run switch 2 will show the part of the config that is specific to switch 2.

! The following commands can be used to verify the status of the VSS.
! Notice the reference to the switch number – 1 or 2.
show switch virtual
show switch virtual link
show switch virtual role

! The following command is used to synchronize mac-address tables across forwarding
! engines on the 2 switches. If a WS-670x-10G line card is present in the VSS system,
! mac-syncronization is turned on automatically. Otherwise, it has to be enabled manually.
! It certainly doesn’t hurt to always include this command.

mac-address-table synchronize

! The following command sets the redundancy mode to SSO.
! However, it should be SSO by default.

redundancy
mode sso
exit

! Do show redundancy to see that it is SSO. If it comes up RPR,
! chances areSups are 3CXL and the line cards are 3C.
! If that is the case, you’ll need to execute platform hardware vsl pfc mode pfc3c

Configuring a MultiChassis EtherChannel (MEC)

The upstream switch is a 6509 with 2) WS-X670X-10GE sups.  1 in slot5 and 1 in slot 6. This might be one of a pair of data center distribution switches, with the VSS pair being a server switch. The second distribution switch would also be connected using a standard etherchannel back to a MEC on the VSS pair. And of course the distribution pair would be connected to each other.

Notice the port designations on the VSS pair. They are now in the form of switch/module/port.


Configuring  the VSS pair for connectivity to the upstream switch

For our purposes we’ve going to configure an etherchannel configured as a layer 3 etherchannel. However, it can just as easily be configured as a layer 2 etherchannel or even an access port etherchannel.

!The layer three etherchannel gets configured just as it would on any other switch.
interface port-channel 10
no switchport  ip address 172.16.0.1 255.255.255.252
no shut

! What makes it a MEC is the fact that it includes ports from both chassis of the VSS domain.
interface range TenGigabitEthernet 1/1/1,  TenGigabitEthernet 2/1/1
no switchport  channel-group 10 mode desirable  no shut
exit

Configuring  the upstream switch

interface port-channel 10
no switchport  ip address 172.16.0.2 255.255.255.252
no shut

!Note: The etherchannel on the upstream switch is not a MEC. ! The MEC resides on the VSS pair.

interface range TenGigabitEthernet 5/4 -5
no switchport  channel-group 10 mode desirable  no shut
exit

From here you’ll want to confirm the etherchannel is up and you can ping across it.

show etherchannel summary
ping 172.16.0.1

At this point you can do anything you want from a simulation perspective. Configure loopbacks with addresses and configure a routing protocol. Configure a local DHCP scope and use one of the Gig interfaces on the WS-X670X-10GE supervisor to connect a computer. If you do configure a routing protocol, you’ll want to make certain to include the nsf command. VSS will take advantage of both SSO and NSF.

! For OSPF
router ospf 1
nsf
exit

! If using EIGRP
router eigrp 1  nsf
exit

Through all of this I used 10 Gig interfaces with which to connect switches. However the reason I showed a WS-X6748-GE-TX in slot 1/2 and 2/2 of the VSS pair is because being a server switch I’d expect to be connecting to servers with 1G. A MEC can be built on the 6748 ports and be used to connect to servers. If the server supports LACP, the MEC could configured as active and negotiate the etherchannel with the server. Otherwise you’ll have to configure the etherchannel as on.

For a server connecting to a single vlan, the etherchannel would be configured as an access port. However, for VM servers, it would be reasonable to connect using dot.q tagged frames. In that case the MEC could be configured as a trunk. All of that is pretty well documented in the Cisco docs I referenced.

I hope this helps get you started with VSS.

Incidentally, had the upstream switch really have been a distribution switch, it might instead look like this.

 

25 responses to “VSS Configuration

  1. Hi Jim,

    Thanks for a great post. i just had one question about it. incase if a supervisor goes down on switch 2 what will happen. does switch 2 stops working or still switch 1 supervisor controls the switch 2 and it works like a 18 slot chassis.
    i read in cisco doc that VSS can only support single SUP in a chassis as well??
    Thanks
    Kamlesh sharma

  2. Kamlesh,
    If the sup in the standby chassis goes down, the entire chassis will go down and the active chassis will loose access to all the ports on the standby chassis.
    f the sup goes down in the active switch the entire chassis will go down. The standby will go active when it sees the VSL is gone and will only have access to its own ports.
    Hopefully Cisco will eventually support dual sups in a chassis running VSS. While it is something they say they intend to do, to my knowledge there is no published timeline on when that will become available.
    Hope this helps.
    Jim

  3. Mark,

    Sorry, I don’t have any experience doing that.

    However, if you are to proceed, what you described is the only way that Cisco recommends doing it. In a somewhat dated document from 2009, Cisco describes connecting a pair of VSS core switches to a pair of VSS distribution switches.

    The document is Campus 3.0 Virtual Switching System Design Guide.
    You’ll want to look at "VSS in the Core" under "VSS Enabled Campus Design".
    This link should take you there.

    http://www.cisco.com/en/US/partner/docs/solutions/Enterprise/Campus/VSS30dg/VSS-dg_ch3.html#wp1080438

    Hope this helps.

    Jim

  4. Mark,
    Try this URL instead. The other one requires a partner login.
    [url]http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/VSS30dg/VSS-dg_ch3.html#wp1080438[/url]
    Jim

  5. Mark,

    Sorry, I don’t have any experience doing that.

    However, if you are to proceed, what you described is the only way that Cisco recommends doing it. In a somewhat dated document from 2009, Cisco describes connecting a pair of VSS core switches to a pair of VSS distribution switches.

    The document is Campus 3.0 Virtual Switching System Design Guide.
    You’ll want to look at "VSS in the Core" under "VSS Enabled Campus Design".
    This link should take you there.
    [url]http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/VSS30dg/VSS-dg_ch3.html#wp1080438[/url]

    Hope this helps.

    Jim

  6. Blossom, actually should nothing to do with the season. A lot of time in his life is confused, find a better reason to let himself not to want to some other people think unimportant matters.
    We all like a clown, in our lifetime playing five balls, the five balls is work, health, family, friends, and spirit. Five balls with only one is rubber, fall can play up and that is work. The other four balls are use made of glass, the off, broken…,http://www.aubootsoutlet.co.uk

  7. Hi Jim,

    Just reading this article and your comment on "Single Sup per VSS chassis". Just wanted to know if the sups are still a concern for "single point of failure" in the current and latest 4500 and 6500 Chassis or is CISCO still trying to fix this concern.

    Have they come out with dual sups on a single VSS chassis?

    Regards,
    Ajit

  8. Hi, i have two switch 6509, one switch with two supervisor and the other switch with one (1) supervisor. So, we want configure VSS but with two (2) supervisor active mode, one supervisor active on switch 1 and one supervisor active on switch 2. It’s possible?

  9. Good question. I did some light research and don’t see the answer. You should check with TAC to see if that configuration is supported. My read on this is that it *might* be supported (after all, a Sup can occasionally fail), but it would be unwise. If the single Sup fails, then that chassis and its ports will be down.

  10. Hello All,

    I was hoping you could help me with a question around VSS. I would like to know if there is a downside from delivering an access layer device into only 1 chasiss of a VSS pair and then delivering a second link from the access layer device into another VSS pair, aside from the loss of efficency in switching, would this be considered bad practice.

Leave a Reply

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.