bdragun
asked on
Redundant Supervisor Response Time For FailOver
I have Catalyst 4507r setup and testing the redundant supervisor failover before I put it live. The Sup engines are both Sup II Plus. I have the auto sync standard enabled and I can see the sups sync.
So I run a constant ping from a laptop to a server through the 4507r.
Now my thinking about how it should work is this... when I force a switch over or pull out the active sup the ping should keep replying without missing a beat.
What really happens is this... when I force the switchover the ping times out and comes back up when the new redundant sup initializes.
My question is this... Is this the way its redundant sups are supposed to work? Or is the connection supposed to keep running without missing a beat?
So I run a constant ping from a laptop to a server through the 4507r.
Now my thinking about how it should work is this... when I force a switch over or pull out the active sup the ping should keep replying without missing a beat.
What really happens is this... when I force the switchover the ping times out and comes back up when the new redundant sup initializes.
My question is this... Is this the way its redundant sups are supposed to work? Or is the connection supposed to keep running without missing a beat?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
"The 5513 is a COS only switch. Supervisor failover is nice and fast in that situation."
Just another reason for me to prefer the COS in big switches, and goes to show why Cisco hasn’t been able to kill it yet.
Just another reason for me to prefer the COS in big switches, and goes to show why Cisco hasn’t been able to kill it yet.
ASKER
I did find this on Cisco's Site:
The standby supervisor engine runs in RPR mode. When RPR mode is used, the standby supervisor engine partially boots and keeps synchronized copies of the active configuration, which shortens the time needed to bring up the standby supervisor engine and have it start handling traffic from 1.5 minutes (for a cold boot on the standby) to 30 seconds (to finish the boot and re establish links).
A switchover will occur when:
* The active supervisor engine fails or is removed
* A user forces a switchover
* A user reloads the active supervisor engine
* A core dump occurs
Note In a switchover, there is a disruption of traffic because some address states are lost and then restored after they are dynamically redetermined.
I don't think this is working correctly because i clocked it and it is taking 1.5 minutes to come back up.