Redundant SUP720's single chassis

Sep 07, 2006 12 Replies

Hey all,



Single 6500, Dual SUP720's. Is there any way to make both sup's active? Trying for most of the day, can only get active/standby. When using active/standby there is about 1-2minutes of downtime when failing a sup. Trying to eliminate any downtime.



Thanks,



-Brian


AFAIK there can only be one active supervior.

What is the IOS release in use ?

Starting with Cisco IOS Software Release 12.2(18)SXF, NSF/SSO supersedes the SRM redundancy mode.

config t redundancy mode sso end

Thanks Merv, that's my thinking as well.....Up'd it to 12.2.18-SXF5 today. I tried both sso and rpr+. Yanked sup1, took bout 30seconds for sup2 to come online, about 2 minutes for all the line cards and almost a full 5 minutes for the FWSM mod to come fully online. I got a TAC case open on it. There is no reason why the line cards should have reset themselves when the primary was pulled.

-Brian

If the TAC doesn't come bak with anything I would try backing down to

12.2(18)SXF4

Almost went to that version today, all the SXF's with the exception of 5 have a software advisory against them. Happy happy joy joy, here we go yet again!

both must have same IOS and May be you need IOS version 12.2(20) or Up

We buy sell all Cisco LinkWaves Corp

29980 Technology Drive, Suite 6 Murrieta, CA 92563
formatting link

Brian V wrote:

oh because SXF4 was supposed to be a safe harbour release ...

We've had various kinds of grief with our 6500s in the last year or so. While I can understand why it's happening[1] I'm disappointed that Cisco haven't managed to produce a GQ quality[2] release of software for their premier switching platform.

Sam

[1] New hardware and features being developed and deployed faster than the testing regime can keep up. [2] General Deployment: "suitable for deployment anywhere in customer networks where the features and functionality of the release are required", see .

Well today, just for s**ts and giggles after a useless TAC response decided to move the sxf5 to the sup-bootflash's rather than using the boot string pointing to disk0. After doing that I pulled sup2 and rebooted the chassis, after it came up, re-inserted sup2. Failover worked great, could go back and forth as much as I want. Single ping loss and no initilizing of the blades or the FWSM. After I did all the testing, I added the boot string back pointing to Disk0, sure enough back to the old failover taking almot a full 5minutes. Removed the boot string and put the image back in the sup-bootflash, presto, back to working great. Needless to say, I found a lovely bug, I mean feature. Undocumented of course, can't find mention of it anywhere, couldn't find any bugs related to it. Sent TAC the screenshots, hopefully it makes it in to the bugs for the next victim.....12hrs wasted, oh the joy.

-Brian

Nice catch, did the TAC provide you with a DDTS number

Negative, not yet atleast. This guy I got is either a newbie or a part timer, piss pooor communications from him. I've already sent it to our local guys here in Boston. They want to come and see it first hand. Meeting them at the customer site Monday morning.

You might want to consider running without redundant SUP720. Looks like SSO may have more than 1 serious bug ...

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required