Stateful switchover (SSO) allows for a hot-standby processor to take control of a failed route processor
while maintaining connectivity. SSO also assures that network
management systems can manage a device with two route processors as one
system and one manageable entity.
With SSO, both active and standby route processors maintain Layer 2
data-link connectivity information by checkpointing the minimal data
required to maintain ATM, frame relay
and Ethernet connections from the active route processor to the standby
one. Maintaining the connection is imperative to minimize CPU
utilization, reduce the amount of data loss during a switchover and
quickly establish the standby processor in hot standby state.
Additionally, any method to create an SSO environment must be able to
scale to tens of thousands of interfaces, because routers on the
Internet keep connection information on tens of thousands of other
routers to which they might need to connect. To accomplish this, the
goal is to attempt to maintain only what is necessary and cannot be
re-created across the route processors. Examples of states that are kept
across the route processors are physical interface state, permanent
virtual circuit state and command synchronization.
In a failure, SSO switches the system to the hot standby route
processor. The failed one will attempt to reboot and operate as the new
standby. This handoff happens without rebooting line cards; therefore
without creating a link flap, which might cause connectivity protocols
to be dropped.
We must give Jimmy a chance to explain all this in his "Cisco Switching Kitchen" -
It
is important for service modules to continue working through an NSF
with SSO supervisor failover event. Many of the service modules have
specific high-availability mechanisms in place today to allow
intrachassis or interchassis module-to-module switchover. Supervisor NSF
with SSO support with services modules complements the
high-availability mechanism of each of these services modules by
minimizing the impact of a supervisor failover.
Each
of the properties pertaining to SSO with standard switching modules
holds true for services modules:
The services modules do not reboot
The
services modules interfaces stay up
The service modules are not
affected by a supervisor switchover except for the short period
corresponding to line-card synchronization.
Almost all of the Optical
services modules (OSMs) and FlexWAN modules are supported with
redundant supervisor engines and continue working through an NSF with
SSO supervisor failover event.
References
Cisco Catalyst 6500 High Availability
Stateful Switchover
Nonstop Forwarding with Stateful Switchover