VSS configuration

Jeroen Huysmans · ‎07-15-2011

Hi,

Currently I'm running VSS on 2 6509-E chassis. Both chassis have identical hardware:

VS-S720-10G-3C (1 per chassis)
WS-X6708-10G-3C (1 per chassis)
other line modules
s72033-adventerprisek9_wan-vz.122-33.SXI6.bin

The VSL links use 1 TenGig iface on the supervisor, and 1 TenGig iface on the 6708 linecard on each chassis.

I also configured dual-active detection (fast-hello).

I don't like the 1 supervisor in both chassis. If the sup fails, the VSS setup is useless.

My question: can I easily add (and configure the 2nd VSL link on the new supervisors) a supervisor in each chassis withouth having to convert the VSS system to standalone mode?

regards,

Jeroen

SunilKhanna · ‎07-15-2011

You may like to check

Two-Port VSL Using Quad-Sup Uplink Forwarding

Regards,

Sunil

Regards, Sunil Khanna

Jeroen Huysmans · ‎07-15-2011

thanks,

I'm aware of the ability to use 2 supervisors in each chassis for VSS.

My question is: can I convert from a 1 supervisor/chassis VSS setup (as configured now) to a 2 sup/chassis VSS setup without converting to stand-alone mode to configure the aditional VSL links... (as this will cause serious downtime)

jeroen

r.shummoogum · ‎07-15-2011

Why would it be useless. The stanby takes over and since everyting is dual homed. you should be ok.

Keep note that quad-vss is only warm rpr. If the sup fails there is a chassis reset. Full SSO not supported yet.

Scott Hodgdon · ‎07-15-2011

Yes, you can add the second Supervisor without going back to standalone mode.

However, as long as everything is dual-homed to the VSS, the loss of a single Supervisor should have only sub-second impact on traffic as it switches to the remaining switch in the Multi-chassis EtherChannels. MOre information about Quad Supervisor Uplink Forwarding can be found at

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vss.html#wp1204229 .

Jeroen Huysmans · ‎07-20-2011

Hi Scott,

thanks for your reply.

However, the main purpose for me is not MCE. I'm sure I'll use this feature on other switches in the future, but for my current setup this isn't the main purpose.

I also read on some pages that when using 1 sup per chassis, when failure occurs on a supervisor the other chassis takes control of the failed chassis. I've tested this: when I remove the single sup in a chassis, all linecards go dark (which is exactly the behaviour I expected to see).

Now I read that when using a quad-sup VSS setup, the 2nd supervisors in both chassis operate in RPR mode?

Jeroen

Jon Marshall · ‎07-20-2011

When using 1 supervisor per chassis if one chassis fails the supervisor in the other chassis will not run the linecards in the failed chassis which is what you saw.

With quad VSS the 2nd supervisor in effect acts as an additional linecard. If the active supervisor fails then the chassis will reboot and the other chassis will take over. Basically the only advantage of dual sups is that the failed chassis can reboot and come up with a supervisor still working.

Jon

Rahul Kachalia · ‎07-20-2011

Hello Jeroen,

Some background may help to understand history and evolution -

VSS History :

Initial software version of VSS clustered two physical chassis to build single logical chassis. This clustering solution heavily leveraged Intra-Chassis SSO redundancy, which means stateful redundancy to protect hw and all planes when SSO-ACTIVE supervisor fails/resets. With VSS the Intra-Chassis SSO redundancy capability is extended to Inter-Chassis (between two physical chassis), this way now both physical chassis is now single entity, unified control/mgmt plane but fully distributed fwding plane because now the switch fabric and PFC function is activated on Standby Sup that reside on remote chassis.

Consider this hw design with Standalone (non-VSS) where you have single sup on each chassis so no in-chassis redundancy. Network availability is achieved thru parallel path redundancy, when one of the chassis resets and restores network capacity is reduced and restore but availability is not compromised.

VSS Today :

Starting 12.2(33)SXI4 IOS release, VSS now allows Quad-Sup. While hw was always ready to handle 4sups between two chassis, the software capability wasnt aware because now logically it is single large chassis and requires architecture to support 1:N stateful redundancy. Before reaching end goal, today Quad-sup delivers RPR-WARM mode. Its an extended capability of original RPR. You still get Inter-Chassis SSO as dual-sup designs, but in parallel you now also get Intra-Chassis RPR redundancy. Unlike RPR software design earlier, the Intra-Chassis Sup provides 1:1 stateless supervisor redundancy AND make the sup act as a DFC linecard to utilize all available onboard physical ports. Benefit, if supervisor fails/resets yes the impacted chassis still resets but if the self-recovery of failed supervisor does not happen then the standby supervisor takes chassis ownership and restores back in services. This significantly reduces MTTR and deliver original network capacity/redundancy rather waiting to get another sup.

With Quad-sup you help protect system level redundancy to restore capacity but with proper path redundancy it helps maintaing network availability while it is getting restore. See following guide for dual vs Quad sup design and implementation in campus :

Borderless Campus 1.0 Design Guide

If you have single-home devices and need stateful redundancy then you should you implement 6500 in standalone mode with dual sup to provide stateful redundancy. Because from network design perspective the single-home devices sees no difference between 6500 implemented in standalone or VSS mode...

thanks,

rahul.

Jeroen Huysmans · ‎07-21-2011

Hi Rahul,

I was making the same assumption after my last post... It might just be better to run both chassis in stand-alone mode with 2 sups in each chassis.

As long as I'm not implementing VSS for MCE, there seems to be no added value (except for managing 1 switch instead of 2). I was unaware that VSS is (currently?) only interesting if devices are dual homed to both members of the VSS setup. Thought it had more value (according to the various ppt/pdf's I read).

Is it correct to conclude VSS is _only_ interesting when using dual-homed devices with MCE?

Thought of implementing it in the server room, but since not all servers are dual-homed, there is no use for VSS there either...

Jeroen

Rahul Kachalia · ‎07-22-2011

Hello Jeroen,

I would say little bit differently - VSS is very_interesting in all common design except_single_home. Combining VSS with MEC simplifies lots, take a look at the design guide I shared it covers most of the pieces.

Because from the physical path diversity, control/mgmt/fwding plane and network topology perspective single-home devices sees no difference whether the 6500 is implemented in Standalone or in Virtual Switch mode. In single-home network design with standalone or VSS you still have multiple single-point-of-fault (SPOF), single link, single linecard, chassis etc. With dual sup you provide control-plane protection but still keeping vulnerable to certain component abnormal failures.

As I described earlier, if you think some of this single-home servers are critical and need better availability like dual-homed servers. Then you have two choices :

1. Implement 6500 in Standalone with redundant supervisor for stateful redundancy.

2. Implement 6500 in VSS mode with intermediate L2 switch (with redundancy) which is dual-homed to VSS, and all single home server connects to this intermediate L2 switch...

thanks,

rahul.

Jeroen Huysmans · ‎07-29-2011

Rahul,

thanks a lot. I'll consider VSS in the future for our serverfarm.

jeroen