Downloads |
Table Of Contents
Prerequisites for Stateful Switchover
Restrictions for Stateful Switchover
Route Processor Redundancy Plus
Route Processor Synchronization
Bulk Synchronization During Initialization
Online Removal of the Active RP
SSO-Aware Protocols and Applications
Routing Protocols and Nonstop Forwarding
Setting the Configuration Register and Boot Variable
Configuring Frame Relay and Multilink Frame Relay Autosynchronization LMI Sequence Numbers
Performing a Fast Software Upgrade
Copying an Image onto an RP Examples
Copying an Image onto the Active and Standby RPs on the Cisco 7500: Example
Copying an Image onto the Active and Standby RPs on the Cisco 7304 and Cisco 10000: Example
Copying an Image onto Active and Standby RPs on the Cisco 12000: Example
Setting the Configuration Register Boot Variable Examples
Setting the Configuration Register Boot Variable on the Cisco 7304: Example
Setting the Configuration Register Boot Variable on the Cisco 7500: Example
Setting the Configuration Register Boot Variable on the Cisco 10000: Example
Setting the Configuration Register Boot Variable on the Cisco 12000: Example
Configuring SSO on the Cisco 7500 Series Router: Example
Configuring SSO on the Cisco 12000 Series Internet Router: Example
Configuring Autosync LMI Sequence Numbers: Example
Verifying SSO Configuration: Examples
Feature Information for Stateful Switchover
Stateful Switchover
First Published: July 22, 2002Last Updated: August 21, 2007Development of the Stateful Switchover (SSO) feature is an incremental step within an overall program to improve the availability of networks constructed with Cisco IOS routers.
is particularly useful at the network edgeSSO provides protection for network edge devices with dual Route Processors (RPs) that represent a single point of failure in the network design, and where an outage might result in loss of service for customers.
SSO has many benefits. Because the SSO feature maintains stateful protocol and application information, user session information is maintained during a switchover, and line cards continue to forward network traffic with no loss of sessions, providing improved network availability. SSO provides a faster switchover relative to HSA, RPR, and RPR+ by fully initializing and fully configuring the standby RP, and by synchronizing state information, which can reduce the time required for routing protocols to converge. Network stability may be improved with the reduction in the number of route flaps had been created when routers in the network failed and lost their routing tables.
This document describes the Stateful Switchover (SSO) feature in Cisco IOS software.
Note
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for Stateful Switchover" section.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
•
•
Prerequisites for Stateful Switchover
•
•
•
Restrictions for Stateful Switchover
General Restrictions for SSO
•
•
•
•
•
•
•
Configuration Mode Restrictions
•
•
%HA-5-MODE:Operating mode is sso, configured mode is sso.On the Cisco 7304 router, a message similar to the following appears:
%HA-6-STANDBY_READY: Standby RP in slot n is operational in SSO modeThe actual slot number depends on which slot has the active processor.
Switchover Process Restrictions
•
•
•
•
•
•
ATM Restrictions
•
–
–
–
–
–
–
–
–
–
–
Frame Relay and Multilink Frame Relay Restrictions
•
Note
•
–
–
–
–
•
•
LMI keepalive messages contain sequence numbers so that each side (network and peer) of a PVC can detect errors. An incorrect sequence number counts as one error. By default, the switch declares the line protocol and all PVCs down after three consecutive errors. Although it seems that synchronizing LMI sequence numbers might prevent dropped PVCs, the use of resources required to synchronize LMI sequence numbers for potentially thousands of interfaces (channelized) on larger networking devices might be a problem in itself. The networking device can be configured to synchronize LMI sequence numbers using a CLI command. Synchronization of sequence numbers is not necessary for DCE interfaces.
•
•
•
•
•
•
•
PPP Restrictions
•
•
Cisco 12000 Series Internet Router Platform Restrictions
•
•
•
–
–
–
–
–
•
–
–
–
–
–
–
–
–
–
–
–
–
–
•
–
•
–
–
–
–
–
–
•
–
–
•
–
–
–
–
–
–
–
–
Cisco 10000 Series Internet Router Platform Restrictions
•
•
–
–
–
–
–
–
–
–
–
–
Cisco 7500 Series Internet Router Platform Restrictions
•
•
•
•
•
•
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
•
•
Cisco 7304 Router Platform Restrictions
•
•
•
•
•
•
Development of the SSO feature is an incremental step within an overall program to improve the availability of networks constructed with Cisco IOS routers.
is particularly useful at the network edgeSSO provides protection for network edge devices with dual Route Processors (RPs) that represent a single point of failure in the network design, and where an outage might result in loss of service for customers.
In specific Cisco networking devices that support dual RPs, SSO takes advantage of RP redundancy to increase network availability. The SSO feature takes advantage of RP redundancy by establishing one of the RPs as the active processor while the other RP is designated as the standby processor, and then synchronizing critical state information between them. Following an initial synchronization between the two processors, SSO dynamically maintains RP state information between them.
A switchover from the active to the standby processor occurs when the active RP fails, is removed from the networking device, or is manually taken down for maintenance.
SSO is used with the Cisco Nonstop Forwarding (NSF) feature. Cisco NSF allows for the forwarding of data packets to continue along known routes while the routing protocol information is being restored following a switchover. With Cisco NSF, peer networking devices do not experience routing flaps, thereby reducing loss of service outages for customers.
Figure 1 illustrates how SSO is typically deployed in service provider networks. In this example, Cisco NSF with SSO is primarily at the access layer (edge) of the service provider network. A fault at this point could result in loss of service for enterprise customers requiring access to the service provider network.
For Cisco NSF protocols that require neighboring devices to participate in Cisco NSF, Cisco NSF-aware software images must be installed on those neighboring distribution layer devices. Additional network availability benefits might be achieved by applying Cisco NSF and SSO features at the core layer of your network; however, consult your network design engineers to evaluate your specific site requirements.
Figure 1 Cisco NSF with SSO Network Deployment: Service Provider Networks
Additional levels of availability may be gained by deploying Cisco NSF with SSO at other points in the network where a single point of failure exists. Figure 2 illustrates an optional deployment strategy that applies Cisco NSF with SSO at the enterprise network access layer. In this example, each access point in the enterprise network represents another single point of failure in the network design. In the event of a switchover or a planned software upgrade, enterprise customer sessions would continue uninterrupted through the network.
Figure 2 Cisco NSF with SSO Network Deployment: Enterprise Networks
SSO Redundancy Modes
SSO is one link in a chain of Cisco IOS redundancy features designed to provide progressively higher system and network availability. The specific configuration running on the networking device identifies Cisco IOS redundancy modes, which are described in the following sections:
•
Understanding the various modes is helpful in configuring and verifying SSO. Table 2 indicates which redundancy modes are supported on various platforms and releases.
High System Availability
High system availability (HSA) mode allows you to install two RPs in a single router to improve system availability. This mode is available only on Cisco 7500 series routers. Supporting two RPs in a router provides the most basic level of increased system availability through a "cold restart" feature. A cold restart means that when one RP fails, the other RP reboots the router. Thus, the router is never in a failed state for very long, thereby increasing system availability.
Route Processor Redundancy
Router Processor Redundancy (RPR) is an alternative mode to HSA and allows Cisco IOS software to be booted on the standby processor prior to switchover (a "cold boot"). In RPR, the standby RP loads a Cisco IOS image at boot time and initializes itself in standby mode; however, although the startup configuration is synchronized to the standby RP, system changes are not. In the event of a fatal error on the active RP, the system switches to the standby processor, which reinitializes itself as the active processor, reads and parses the startup configuration, reloads all of the line cards, and restarts the system.
Route Processor Redundancy Plus
In RPR+ mode, the standby RP is fully initialized. For RPR+ both the active RP and the standby RP must be running the same software image. The active RP dynamically synchronizes startup and the running configuration changes to the standby RP, meaning that the standby RP need not be reloaded and reinitialized (a "hot boot"). Additionally, on the Cisco 10000 and 12000 series Internet routers, the line cards are not reset in RPR+ mode. This functionality provides a much faster switchover between the processors. Information synchronized to the standby RP includes running configuration information, startup information (Cisco 7304, Cisco 7500, Cisco 10000, and Cisco 12000 series networking devices), and changes to the chassis state such as online insertion and removal (OIR) of hardware. Line card, protocol, and application state information is not synchronized to the standby RP.
Note
Stateful Switchover Mode
SSO mode provides all the functionality of RPR+ in that Cisco IOS software is fully initialized on the standby RP. In addition, SSO supports synchronization of line card, protocol, and application state information between RPs for supported features and protocols (a "hot standby").
Note
Route Processor Synchronization
In networking devices running SSO, both RPs must be running the same configuration so that the standby RP is always ready to assume control if the active RP fails.
To achieve the benefits of SSO, synchronize the configuration information from the active RP to the standby RP at startup and whenever changes to the active RP configuration occur. This synchronization occurs in two separate phases:
•
•
Bulk Synchronization During Initialization
When a system with SSO is initialized, the active RP performs a chassis discovery (discovery of the number and type of line cards and fabric cards, if available, in the system) and parses the startup configuration file.
The active RP then synchronizes this data to the standby RP and instructs the standby RP to complete its initialization. This method ensures that both RPs contain the same configuration information.
Even though the standby RP is fully initialized, it interacts only with the active RP to receive incremental changes to the configuration files as they occur. Executing CLI commands on the standby RP is not supported.
On Cisco 12000 series devices with three or more RPs in a chassis, after negotiation of active and standby RP, the non-active (remaining) RPs do not participate in router operation.
Synchronization of Startup Configuration
Note
The startup configuration is a text file stored in the NVRAM of the RP. It is synchronized whenever you perform the following operations:
•
•
•
•
•
•
•
Incremental Synchronization
After both RPs are fully initialized, any further changes to the running configuration or active RP states are synchronized to the standby RP as they occur. Active RP states are updated as a result of processing protocol information, external events (such as the interface becoming up or down), or user configuration commands (using CLI commands or Simple Network Management Protocol [SNMP]) or other internal events.
CLI Commands
CLI changes to the running configuration are synchronized from the active RP to the standby RP. In effect, the CLI command is run on both the active and the standby RP.
SNMP SET Commands
Configuration changes caused by an SNMP set operation are synchronized on a case-by-case basis. Currently only two SNMP configuration set operations are supported:
•
•
Routing and Forwarding Information
Routing and forwarding information is synchronized to the standby RP:
•
•
Chassis State
Chassis state changes are synchronized to the standby RP:
•
•
Line Card State
Changes to the line card states are synchronized to the standby RP. Line card state information is initially obtained during bulk synchronization of the standby RP. Following bulk synchronization, line card events, such as whether the interface is up or down, received at the active processor are synchronized to the standby RP.
Counters and Statistics
The various counters and statistics maintained in the active RP are not synchronized because they may change often and because the degree of synchronization they require is substantial. The volume of information associated with statistics makes synchronizing them impractical.
Note
Switchover Operation
During switchover, system control and routing protocol execution are transferred from the active to the standby RP. Switchover may be due to a manual operation (CLI-invoked) or to a software- or hardware-initiated operation (hardware or software fault induced).
The following sections describe switchover operation considerations:
•
Switchover Conditions
An automatic or manual switchover may occur under the following conditions:
•
•
•
The user can force the switchover from the active RP to the standby RP by using a CLI command. This manual procedure allows for a "graceful" or controlled shutdown of the active RP and switchover to the standby RP. This graceful shutdown allows critical cleanup to occur.
Note
Caution
Switchover Time
The time required by the device to switch over from the active RP to the standby RP varies by platform:
•
•
•
Although the newly active processor takes over almost immediately following a switchover, the time required for the device to begin operating again in full redundancy (SSO) mode can be several minutes, depending on the platform. The length of time can be due to a number of factors including the time needed for the previously active processor to obtain crash information, load code and microcode, and synchronize configurations between processors and line protocols and Cisco NSF-supported protocols.
The impact of the switchover time on packet forwarding depends on the networking device:
•
•
•
Online Removal of the Active RP
For Cisco 7500 series routers, online removal of the active RSP will automatically switch the redundancy mode to RPR. Online removal of the active RSP causes all line cards to reset and reload, which is equivalent to an RPR switchover, and results in a longer switchover time. When it is necessary to remove the active RP from the system, first issue a switchover command to switch from the active RSP to the standby RSP. When a switchover is forced to the standby RSP before the previously active RSP is removed, the network operation benefits from the continuous forwarding capability of SSO.
For Cisco 7304, Cisco 10000, and Cisco 12000 series Internet routers that are configured to use SSO, online removal of the active RP automatically forces a stateful switchover to the standby RP.
Single Line Card Reload
In Cisco 7500 series routers, a line card might fail to reach the quiescent state as a result of a hardware or software fault. In such cases, the failing line card must be reset. We recommend using the Single Line Card Reload (SLCR) feature to provide maximum assurance that SSO will continue forwarding packets on unaffected interfaces during switchover.
Note
The SLCR feature allows users to correct a line card fault on a Cisco 7500 series router by automatically reloading the microcode on a failed line card. During the SLCR process, all physical lines and routing protocols on the other line cards of the network backplane remain active.
The SLCR feature is not enabled by default. When you enable SSO, RPR+, or RPR, it is important that you enable SLCR also. For information on how to load and configure SLCR, refer to the Cisco 7500 Single Line Card Reload feature module.
Fast Software Upgrade
You can use Fast Software Upgrade (FSU) to reduce planned downtime. With FSU, you can configure the system to switch over to a standby RP that is preloaded with an upgraded Cisco IOS software image. FSU reduces outage time during a software upgrade by transferring functions to the standby RP that has the upgraded Cisco IOS software preinstalled. You can also use FSU to downgrade a system to an older version of Cisco OS or have a backup system loaded for downgrading to a previous image immediately after an upgrade.
SSO must be configured on the networking device before performing FSU.
Note
Core Dump Operation
In networking devices that support SSO, the newly active primary processor runs the core dump operation after the switchover has taken place. Not having to wait for dump operations effectively decreases the switchover time between processors.
Following the switchover, the newly active RP will wait for a period of time for the core dump to complete before attempting to reload the formerly active RP. The time period is configurable. For example, on some platforms an hour or more may be required for the formerly active RP to perform a coredump, and it might not be site policy to wait that much time before resetting and reloading the formerly active RP. In the event that the core dump does not complete within the time period provided, the standby is reset and reloaded regardless of whether it is still performing a core dump.
The core dump process adds the slot number to the core dump file to identify which processor generated the file content. For more information on how to complete a core dump, refer to the Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.2.
Note
SSO-Aware Protocols and Applications
SSO-supported line protocols and applications must be SSO-aware. A feature or protocol is SSO-aware if it maintains, either partially or completely, undisturbed operation through an RP switchover. State information for SSO-aware protocols and applications (such as PPP, Frame Relay, Multilink Frame Relay, ATM, and SNMP) is synchronized from active to standby to achieve stateful switchover for those protocols and applications.
The dynamically created state of SSO-unaware protocols and applications is lost on switchover and must be reinitialized and restarted on switchover.
SSO-aware applications are either platform-independent, such as in the case of line protocols (Frame Relay, Multilink Frame Relay, ATM, and PPP) or platform-dependent (such as line card drivers). Enhancements to the routing protocols (CEF, Open Shortest Path First, and Border Gateway Protocol [BGP]) have been made in the SSO feature to prevent loss of peer adjacency through a switchover; these enhancements are platform-independent.
Line Protocols
SSO-aware line protocols synchronize session state information between the active and standby RPs to keep session information current for a particular interface. In the event of a switchover, session information need not be renegotiated with the peer. During a switchover, SSO-aware protocols also check the line card state to learn if it matches the session state information. SSO-aware protocols use the line card interface to exchange messages with network peers in an effort to maintain network connectivity.
This sections describes SSO supports for each of the line protocols described in the following sections:
•
•
Table 3 indicates which protocols are supported on various platforms and releases.
