Home
VSS Configuration

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 type CEF720 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 are Sups 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.

 

 

Comments (2)Add Comment
feedSubscribe to this comment's feed
0
Technical Consultant
written by Kamlesh Sharma, December 25, 2009
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
Jim Marinelli
Single Sup per VSS chassis
written by Jim Marinelli, December 28, 2009
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

Write comment

busy