| 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 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. 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 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. 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.
! 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 mac-address-table synchronize ! The following command sets the redundancy mode to SSO. redundancy ! 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.
Comments (27)
  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
 written by rajendra, July 27, 2010
Hi Jim
I am preparing for the VSS implementation in next month.I found this post very usefull from practical view point.This clarifies some of the initial doubts.
 written by Pat, September 29, 2010
•Jim, you indicate that the configuration on the secondary switch is lost. If this is a core upgrade does this mean that all interface configurations on switch 2 are lost and will have to be re-configured?
written by Jim Marinelli, September 29, 2010
Pat,
By a core upgrade, are you saying you will be converting a pair of core switches to VSS ?
 written by Andriu, October 01, 2010
Hi Jim
i just wondering if it possible to configure 1 VSL link with 10G and one with 1G ? I know that cisco recommends minimum 2X10G I supervisor.
written by Jim Marinelli, October 01, 2010
Andriu,
A VSL is a port channel. By definition, all links in a port channel must be the same type and speed. I have never tried it but I would not expect it to work. Jim
 written by Sreekanth, October 19, 2010
Please advice me on configuring FWSM in active/standby state interchasis failover in VSS Domain
written by Jim Marinelli, October 19, 2010
Sreekanth,
I've never done a FWSM so I won't be able to help with that. Jim
 written by Kelvin, January 18, 2011
hi,
i'm wondering why the channel-group was difference number for switch1 and switch2. may i use the same number for boths. thanks
written by Jim Marinelli, January 23, 2011
Kelvin,
I'm not exactly sure why it is a requirement but they must be different. Just as important, whatever port-channel is used on switch 1 for the VSL must not be configured on switch 2 and vice versa. An example best illustrates what I mean. If you use port-channel 10 on switch 1 for the VSL, you must make certain port-channel 10 is not used or configured on switch 2. And if you use port-channel 20 on switch 2 for the VSL, you must make certain port-channel 20 is not used or configured on switch 1. This is because both port-channels become part of the single configuration when the 2 switches get converted to 1 virtual switch. So both port-channels end up on both chassis as part of the VSS conversion. If port-channel 20 were already configured on switch 1, it would conflict with the creation of port-channel 20 on switch 1 as part of the VSS conversion. The same would happen if port-channel 10 were already configured on switch 2. Jim
 written by Ben Alex, January 25, 2011
If I am converting a pair on existing distribution switches. Does it mean that I will have to reconfigure sw2 or sw1 or both as far as the linecards are concerned.Same concern as PAt above.
Also, should both be converted at the same time. Thanks
 written by Joe, February 07, 2011
Hi guys,
My VSL is currently configured with Port-Channel 1 (active sw) and Port-Channel 2 (standby sw). I've been asked to change the numbers of the Port-channels to 20 and 21. Which will be the way to go? Convert to standalone? Thanks!
written by Jim Marinelli, February 10, 2011
Joe,
Yes, that's the approach I would take. Convert to standalone and then back to VSS with the new port channel numbers. Hopefully the box isn't yet in production. Jim
written by Jim Marinelli, February 10, 2011
Ben,
Sorry about the delay in replying. I just now saw your post. You asked - "should both be converted at the same time." When converting 2 switches to VSS, the process converts both switches. You have no choice. It also requires several reboots so there will be down time. Regarding reconfiguring Sw1 or Sw2 - keep in mind that when 2 switches are converted to VSS, the configuration on switch 2 is completely lost. The configuration on switch 1 is preserved and used for the single virtual switch. Port numbers change so that interface x/y on switch 1 becomes interface 1/x/y. Interfaces from switch 2 become interface 2/x/y. Are your access switches layer 2 or layer 3. If they are layer 2 and you have HSRP running on your distribution switch pair, that will no longer apply to VSS because sw1 and sw2 become a single virtual switch with a single configuration. Think in terms of a 3750 type switch stack but with 6500s. Jim
 written by Tony, March 17, 2011
I'm wondering if you can still have a valid VSS config if you are unable to configure your uplinks in Etherchannel/MEC. ie- if I am dropped 2 separate 10Gb links from a coloc provider/ISP/etc and they are not setup for Etherchannel 802.3ad, but completely separate links, with separate L3 addresses.
To Clarify; I want to run a pair of 650x w/ VSS as my core, can they still have redundant upstream links if the links are not 802.3ad? Thanks -Tony
 written by Lai Dong, March 22, 2011
When you use VSS quad-supervisor uplink forwarding, the in-chassis standby (ICS) supervisor engine
acts as a DFC line card. Only one processor, the SP processor, acts as the DFC line card; the RP processor is reset to ROMMON. During the bootup, once the chassis level role is resolved, the ICS downloads the image from the in-chassis active (ICA) supervisor engine. Once the supervisor engine is booted with the image, it will function in the same way as a DFC line card. All applications running in virtual switch (VS) view the in-chassis standby as a DFC line card. If your supervisor engine is: • in-chassis active, it can be VSS active or VSS standby. • in-chassis standby, it can only be an ICS. • VSS active, it can only be ICA. • VSS standby, it can only be ICA.
 written by Ahmed, April 10, 2011
Hi Jim,
i found in the configuration guide that NSF and SSO are must. what do you think? and also NSF should be configured under all the used routing protocols (ospf,eigrp.....)?
 written by colin, April 14, 2011
The CFC on the 67xx with CFC also are supported for VSS. (took some digging on cisco's site to find out)
https://supportforums.cisco.com/thread/162934 http://www.cisco.com/en/US/pro....shtml#qa7 Slide#27: http://ccug.files.wordpress.co...up-may.ppt
written by Jim Marinelli, April 18, 2011
Tony,
I hope my answer doesn't come too late for you. The short answer is yes. As you know, two 6500s running VSS look like a single logical switch. Connections from those switches do not have to be etherchannel connections. MEC is something that is available but not a requirement. It is perfectly acceptable to have single links from each switch that are layer 3 connections as in the case of your coloc. Not that you'd want to do this, but there is nothing to keep you from having devices that are single homed to the VSS core. The connection can be a link like a connection to any 6500 switch. It can be a connection to an access port, a layer 3 port or a trunk port. Jim
written by Jim Marinelli, April 18, 2011
Lai Dong,
What you say is true as of 12.2(33)SXI4. This blog was written in December of 2009. At that time, SXH4 and SXI were the current versions of code and only single supervisors per chassis were supported. As Cisco Documentation states: In software releases earlier than Cisco IOS Release 12.2(33)SXI4, the VSS does not support supervisor engine redundancy within a chassis. Starting in Cisco IOS Release 12.2(33)SXI4, the VSS does support supervisor engine redundancy within a chassis.
written by Jim Marinelli, April 18, 2011
Ahmed,
Yes you want to run SSO and you want to configure NSF for each routing protocol that is running. SSO (stateful switchover) and NSF (Non Stop Forwarding) are both are used to provide high availability in the event of loss of the active supervisor and failover to the standby supervisor. With SSO, the 2 supervisors share state so that should the standby supervisor need to take over, it has all the state information needed to continue processing packets. NSF deals with the layer 3 routing protocols and their topology tables. When the standby supervisor takes over, the Vlan SVIs reset which normally would result in the loss of any Layer 3 routing protocol neighbors. This would cause a routing protocol re-convergence and layer 3 forwarding of packets would be interrupted. However, with NSF, packets continue to be forwarded while neighbor relationships and topology tables are rebuilt. This only works if the neighboring routers are NSF aware. In other words, the neighboring router must be able to exchange special NSF messages with the NSF capable 6500 to help the 6500 rebuilt its topology table. Without SSO and NSF, loss of the active supervisor will result in disruption of existing traffic flows. So you want to use them both.
written by Jim Marinelli, April 18, 2011
Colin,
Sorry I was not clear on this. It was inferred by the "if" statement Under 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. So as you pointed out, DFC is not a requirement.
 written by Mark Gunther, May 16, 2012
Do you have any experience connecting two VSS domains via a MEC? Are there any tidbits of wisdom to share doing this? The two domains have the same networks/VLAN's and this is nothing more than an expansion of a data center. My thoughts are standing up a MEC (fully-meshed), but prior to doing that define spanning-tree root and route points out of my data center.
written by Jim Marinelli, May 16, 2012
Mark,
Sorry, I don't have any experience doing that. However, if you are to proceed, what you described is the only way that Cisco recommends doing it. In a somewhat dated document from 2009, Cisco describes connecting a pair of VSS core switches to a pair of VSS distribution switches. The document is Campus 3.0 Virtual Switching System Design Guide. You'll want to look at "VSS in the Core" under "VSS Enabled Campus Design". This link should take you there. http://www.cisco.com/en/US/doc...#wp1080438 Hope this helps. Jim
Write comment
|
Subscribe to this comment's feed
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