Thursday, December 31, 2009

Cisco VSS configuration

I just finished standing up a Cisco VSS 1440 configuration for a client and thought I would put down a few notes about getting the system up and configured (with a script) plus some basic commands that are useful to know. Also, there are some quick notes on how to set up detecting a dual active configuration.

A basic configuration requires that both 6500 series chassis have the Sup720-10G and currently VSS will only support X67xx series line cards with some additional service modules like the FWSM, ACE and NAM. Seems that VSS really prefers line cards with the PFC 3C also.

You have to prep the two chassis so they are able to connect and function as a VSS pair. To do this they must be running SSO and NSF prior to pairing plus have the port-channel built out for the Virtual Switch Link (VSL.)

So, the bit of script to do that on each chassis is:
!
redundancy
mode sso
exit
!
router ospf {process id}
nsf
exit
!

Next is to build out the virtual switch domain, it should be unique to the VSS pair:
!
switch virtual domain {domain # between 1-255}
switch {1 or 2 - designated switch number for that chassis}
exit
!

The VSL should run across a port-channel of ten gig:
! - switch 1
interface port-channel 1
switch virtual link 1
no shut
!
! - switch 2
interface port-channel2
switch virtual link 2
no shut
!
! - next set up the ten gig ports - putting in the ten gig port on the sup720-10G in slot 5 plus a port from a x6708-10G in slot 6
! - switch 1
interface ten5/4
channel-group 1 mode on
no shut
! - add a second port
interface ten6/1
channel-group 1 mode on
no shut
!
! - switch 2
interface ten5/4
channel-group 2 mode on
no shut
! - add a second port
interface ten6/1
channel-group 2 mode on
no shut
!

Cisco recommends you set the Policy Feature Card (PFC) operating mode to 3C - this is assuming all your linecards have 3C PFC's in them - not always the case but here is how to do it:
!
platform hardware vsl pfc mode pfc3c
!

Now you finally get to issue commands that convert the existing chassis to a VSS ready configurations. Basically, by putting in the next command it uses the information that you gave it (which switch it is) plus knowledge of the existing port configuration to generate a new configuration file that will work when paired with the other unit. It effectively pre-pends its switch number to the slot/port numbers. For example, in switch 1, slot 5, port 4 - ten gig the current configuration refers to that port as simply tengigabitethernet5/4 but in the new configuration it will be tengigabitethernet1/5/4. After it does this a reload is required to get the configuration and pairing to work as expected. The command is:
!
switch convert mode virtual
!

The first time the VSL comes up and pairs you need to put in a command telling the primary switch to pull configuration information over from the secondary. You do that with the following command:
!
switch accept mode virtual
!

That should be it, you should have a working configuration. The first time I did this it was very confusing because using the traditional command sets for checking port-channels or modules or power status worked - they just didn't display what I thought they would. There are specific commands for a VSS and once you figure them out the whole configuration makes a lot more sense.

Some specific VSS common commands to use are:
!
show switch virtual link
show switch virtual link port-channel
show switch virtual link port
!
show switch role
!
! - commands that are modified for VSS so you can see information per switch chassis:
show mod switch 1
show mod switch 2
show power switch 1
show power switch 2
!

Of special note, if you look at the port-channel configuration for the VSL using traditional commands it will show it as down/down. At first this was very confusing for me until I realized that the port-channel had been effectively virtualized and controlled by the VSS process and you had to look at the status of the virtual link to determine what was happening. It also makes sense as you would never set up a port-channel to and from the same switch so the switch should NOT bring the link up in that logical context so having it only visible via the virtual link commands makes a lot of sense.

I think they should do some special reserved or locking commands for the port-channels you do set up for the virtual link because someone who is NOT familiar with VSS could easy think there are unused port-channels and potentially try and clean them out of the configuration, that could be bad. Hey, sometimes people don't read the descriptions on interfaces as much as you would like them too!

The next item to set up is Dual-Active Detection which is how the switches detect that both chassis think they are the active system and how to avoid this situation and detect it quickly to tell one of the switches to stop acting as the active system. I think the quickest way to set this up is with Fast Hello using a Layer 2 Ethernet link between the two chassis but you also have PagP and BFD options. You can optionally use all of the methods to help detect a Dual-Active condition.

To set up the Fast Hellow Dual-Active Detection simply pick two Ethernet ports on each chassis and do:
!
switch virtual domain {domain ID}
dual-active detection
exit
interface {type}{switch id/module/port}
switchport
dual-active hello
no shut
!

- Correction (01/18/10) - thanks Jay:
The correct syntax should be:
!
interface {type}{switch id/module/port}
no switchport
no ip address
dual-active fast-hello
!

To see if it is working do:
show switch virtual dual-active summary
show switch virtual dual-active fast-hello

That should get you started on the Cisco VSS bandwagon quickly, send me a note if you see problems, this was based on 12.2(33)SXH code so earlier code might have different commands.

- Correction (01/18/10) - thanks Jay:
The code release should be 12.2(33)SXI - I am running s72033-advipservicesk9_wan-mz.122-33.SXI3.bin and the configuration works.
- Ed

7 comments:

Unknown said...

fast-hello doesn't seem to be supported in SXH at all, and in SXI it's refered to specifically as fast-hello and the tending switchport needs to be in no switchport mode:

interface GigabitEthernet1/5/3
no switchport
no ip address
dual-active fast-hello

Ed Horley said...

Jay,
That is correct, I will fix that in the post. The code release I am running is 122-33.SXI3 Adv IP Services and the port configuration I have set up currently is:
!
interface GigabitEthernet1/2/48
no switchport
no ip address
dual-active fast-hello
!

More importantly, it works ;)
- Ed

Voyage en Amérique said...

Hello,

I got the same architecture on a customer's site but I got a problem.
When I do a failover (stopping the Active châssis), the convergence is very slow : 6 lost pings !!!!

I only have SSO because NSF is not available on IP BASE IOS (s72033-ipbasek9-mz.122-33.SXI3.bin).
The châssis were delivered with this IOS by Cisco itself !

Is it necessary ?

I checked many times my configuration (which is exactly the same than yours) but I always have a very slow convergence (6 lost pings and ToIP communications lost).

Thanks

Voyage en Amérique said...

Hi again,

I found my issue.

The "routage" was on another router.
But it was the LACP negociation between this router (an Extreme Networks's device) and the 6500 VSS.

Now everything works fine and failover is very fast.

Thanks for all.

Chad D. said...

Good article...thanks for posting it!

Anonymous said...

Easier yet, just by Avaya switches. Cisco is lagging behind Avaya in this technology. The Avaya version is much easier to configure and runs without any problems.

Anonymous said...

Hi,

Is it possible to set up VSS over colo? I am thinking of using a 1GB 4503E