cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2638
Views
0
Helpful
10
Replies
Highlighted

VSS configuration

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

Everyone's tags (2)
10 REPLIES 10
Beginner

VSS configuration

You may like to check

Two-Port VSL Using Quad-Sup Uplink Forwarding

Regards,

Sunil

Regards, Sunil Khanna

VSS configuration

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

Beginner

VSS configuration

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.

Cisco Employee

VSS configuration

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 .

VSS configuration

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

Hall of Fame Guru

VSS configuration

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

Cisco Employee

VSS configuration

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.

VSS configuration

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

Cisco Employee

VSS configuration

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.

VSS configuration

Rahul,

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

jeroen

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards