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
Cisco Catalyst 6500 Virtual Switching System Deployment Best Practices
Replace Supervisor Module in Cisco Catalyst 6500 Virtual Switching System 1440
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.
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.
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.
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.
! 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.
! The following commands can be used to verify the status of the VSS.
! The following command is used to synchronize mac-address tables across forwarding
! The following command sets the redundancy mode to SSO.
! Do show redundancy to see that it is SSO. If it comes up RPR,
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.
! What makes it a MEC is the fact that it includes ports from both chassis of the VSS domain.
Configuring the upstream switch
interface port-channel 10
!Note: The etherchannel on the upstream switch is not a MEC. ! The MEC resides on the VSS pair.
interface range TenGigabitEthernet 5/4 -5
From here you’ll want to confirm the etherchannel is up and you can ping across it.
show etherchannel summary
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
! If using EIGRP
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.
What is the use of NSF and SSO and what will happen if i'm not used them.
written by Ahmed, April 10, 2011