Cisco VSS

Cisco VSS Configuration using primarily Catalyst 6509 switches with Sup 720 – 10 G Supervisors.

Here are some useful Cisco docs on the subject, 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

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. 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.

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 the 10G ports on the supervisor cards will be used.

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

Here etherchannel is 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.