Ask the Expert: Configuring and Troubleshooting Virtual Switching System (VSS)

[ciscomoderator]

With Anand Ganesan

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about how to monitor, configure, and troubleshoot the Virtual Switching System (VSS) in Cisco Catalyst 6500 Series Switches with expert Anand Ganesan.

VSS is network system virtualization technology that pools multiple Cisco Catalyst 6500 Series Switches into one virtual switch, increasing operational efficiency, boosting nonstop communications, and scaling system bandwidth capacity to 1.4 Tbps. At the initial phase, a VSS will allow two physical Cisco Catalyst 6500 Series Switches to operate as a single logical virtual switch called a virtual switching system 1440 (VSS1440). 

For more information, visit:  www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9336/prod_qas0900aecd806ed74b.html

The VSS simplifies network configuration and operation by reducing the number of Layer 3 routing neighbors and by providing a loop-free Layer 2 topology.

Anand Ganesan is a customer support engineer in the High-Touch Technical Service team at Cisco specializing in switching protocols. He has been supporting major service providers and enterprise customers in switching and all other switching technologies for more than two years with Cisco. He has a total of eight years of experience in the IT industry. He holds a bachelor of engineering degree from Bharathiyar University, Coimbatore.

Remember to use the rating system to let Anand know if you have received an adequate response. 

Because of the volume expected during this event, Anand might not be able to answer every question. Remember that you can continue the conversation in the Network Infrastructure subcommunity, LAN Switching & Routing shortly after the event. This event lasts through September 6, 2013. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

[Alexey Stytsenko]

Hi Leonardo.

First of all you need supervisors 720-10G  and 6509-NEB-A chassis at least,  to make up your VSS.

About 15.1 version of IOS - it does not support quad sup redundancy for SUP2T   - http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.1SY/config_guide/sup2T/virtual_switching_systems.html#wp1300164, but for SUP720-10G is ok.

BTW i have negative experience of upgrading to 15.1 after that i had to rollback to more stable 12.2.33. So I will recommend you to use 12.2 line until you really need smth what only 15.1 can give to you.

Regards,

[Alexey Stytsenko]

Good day, Anand.

I need to deploy distributed datacenter, and I decide to build it based on two Catalyst 6509 united into VSS. But to make VSL link redundant I plan to use different optical connections - one link with approximately length 4 km and second 15 km.

So as I can imagine those links can have slightly different delays when transmit, so how do you think can this results in problem?

Regards,

[Anand G]

Dear Alexey,

Thanks for posting the query. I am glad to answer the query.

One of the main advantage of the VSS setup is the distance between the physical chassis.

The underlying physical switches do not have to be colocated. The two physical switches are connected with standard 10 Gigabit Ethernet interfaces and as such can be located any distance based on the distance limitation of the chosen 10 Gigabit Ethernet optics.

For example, with X2-10GB-ER 10 Gigabit Ethernet optics, the switches can be located up to 40 km apart.

So, the distance which you have mentioned is max.15km and ideally it should work without any issues.

As far as I know, there are no issues reported so far.

Regarding pros & cons of a large split like this; sometimes, it is difficult to find diverse paths when you are going longer distances like this even in a campus environment. I would recommend planning out your paths and methods of dual-active detection to make sure your risks of split-braining the VSS are not increasing significantly by splitting them across campus.

Hope this clarifies ! Please let me know if you have any further questions.

Thanks,

Anand G.

[Alexey Stytsenko]

Good day, Anand.

Thnx for reply, but can you specify such moment as:

VSL consists of two links - one link 4 km length, other one 15 km length, so those links have different delays - can this negatively affect inter VSS control traffic passed over those links? As far I understand only one link will be used by each chassis to communicate to other one (based on cef principles), so there are no possibility for control packets to get to other side of VSL link out of order. And consequently this design (with different links length forming one VSL link) is acceptable. Can you confirm this or disprove?

Regards,

[Anand G]

Dear Alexey,

Thanks for your question.

With respect to your first question, I would like to let you know about a protocol named Link Management Protocol (LMP), The LMP runs on each individual link that is part of the VSL, and is used to program information such as member details, forwarding indices, etc.

By default LMP hello transmit timer(T4) and receive (min_rx) timer is 500 msec. The hold-timer known as T5 timer derived from a min_rx and default multiplier of 120. Thus by default VSL member link time out is detected in 60 second.

So, as long as the links on VSL receives the response from peer before the T4 & T5 values gets time out, there will not be any delay issues that affects inter-VSS control traffic passed over those links.

The VSL bundle is special purpose EtherChannel that can have up to eight members. Only one link out of a configured member is selected as the control link and that control link is the only link that can carry the inter-chassis control plane. The control link carries the inter-switch External Out-of-Band Channel (EOBC) control traffic that includes the Switch Control Packet (SCP) for line card communication, Inter-process Communication Packets (IPC), and Inter-Card Communication (ICC) for communicating the protocol database and state—as well as updates to the hot-standby supervisor.

In addition, the same link can carry user and other network control traffic—depending how the traffic is hashed (i.e., based on source and destination MAC and/or IP addresses). The remaining bundled links carry network control plane and user data traffic, but not the inter-chassis control plane traffic.

Another important point which I would like to mention here is, the control-link selection procedure is determined by the VSS system and cannot be managed by the user. During the bootup process, the first VSL link that establishes LMP relationship (state-machine) will be selected as the control link. Based on the Cisco Catalyst 6500 architecture, the supervisor module becomes operational ahead of any other module installed in the switch. If the 10-Gbps port of Sup720-10G module is bundled in the VSL EtherChannel, then it will be selected as control-link interface whenever both switches undergo the boot process.

Hope this answers your question.

Please let me know if you have any additional questions. I am very glad to provide more details.

Thanks,

Anand G.

[csc010627097]

Hi Anand,

I ask again with new information:

I am planning to  implment VSS on my Datacenter. I Have a 6509-E and a 6506-E both with  Supervisor 720-10G. At the moment the 6509-E is working with ios12.2(33)SXI as an standalone switch. The 6506-E is a brand new. I would like to  know what are the advantages in using VSS or VSS Quad Supervisor!  Aditional if I decide to use Quad Supervisor wich IOS version do you  recommend? 15.1?

Thanks a lot for your time

Regards

[Anand G]

Hi Leonardo,

Thanks for posting your query.

Let me provide you the advantages of using VSS/Quad Supervisor.

Beginning in software release 12.2(33)SXI4, VSS supports a feature called Quad-Sup Uplink Forwarding which allows a redundant in-chassis Supervisor to operate primarily as a line card. Prior to this release with a second supervisor in the chassis it will be forced into rommon and not be allowed to boot, however there are no issues keeping the 2nd sup in the chassis.

A Supervisor failure event will down the affected chassis decreasing the VSS bandwidth by 50%.

A Second Supervisor installed in the chassis will boot as a Linecard with all of its ports active. It is supported in 12.2(33)SXI4 and newer on supervisor VS-Sup720-10G.

Another advantage is, if the active Supervisor in the chassis fail, the In-Chassis Standby will reload and then take over the chassis Supervisor functions without human intervention.

Here are some keypoints which I would like to highlight.

1. Quad Supervisor Uplink Forwarding feature is available starting with release in 12.2(33)SXI4
2. Quad Supervisor Uplink Forwarding is not available on Supervisor Engine 2T based VSS, future software releases will provide support for fully redundant Supervisors with VSS
3. Quad Supervisor Uplink Forwarding allows for deterministic recovery from a Supervisor failure event
4. In-Chassis Standby Uplinks are active and operational under normal conditions
5. In-Chassis Standby Supervisor runs in new redundancy mode called RPR-WARM
6. Switchover to the In-Chassis Supervisor does require a reload of the chassis
7. Supervisor role negotiation occurs first within the chassis, then the “winning” In-Chassis active Supervisor performs VSS role negotiation between chassis

The Supervisor 720-10 G supports the Quad-Sup Uplink Forwarding4 feature, which allows for a redundant in-chassis supervisor module. Again, it is recommended to build the VSL with at least one port from each supervisor module. If desired, you can use all the 10 Gigabit ports from the supervisor modules for the VSL. With this configuration, you should cross-connect one port form each supervisor to one port on each supervisor on the peer chassis. This will help ensure an active VSL port member local to the active supervisor, regardless of any supervisor module failure.

Quad-Sup Uplink Forwarding VSL design using all 10 Gigabit ports on the supervisor modules:

• Maintains 20 Gbps VSL bandwidth in the event of a supervisor failure
• Maintains at least one locally attached VSL port to the active supervisor, in the event of a supervisor module failure
• Requires no additional line cards

If additional bandwidth is needed for the VSL, additional 10 Gigabit ports from supported line cards can be used. Up to eight ports per port channel can be added, just like any other port channel interface.

With respect to the image 15.1, I see from my database repository, there are couple of bug applicable for 15.1.

To highlight an example, I have come across a situation where the customer did a manual switchover in 15.1 VSS setup.

They got the below error messages.

Jul 10 04:14:07.075: ISSU-SW2-3-PEER_IMAGE_INCOMPATIBLE Peer image (s2t54-IPSERVICESK9-M), version (15.1(1)SY1) on peer uid (262) is incompatible
Jul 10 04:14:07.075: ISSU-SW2-3-PEER_IMAGE_INCOMPATIBLE Peer image (s2t54-IPSERVICESK9-M), version (15.1(1)SY1) on peer uid (262) is incompatible 

Hence, I would recommend to use the standard 12.2(33)SXI and above.

Please let me know if you have any questions.

Thanks,

Anand G

[sandevsingh]

Hi Anand, I had a question on Layer 3 peering with VSS. As VSS is logically one control plane, so if I dual attach any layer 3 device with the VSS pair, will it see only 1 IGP neighbor (i.e the active switch)? If yes, this is a big advantage over nexus-vpc as you have 2 control planes there and each layer 3 device sees both the nexus as its IGP neighbor (one of them over the vpc peer link)  which leads to 50% of the traffic being dropped over the vpc peer link due to the in-built vpc loop avoidance technique.

thnx

[Anand G]

Hi Sandevsingh,

Thanks for posting the query.

Yes. your assumption is perfectly right. The Layer-3 device when attached with the VSS pair, it will see the VSS switch as a single neighbor (whichever the active in a VSS pair).

Please let me know if you have any questions.

Thanks,

Anand G

[patelronak]

I have 2 Cisco 4950 switches. Is VSS supported on Cisco 4950  switch? If yes, Which IOS image I need?

[Anand G]

Dear Ronak,

Thanks for posting your query.

Yes, the VSS is well supported in 4900 series switches. It should have the Supervisor Engine 7E or 7LE for VSS support and we need an identical pairs (7E/7LE)  in hardware front.

With respect to your question about software (IOS) support, we need to have Cisco IOS XE 3.4.0SG and ROMMON IOS Version 15.0(1r)SG7 or later release would support VSS. Coming to the license part, you may need a minimum license of IP Base or higher (7-E) or special license (7-LE and Catalyst 4500-X).

I would like to provide some additional information on SSO and NSF.

SSO and nonstop forwarding (NSF) must be configured on each switch. If a VSS does not meet the requirements for SSO redundancy; it will be incapable of establishing a relationship with the peer switch. Catalyst 4500/4500-X series switches' VSS does not support route processor redundancy (RPR) mode.

Hope this answers your question!

If you have any further queries, please let me know.

Thanks,

Anand G.

[tissebastian]

hi anand, i am new to networking field. could you please provide some information  on how the 2 standalone switches establish a VSS connection? what are the  protocols involved?

[Anand G]

Hello Tismol,

Thanks for your query and the interest shown on knowing the technical aspects.

As you are new to this field, let me explain in a very simple manner.

The two standalone switches can be combined using a link called VSL, Virtual Switch Link. It provides the mechanism to keep both the chassis in sync upon VSS is formed.

The VSL initialization happens in 3 steps.

1) Bringing the link Up.

This is to determine which ports form the VSL

2) LMP (Link Management Protocol)

This protocol is used to track and reject unidirectional links, exchange chassis ID and other information between the 2 switches.

3) RRP (Role Resolution protocol)

This protocol is used to determine the compatible hardware and software versions to form the VSL as well as determine which switch becomes Active and Hot standby from a control plan perspective.

Hope this answers your question.

Please let me know if you have any questions.

Thanks,

Anand G.

[subaviswesvaran]

Hi Anand,

I have the following questions.

1) what are the various detection methods available in case of dual-active scenario?

2) which method is ideally used in fast converging?

Thanks

Suba

[Anand G]

Dear Subbulakshmi,

Thanks for posting your query.

There are three detection methods can be configured while dual-active scenario is observed.

1) Enhanced PAgP

It uses PAgP messaging over the MEC links to communicate between the two chassis through a neighbor switch. Enhanced PAgP is faster than IP BFD, but requires a neighbor switch that supports the PAgP enhancements.

2) IP BFD (Bi-directional Forwarding Detection)

It uses BFD messaging over a backup Ethernet connection. IP BFD uses a direct connection between the two chassis and does not require support from a neighbor switch.

3) Dual-active fast-hello method

It uses special hello messages over a backup Ethernet connection. Dual-active fast-hello is faster than IP BFD and does not require support from a neighbor switch.

This method is available only in Cisco IOS Release 12.2(33)SXI and later releases,

You can even configure all three detection methods to be VSS active at the same time.

For line redundancy, we recommend dedicating at least two ports per switch for dual-active detection. For module redundancy, the two ports can be on different switching modules in each chassis, and should be on different modules than the VSL links, if feasible.

Coming to the other question, teh Enhanced PAgP and Fast Hello methods have a sub-second convergence whereas the IP-BFD method has seconds of convergence.

The few things which you need to remember is, the PAgP requires a PAgP capable neighbor, the Fast-hello is a direct L2 connection and the IP BFD method is direct L3 connection.

Hope this answers your queries.

Please let me know if you have any further questions.

Thanks,

Anand G.