[c-nsp] Catalyst 6500 Supervisor Engine Redundancy

[Ed Butler]

I suppose the obvious follow-on question from this, is how do number of
failure compare between hardware/software?

Regards,

Ed Butler
RapidSwitch Ltd
DDI: 020 7106 0731

RapidSwitch Ltd, 5th Floor, Sovereign House, 227 Marsh Wall, London, E14
9SD

This email message is intended only for the addressee(s) and contains
information that may be confidential and/or copyright.  If you are not
the intended recipient please notify the sender by reply email and
immediately delete this email. Use, disclosure or reproduction of this
email by anyone other than the intended recipient(s) is strictly
prohibited. No representation is made that this email or any attachments
are free of viruses. Virus scanning is recommended and is the
responsibility of the recipient. 
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Lasher, Donn
Sent: 26 October 2006 19:48
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Catalyst 6500 Supervisor Engine Redundancy


I would only offer one caveat as to Redundancy mode discussions.

For software-related failures, SSO may actually hurt you more than it
helps.

SSO, at least in my experience in the past (was SRM as I recall), is a
complete "mirror" of one proc to the other. This means any memory
corruption issues, stack problems, IOS issues, that may cause the first
Proc to crash, may then crash the other proc as well, leading to a
chassis reboot. Badness.

RPR+, while taking longer to fail over compared to SSO, avoids those
issues, by being "warm" but not "hot" standby.

For hardware related failures on the other hand, SSO > RPR*

 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Church, Chuck
Sent: Thursday, October 26, 2006 10:20 AM
To: Dave Lim; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Catalyst 6500 Supervisor Engine Redundancy

Dave,

	I believe SSO has replaced RPR and RPR+.  No reason to consider
them for a Sup720 to my knowledge.  SSO seems to be about a 2 second
failover.  NSF is a 'hook' into the routing protocols that tells other
boxes with neighbor relationships to the box undergoing the failover to
NOT dump their routing tables when they see the new Sup come up and want
to create a neighborship.  There are a ton of caveats, but I believe
that's a good overview of it.  So I guess a short answer is always use
SSO, and use NSF if your routing protocols and topology support it. 


Chuck Church
Network Engineer
CCIE #8776, MCNE, MCSE
Multimax, Inc.
Enterprise Network Engineering
Home Office - 864-335-9473
Cell - 864-266-3978
cchurch at multimax.com

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dave Lim
Sent: Thursday, October 26, 2006 11:36 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Catalyst 6500 Supervisor Engine Redundancy

Hi group,

I am trying to configure Sup 720 engine redundancy for the first time.
There's 3 types of sup engine as in the Catalyst 6500 configuration
guide.

Route processor redundancy (RPR):

Route processor redundancy plus (RPR+)

Single router mode with stateful switchover (SRM with SSO)

Nonstop Forwarding (NSF) with SSO:

My questions are, I have asked my colleagues and they have seen more of
RPR and RPR+ deployed. My question is, which type of sup engine
redundancy do I use and under what circumstances.

Thanks.
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/