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

Labels:


Monday, December 28, 2009

 

So, what advatages are there to having a Cisco VSS configuration?

I've been in several discussions with clients who are trying to understand the benefit of Cisco VSS vs a Nexus 7k approach for new data center deployments. Cisco has some excellent information out there on differences between the two platforms but if you haven't been on the lookout to upgrade your network infrastructure you might have missed the discussion.

I think both the Cisco VSS and Nexus solutions address many of the frustrations that people who are building larger data centers with virtualization are looking for. Specifically, a way to get redundancy and high availability plus very large bandwidth into their server farms while not building out a massive layer 3 network which can cause limitations for virtualization solutions. One of the advantages for companies that are not doing virtualization (perhaps their applications require all the cpu and memory of the host server) is that the architecture works equally well for them.

Cisco has build some specific solutions around virtualization plus data center, this is their recent announcement of the UCS products. I am not going to bother discussing that in this post and if you want to know more about that I suggest reading Colin McNamara's blog - he covers it really well so no reason to repeat it here.

So why would you pick a Cisco VSS solution vs a Cisco Nexus solution. There isn't an obvious answer at first blush.

Here would be the short list of why VSS first. They would be:
1. Having staff who understand and are familiar with the Cisco 6500 series and support a lot of them already.
2. The requirement for having service modules in the solution, something VSS supports but Nexus does not.
3. Moving from an existing investment in 6500's with Sup720-10G's to a high available, redundant solution split across multiple chassis - gear reuse.
4. Want tight fault tolerance solutions with other Catalyst switching platforms.
5. Able to provide Multichassis EtherChannel (MEC) to downstream or upstream devices.

Here would be the short list of why Nexus first. They would be:
1. Running into throughput and performance problems with a 6500 solution at core or distribution. Especially due to service modules impacting performance.
2. Would like to move to having independent point devices for services like firewalling, load balancing, network analysis and wireless. Perhaps you like a different vendors load balancer or firewall product that run at much higher throughputs.
3. Moving to very high density 1 and 10G server solutions that can grow and scale for investment protection.
4. Moving to the next generation platform where Cisco will be investing research and dollars into.
5. Able to provide Multichassis EtherChannel (MEC) to downstream or upstream devices.

So, if you are building out a data center soon that will require a 5-7 year lifespan then I really suggest moving to the Nexus platform now. Cisco is making the pricing just as attractive as the 6500 series but you gain all the advantages of moving to the next generation of platform.

If your time horizon is shorter for changing out your data center network equipment then the Cisco 6500 VSS solution is a great transition product which allows the re-use of your 6500 chassis and investment in supervisors (if you have Sup720-10G's already) and service modules.

The reality is that you will likely have both within your data center if you are making reuse of service modules. You can then run those service modules in 6500 series with 10Gig to a core Nexus plaform with the 6500's running VSS MEC to the Nexus 7000's running vPC MEC.

Both solution will work to your downstream server farms for MEC and the VSS has been upgraded to support 512 Port-Channels in a single chassis, more than enough considering many servers are getting 4 x 1Gig ports or more channeled together to the network.
- Ed

Labels: ,


This page is powered by Blogger. Isn't yours?

Creative Commons

Unless otherwise expressly stated, all original material of whatever nature created by Ed Horley and included in this weblog and any related pages, including the weblog's archives, is licensed under a Creative Commons License.