1.2: High Availability

9. Stateful Switchover (SSO)

Stateful Switchover is a high-availability mechanism for platforms with redundant route processors or supervisors. The standby control-plane component is kept synchronized so it can assume the active role with much less disruption than a cold restart. On supported Cisco IOS XE platforms, the standby is commonly described as STANDBY HOT when SSO is ready.

Figure 9 - SSO provides active/standby-hot control-plane redundancy inside a supported platform.

9.1 What Is Synchronized?

The exact state synchronized depends on platform and feature support, but the key idea is that the standby control plane maintains enough synchronized operational state to take over quickly. Configuration, redundancy state, and supported protocol/client state are coordinated between active and standby components.

9.2 SSO vs NSF

SSO and FHRP are complementary. A distribution switch might use SSO internally for supervisor redundancy and also participate in HSRP/VRRP with another distribution switch for node-level gateway redundancy.

9.3 Generic SSO Configuration Pattern

On supported platforms, enabling SSO can reset/reinitialize the standby control-plane component. Production changes must follow the platform-specific procedure and maintenance policy.

9.4 Expected Verification Indicators

9.5 SSO Failover Test

1. Before testing, confirm both control planes are healthy and the peer is STANDBY HOT.

2. Capture baseline routing neighbors, FHRP states, forwarding counters, and application probes.

3. Perform an approved manual switchover using the platform-supported method during a maintenance window.

4. Measure traffic loss and neighbor behavior during the transition.

5. Verify the previous standby is now active and the recovered peer returns to a healthy standby state.

6. Review redundancy history/logs for unexpected resets or synchronization failures.

9.6 SSO Troubleshooting

When troubleshooting Stateful Switchover (SSO), network engineers should verify the redundancy state, standby RP readiness, inter-RP communication, and routing protocol recovery.

The following scenarios explain common SSO problems, their possible causes, and the verification steps required to identify the issue.

1. Standby RP Is Not in STANDBY HOT State

Symptom

The standby Route Processor (RP) does not reach the STANDBY HOT state, even though the active RP is operational.

Possible Causes

• Standby RP is still booting or initializing.

• Software image or version incompatibility between RPs.

• Configuration synchronization failure.

• Unsupported redundancy configuration.

• Hardware or platform-related problems.

Verification Commands

show redundancy
show redundancy states
show redundancy history
show logging

What to Verify

• Confirm the standby RP is detected.

• Check whether the standby is initializing, synchronizing, or repeatedly restarting.

• Verify software compatibility and platform requirements.

• Check logs for synchronization failures or hardware errors.

Expected Result: One RP should be ACTIVE, and the peer should reach STANDBY HOT, with healthy state synchronization.

2. Configured SSO Mode Does Not Match Operational Mode

Symptom

The chassis is configured for SSO, but its operational redundancy mode indicates another state.

Possible Causes

• Standby RP initialization is incomplete.

• Redundancy prerequisites are not satisfied.

• Platform or software restrictions prevent SSO operation.

• Redundancy synchronization has failed.

Verification Commands

show redundancy
show redundancy states

What to Verify

• Compare configured redundancy mode with operational mode.

• Confirm that SSO is supported on the platform and software version.

• Verify standby RP readiness.

• Investigate any reported redundancy initialization errors.

Expected Result: Both configured and operational redundancy modes should indicate SSO, with a healthy standby RP.

3. Peer Communication Is Down

Symptom

The Active RP cannot communicate properly with the standby RP.

Possible Causes

• Internal backplane communication failure.

• High-availability communication channel failure.

• Standby RP hardware failure.

• Internal redundancy communication errors.

Verification Commands

show redundancy
show redundancy states
show logging

What to Verify

• Check redundancy peer communication status.

• Confirm both RPs are detected and operational.

• Investigate internal HA communication errors.

• Examine platform-specific hardware diagnostics and system logs.

Expected Result: Peer communication should be operational, allowing synchronization between the Active and Standby RPs.

4. Unexpected Routing Reset During Switchover

Symptom

OSPF, EIGRP, or BGP adjacencies unexpectedly reset during an RP switchover, resulting in routing reconvergence or temporary traffic interruption.

Possible Causes

• NSF or graceful restart is not enabled or supported.

• Neighboring devices do not support the required recovery behavior.

• Routing protocol recovery exceeds supported timers.

• Platform or software limitations affect control-plane recovery.

• The RP switchover causes a broader interface or line-card disruption.

Verification Commands

show redundancy
show ip ospf neighbor
show ip eigrp neighbors
show ip bgp summary
show ip route
show logging

What to Verify

• Confirm the RP switchover occurred successfully.

• Check routing neighbor states and uptime.

• Verify NSF or graceful-restart configuration and operational support.

• Check whether routes remained installed during recovery.

• Review logs for adjacency resets and protocol errors.

Expected Result: On supported platforms with correctly configured NSF or graceful restart, forwarding should be maintained where possible while the routing control plane recovers. Protocol adjacencies may still reset or reestablish depending on protocol behavior and capabilities.

5. Repeated Standby RP Reloads

Symptom

The standby RP continuously reloads or fails to remain operational long enough to reach the STANDBY HOT state.

Possible Causes

• Software crashes or defects.

• Hardware instability.

• Configuration or state synchronization failures.

• Image or version incompatibility.

• Internal RP communication problems.

Verification Commands

show redundancy
show redundancy history
show logging
show version

What to Verify

• Identify the frequency and reason for standby reloads.

• Review crash information and system logs.

• Confirm software compatibility between RPs.

• Check for hardware faults.

• Determine whether synchronization failures occur before each reload.

Expected Result: The standby RP should boot successfully, complete synchronization, and remain stable in STANDBY HOT.

9.7 What Happens During an SSO Switchover

SSO protects against a Route Processor / supervisor control-plane failure inside a supported chassis. It is different from FHRP: the chassis itself can remain the forwarding gateway while only the active control processor changes. A separate chassis-level FHRP is still required to protect against complete power, fabric, line-card, or chassis failure beyond the scope of SSO.

Phase 1 — Normal Operation (Steady State)

What Happens

• One Route Processor operates in the ACTIVE state.

• The second RP operates in the STANDBY HOT state.

• Supported state information is synchronized between the two RPs.

• Initial synchronization is followed by ongoing dynamic synchronization.

Verification

show redundancy
show redundancy states

Expected Result

• Operational redundancy mode: SSO

• Active RP: ACTIVE

• Standby RP: STANDBY HOT

• Peer communication: Up

Phase 2 — Active RP Failure Detection

What Happens

The chassis detects a failure, removal, or loss of communication involving the Active RP through its internal redundancy mechanisms.

This initiates a supervisor switchover.

Verification

Check system logs and redundancy events.

show logging
show redundancy history

Expected Result

• Logs identify the Active RP failure or switchover trigger.

• Redundancy history records the switchover event.

Operational Note: An internal RP failure should not automatically be interpreted as an HSRP failure. RP redundancy and gateway redundancy operate at different levels.

Phase 3 — Standby RP Promotion

What Happens

The STANDBY HOT RP assumes the ACTIVE role using previously synchronized state information.

The new Active RP takes control of the chassis control plane.

Verification

show redundancy
show redundancy states

Expected Result

• The previously standby RP is now ACTIVE.

• The system identifies the new Active RP.

• Redundancy state transitions are recorded.

Phase 4 — Forwarding Continuity

What Happens

On supported platforms, SSO allows line cards to continue forwarding traffic using previously programmed forwarding information.

This helps prevent unnecessary interruption to the data plane during the RP switchover.

Verification

show interfaces status
show interfaces counters
show logging

Expected Result

• Supported line cards remain operational.

• Interfaces remain Up.

• Forwarding counters continue increasing during traffic.

• No unexpected line-card resets or forwarding-table loss occur.

Operational Note: SSO minimizes disruption but does not guarantee zero packet loss under every failure condition.

Phase 5 — Routing Protocol Recovery

What Happens

Following the switchover, the new Active RP restores routing protocol control-plane operations.

When Nonstop Forwarding (NSF) and compatible protocol graceful-restart mechanisms are supported and enabled, previously programmed forwarding information can remain in use during protocol recovery.

Verification

show ip ospf neighbor
show ip eigrp neighbors
show ip bgp summary
show ip route

Expected Result

• Relevant routes remain available during recovery.

• Routing neighbors recover according to the configured NSF or graceful-restart capabilities.

• Normal control-plane operation resumes.

Important: NSF does not universally guarantee that all routing adjacencies remain continuously established. The actual behavior depends on the protocol, platform, software release, and neighbor capabilities.

Phase 6 — HSRP Operation During SSO

What Happens

On platforms supporting SSO-aware HSRP, an internal RP switchover can preserve the chassis's existing HSRP role.

For example, if Switch-1 is the HSRP Active gateway and its Active RP fails, the standby RP may assume control without causing Switch-2 to become the HSRP Active gateway.

Verification

show standby brief
show redundancy

Expected Result

• The HSRP Active gateway remains the intended chassis when supported state continuity is maintained.

• The RP switchover does not unnecessarily trigger an HSRP role change.

Phase 7 — Post-Switchover Recovery

What Happens

After the standby RP becomes Active, the failed RP must be repaired, replaced, or recovered.

Once operational, it should return to a healthy standby state and complete synchronization with the Active RP.

Verification

show redundancy
show redundancy states
show logging

Expected Result

• One RP is ACTIVE.

• The recovered RP is STANDBY HOT.

• Redundancy mode is SSO.

• State synchronization and peer communication are healthy.

Operational Note: Redundancy is not fully restored while the chassis has only one functioning RP.

9.8 SSO Health and Failure Checks

10. Failure Scenarios and Convergence

Convergence is the time required for the network to detect a failure, select a replacement path or role, update forwarding state, and restore usable traffic. Different failures trigger different mechanisms, so there is no single universal convergence timer.

Figure 10 - Match each failure type to the high-availability mechanism that can actually react to it.

10.1 Scenario Analysis

10.2 Device-Level Failover Decision Chain

For any HA incident, walk through the same chain. The exact protocol differs, but the device must detect failure, decide whether local forwarding is still valid, select/promote a replacement, and then restore packet forwarding. If any link in this chain fails, the network can show a correct protocol role while traffic is still broken.

In enterprise networks, high availability mechanisms such as HSRP, VRRP, Stateful Switchover (SSO), STP, EtherChannel, and dynamic routing protocols help maintain connectivity during network failures.

Although these technologies operate differently, their failure-handling processes can be explained using seven common operational phases:

Detection → Qualification → Eligibility → Election/Promotion → Forwarding → Reconvergence → Stabilization

These phases provide a troubleshooting framework. They do not represent a single state machine implemented identically by every protocol.

Phase 1 — Failure Detection

What Happens

A network device identifies a potential failure by monitoring physical links, protocol advertisements, tracked objects, routing adjacencies, or internal hardware components.

The detection mechanism depends on the technology being used.

Examples:

• HSRP: The standby router stops receiving Hello messages and its hold timer expires.

• VRRP: The Backup router stops receiving Master advertisements and its Master Down timer expires.

• SSO: Internal redundancy mechanisms detect an Active Route Processor failure.

• EtherChannel: A member interface fails or LACP detects an unavailable member.

• Dynamic Routing: A routing neighbor becomes unreachable or a protocol dead timer expires.

Verification Commands

show interfaces status
show standby brief
show vrrp detail
show track
show redundancy states
show logging

What to Verify

• Whether an interface has transitioned to Down.

• Whether HSRP or VRRP advertisements have stopped.

• Whether a tracked object has changed state.

• Whether a routing adjacency has failed.

• Whether redundancy logs identify a supervisor failure.

Expected Result: The appropriate failure-detection mechanism identifies the fault and initiates the required recovery behavior.

Phase 2 — Failure Qualification

What Happens

After a failure is detected, the relevant protocol or redundancy mechanism determines its significance.

The failure may require an immediate failover, reduce available bandwidth, or leave the current forwarding role unchanged.

Example 1 — EtherChannel

A Port-Channel contains four active physical interfaces. One interface fails.

If the Port-Channel remains operational with sufficient active members, traffic can continue across the remaining links.

Example 2 — HSRP Tracking

An HSRP Active router loses its primary uplink. The tracked object changes state and reduces its configured HSRP priority.

Whether another router takes over depends on the resulting priorities and preemption behavior.

Example 3 — SSO

A standby RP failure reduces chassis redundancy but does not normally require the healthy Active RP to relinquish control.

Verification Commands

show track
show etherchannel summary
show standby
show redundancy
show interfaces port-channel 1

What to Verify

• Whether the failure affects the current forwarding path.

• Whether redundant links remain available.

• Whether tracked-object policies are functioning.

• Whether the Port-Channel meets its minimum-link requirements, if configured.

• Whether the Active RP remains healthy.

Expected Result: The network distinguishes failures requiring failover from failures that only reduce redundancy or capacity.

Phase 3 — Recalculate Priority and Eligibility

What Happens

For protocols that use priorities or election criteria, the devices determine which participant is eligible to take over the active role.

This depends on protocol-specific parameters.

HSRP example

Assume:

• Router-1: Priority 110, currently Active

• Router-2: Priority 100, currently Standby

• Router-1 tracks an uplink with a decrement of 30

When the tracked uplink fails:

Router-1 original priority : 110
Tracking decrement         : 30
Router-1 effective priority: 80

Router-2 priority          : 100

Router-2 now has the higher priority. With the appropriate preemption configuration, Router-2 can take over the Active role.

VRRP example

VRRP evaluates Master and Backup eligibility using its protocol-defined priority, address ownership, advertisements, and preemption behavior.

SSO distinction

SSO does not use the HSRP/VRRP priority-election model. It promotes an eligible synchronized standby RP according to the platform's redundancy state machine.

Verification Commands

show standby
show vrrp detail
show track
show redundancy states

What to Verify

• Effective HSRP or VRRP priority.

• Tracking decrement values.

• Preemption configuration.

• VRRP address ownership where applicable.

• Whether the standby RP is ready for promotion.

Expected Result: The intended device is eligible to assume the forwarding or control-plane role when the required conditions are met.

Phase 4 — Active Device Election or Promotion

What Happens

The appropriate protocol or platform transitions control to another device or processor.

Different redundancy technologies perform different actions.

HSRP

The standby gateway becomes Active when the relevant failure or preemption conditions are satisfied.

VRRP

An eligible Backup becomes Master after detecting Master failure or satisfying applicable preemption rules.

SSO

The STANDBY HOT Route Processor assumes the ACTIVE role after an Active RP failure.

Verification Commands

show standby brief
show vrrp
show redundancy states
show logging

What to Verify

• Which device is now Active or Master.

• Whether the expected standby RP was promoted.

• Whether the role transition completed.

• Whether system logs identify the transition.

• Whether unintended repeated role changes are occurring.

Expected Result: The correct gateway or Route Processor assumes control according to the configured redundancy design.

Phase 5 — Forwarding Table Retention or Reprogramming

What Happens

Once the new active device or control-plane owner takes over, traffic forwarding must use valid forwarding information.

Depending on the technology, the system may preserve existing forwarding entries or program new ones.

SSO with NSF

On supported platforms, forwarding hardware can continue using previously programmed Forwarding Information Base (FIB) entries during control-plane recovery.

HSRP and VRRP

The new Active or Master gateway assumes responsibility for the virtual IP and virtual MAC address.

Connected switches may need to relearn the location of the virtual MAC address.

Dynamic Routing

The routing process may calculate new routes and install updated next-hop information into the forwarding table.

Verification Commands

show ip cef
show ip route
show arp
show mac address-table
show interfaces counters

What to Verify

• Whether forwarding entries point toward valid next hops.

• Whether the virtual MAC address is associated with the correct switch port.

• Whether ARP information is correct.

• Whether supported line cards continued forwarding during SSO.

• Whether interface counters confirm traffic forwarding.

Expected Result: Traffic uses the correct active forwarding path with minimal interruption.

Phase 6 — Reconvergence of Network Dependencies

What Happens

After failover, other network technologies may need to adapt to the new forwarding path.

This is important because a successful gateway transition does not automatically guarantee end-to-end connectivity.

Potential dependencies include:

• STP reconvergence and port-state changes.

• EtherChannel or LACP member-state changes.

• OSPF, EIGRP, or BGP route changes.

• ARP and IPv6 Neighbor Discovery updates.

• NAT and firewall session-state continuity.

• Return-path routing across redundant links or devices.

Verification Commands

show spanning-tree
show etherchannel summary
show lacp neighbor
show ip ospf neighbor
show ip bgp summary
show ip route
show arp

What to Verify

• Routing adjacencies are established where expected.

• The routing table contains the intended best paths.

• STP ports are in the correct operational states.

• EtherChannel members are active and bundled correctly.

• Firewall policies and session state permit traffic.

• Return traffic follows an acceptable path.

• Application connectivity is restored.

Expected Result: All required Layer 2, Layer 3, and security dependencies support the new forwarding path.

Phase 7 — Network Stabilization and Recovery

What Happens

After the failure is resolved, the network must return to a stable operating state.

The recovered device may either resume its backup role or reclaim the primary role, depending on the technology and configuration.

Example — HSRP Recovery

Router-1 recovers from an uplink failure.

Its tracked object returns to Up, restoring its original HSRP priority.

If preemption is enabled and applicable conditions are met, Router-1 may reclaim the Active role.

Example — SSO Recovery

The failed RP returns to service, synchronizes its state, and becomes STANDBY HOT.

Example — Routing Recovery

A restored routing adjacency may introduce an additional path or restore a preferred route. Stability should be confirmed before considering the incident resolved.

Verification Commands

show standby brief
show vrrp
show redundancy states
show track
show ip route
show logging

What to Verify

• The expected primary/backup roles are established.

• Recovered tracked objects report Up.

• Routing adjacencies and routes remain stable.

• No repeated failovers or route flapping occur.

• Any configured preemption delay is functioning as intended.

• Redundancy is fully restored.

Expected Result: The network remains stable, with appropriate primary and backup resources available.

10.3 Failure Type vs Who Detects It

10.4 What Determines the Real Convergence Time?

Measured outage time is the sum of several components, not merely the HSRP/VRRP state-change timer: failure detection + FHRP/SSO election or promotion + L2 forwarding update + routing/adjacency recovery + policy/state recovery + application retry behavior. The slowest dependency becomes the user-visible convergence time.