6506 Sup720 Redundancy mode configuration

[poirot1967]

Morning all.  We have a 6506E in our datacenter with redundant SUP720's running 12.2(18)SXF8. The current redundancy mode is sso.  What I would like to do is configure it so in addition, that it swaps over to the redundant sup if the active sup's uplink goes down.  We are not doing any routing, just access layer.  Is there a link anyone can point me to or give sugestions?

Thanks

Poirot

[Matthew Blanshard]

Hello Poirot,

I am curious as to why you would need to do this?  Uplinks on the standby supervisor are fully operational when in the standby state so there's no need to switchover when the active supervisors link fails.

-Matt

[poirot1967]

Thanks for the response.  The (ill?) logic behing this is I wished to cut down on the time it would take for the standby sup to jump into action shold that uplink go down.  I believe that the sso mode takes 30 seconds to switchover.  I was hoping to be able to cut it down to 10 or less.  I doubt it would ever go down, but that is exactly why it will.  If I am barking at the moon here, let me know .

Thanks

Poirot

[Nathan Spitzer]

As I thought about it is it spanning-tree your worried about? SSO switchover is instantaneous. However, if the switch is the root bridge (like it most likely should be) depending on how spanning-tree is configured there may be a topology change and that may take 30-45 seconds.

First, run rapid-spanning tree (rpvst+) or mst NOT pvst+. Regular spanning-tree is totally obsolete and has been for years. I have no idea why it is still the default. Rpvst+ can converge in under 10 seconds and includes features that in the case like yours will have almost no convergence time plus its backwards compatible with pvst+. All you woud need to do is change spanning-tree mode on the core , wait 10 seconds then start changing your distribution and access switches at your leisure. There is a 10-15 second blip when you convert but that is it.

MST is much harder IMHO to configure and in a all-Cisco shop I never saw any need for it but if you mix-n-match vendors its the way to go. It uses the rapid spanning-tree protocol but instead of a spanning-tree per vlan you group vlans into larger groups and have one spanning-tree per group. Arguably its more resource-efficient but considering how much CPU and memory modern (and even last-generation) switches have it adds complexity without appreciable benefit.

[Nathan Spitzer]

Three more things:

If you cannot for some reason run rapid spanning-tree, ensure that all switches in the network have "backbonefast" and "uplinkfast" enabled. These two items greatly reduce convergence time. Incidently rstp and mst both have them built-in

Also, if spanning-tree is what you are worried about failing over the supervisor would not work anyway since as soon as you failed over the formerly-active supervisor reloads, causing a spanning-tree topology change.

If you are absolutely convinced you want to do it, however, you should be able to use TCL to script it.

[Matthew Blanshard]

Switchover would increase your outage time when the link fails.  All of the links will be up and functional before the link failure.  Once it fails then the other link on the standby would take over.  STP convergence time would be all the downtime (up to 30 seconds depending on the STP mode).  Now if you force a switchover right in the middle of a STP convergence that will definitely have an impact on the convergence time.

There's really no need to force the switchover and it will actually cause problems for you if you do that.

-Matt