6500 Quad VSS

[Garrett Snavely]

We are getting ready to start testing Quad VSS for our production VSS environments we have done the research and per documentation it seems pretty straight forward. 

I want to make sure that the dual to quad VSS is easily done across our multiple VSS setups and I am curious of those that have done this already have you ran into any gotchas on the turn up of the ICS Sup?  

Also I am curious if anyone has done just a ICS in a single chassis instead of one in both chassis of the VSS?

In one of our environments we have all single home devices going to VSS switch 1 and only dual homed devices. going to switch 2 so may be desireable to only install an ICS in the switch 1 VSS, I would think it would work fine just wondering if anyone has done a deployment like that.

[Reza Sharifi]

Garrett,

Today, Quad VSS does not provide any additional redundancy.  The reason for it is when the primary sup fails the entire switch reboots no matter how many sup you have installed. Now, in the next year or so with the development of new IOS versions ie IOS SXJ, and IOS 15, etc... with Quad sup (2 per device) if the primary sup fails, the second sup within the same box will take over, but this is not the case right now.

HTH

[Jon Marshall]

Reza

Thanks for this (+5). I have been wondering about this for a while and was going over the docs but could not see how additional sups provided any extra redundancy in the current setup.

So presumably the main advantage at present is when the primary reboots at least it can come back up with a working sup ?

Jon

[mike.gee]

Hey John, you're correct. And if you're careful not to have any single-homed devices coming off your VSS pair, you have time to RMA your failed card and run at 50% capacity. There's also the advantage of using the 10GigE interfaces on the spare sup.

Also, just a side technical note... I recently got a great rundown of VSS best practices from Nimish Desai who wrote the design guide for VSS. He said to make sure you aren't using a priority or you can cause an outage for yourself if one of the boxes has to reboot. People think of priority in VSS like they think of priority in HSRP, but it's NOT the same. For example, say switch 1 is your active chassis and you are using priority = 110 to keep it the primary and switch 2 has priority = 100 (which is a bad idea in general, they don't recommend using priority in any case). If switch 1 fails and reloads, switch 2's sup takes over the control plane as the active sup. As switch 1 reboots, the priority forces itself to become active, which then forces switch 2 to reboot into hot-standby mode. So, you end up with both switches rebooting and potentially losing traffic.

Read the design guide really carefully, there are some other gotchas like this depending on code version!

-Mike

[mike.gee]

And by time to RMA the failed card, I mean if you go with dual instead of quad sups...

[Leo Laohoo]

Best Practices for VSS Priority/Preemption

6.11.5   Recommended VSS Priority/Preemption Configuration 

It is recommend NOT configuring switch preemption since identical hardware setup between Active/Standby chassis is recommended with virtual router-mac address configured and that all links connected to Neighbor switch through MEC links. Preempt ensures that one particular switch will always be active in the end. However, forcing preemption transitions requires a reload and potential traffic outage.

Hey Mike,

Is this what you mean?

[mike.gee]

Yep! That would be bad

[Reza Sharifi]

I agree with Mike.  Preemption, priority, not a good idea in VSS deployment.  It causes outage and also confusion.

[Reza Sharifi]

Jon,

Thanks for rating

Correct, that would be pretty much the only benefit.

Reza

[Garrett Snavely]

Reza,

I am aware of the lack of true redundancy features with the ICS and that the chassis reloads when the ICA fails.

The main reason we are looking at this is that we have a couple of environments where devices are not dual home capable and if there would be a true supervisor hardware failure (cpu/memory etc) instead of IOS crash/reload to provide faster down/up recovery than moving ports or insert/restore of ICA Supervisor. Also we are looking at using an ICS only in the chassis where we have the single homed servers as a possibility and was curious if anybody had actually done a dual to quad and if it works as easy as advertised or any known things to look out for.

Mike,

     If only it that easy to only do dual homed servers in every environment.

[Rahul Kachalia · Accepted solution]

Hello Garrett,

I gather multiple qn in your post & will try to answer individually :

1. When VSS is already running in dual-sup mode, what are the VSS Quad Sup deployment best practices?

Answer :

Step 1 : Make sure your ICA is running 12.2(33)SXI4 and onwards so that they are Quad-sup ready.

Step 2 : Install ICS on each virtual-switch chassis and make sure they are booting up with same IOS version as ICA. Or else they will be push down to ROMMON mode.

Step 3 : Redesign VSL links with full-mesh to provide redundancy, capacity and reliability during sup failure

From configuration view point, there is nothing to be done as everything is plug-n-play. Read Quad-Sup Migration section in Chapter 2 of following Borderless Campus CVD for more step-by-step detail:

Borderless Campus 1.0 Design Guide

2. Can virtual-switch SW1 be deployed with dual-sup and SW2 with single sup?

Answer : Yes, it can be and even supported. Essentially you are emulating single-sup failure condition, where you can still get Inter-Chassis SSO redundancy but SW1 will get dual-HA - SSO and RPR-WARM. How RPR-WARM mode works is explained in Chapter 4 of same design guide. SW2 will have ICA (In-Chassis Active with SSO ACTIVE/STDBY but with active fabric and PFC), on ICS this components are disabled and made to work as a DFC linecard.

3. Concern of having network availability and reducing MTTR for single-home devices during complete sup failure.

Answer : There are multiple answer to this qn :

Today VSS Quad-Sup does not support intra-chassis SSO capability. SSO technology was originally design to support 1:1 sup redundancy, which VSS heavily leverage to virtual dual systems into single. RPR-WARM was the first-step towards end-goal and the breakthrough to support quad-sup in single logical switch. Because quadrupling sup redundancy to provide stateful protocol and forwarding redundancy requires significant infrastructure development.

Single-home connections and network designs are transparent to 6500 deployment mode - Standalone or VSS. In another words there is no key benefit for such devices regardless how you deploy 6500 today. Even dual-home connections were not optimal to utilize all resources which MEC solved the problem. IF this servers and their network availability is critical AND if they cannot be dual-homed, then the current recommendation is to deploy intermediate L2 switch with redundancy and dual home/MEC to VSS this is where all single-home devices are connected.

Regarding single-home connections, keep some additional points in mind :

- Forces unicast/mcast data traffic to traverse over the "system-L1-Links" - VSL. This links carries - system control-traffic (VSLP/EOBC etc) and network control-traffic (protocols) and data traffic. If the load is high and links are congested then the traffic may get impacted. Because QoS on this links are preset to minimize failures against any misconfiguration or oversubscription condition.

- If all VSL links fails & the chassis (dual or Quad sup) where all single-home connections was in SSO ACTIVE mode. Then those servers will still face network outage until VSL links are recovered and chassis is restored in service.

4. What are the best practices for Switch Preemption and Priorities

Answer : Switch preemption support is removed in recent IOS releases, it damages the network more then it solves. You can still configure the priorities which is only effective when both virtual-switch boots up. This is where priorities are negotiated and switch with high-priority takes control/mgmt-plane ownership and boot up in SSO ACTIVE mode. This function is transparent to network devices, in one another words the neighboring devices will see no different in forming adjacencies and building network when either of the virtual-switch are in SSO ACTIVE or STANDBY mode. So either you can leave it default or modify if you have preference...

thanks,

rahul.

[Garrett Snavely]

Thanks Rahul, this is what I was looking for.

[Marwan ALshawi]

is the issue has been resolved by having the quad sup to fail over to the intra chassis sup without reboot with SSO with new ios version 15.0(1)SY ?

if yes is it documented anywhere as i cant see it in the release notes !!! if not then i dont think there is a big benefit to upgrade from 12.2.x to 15.0.x !

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.0SY/release_notes.html