Table Of Contents
Prerequisites for Stateful Switchover
Restrictions for Stateful Switchover
Information About Stateful Switchover
Route Processor Synchronization
Bulk Synchronization During Initialization
Online Removal of the Active RP
SSO-Aware Protocols and Applications
IPv6 Support for Stateful Switchover
Routing Protocols and Nonstop Forwarding
How to Configure Stateful Switchover
Setting the Configuration Register and Boot Variable
Configuring Frame Relay SSO to Synchronization LMI Sequence Numbers
Troubleshooting Stateful Switchover
Possible SSO Problem Situations
Configuration Examples for Configuring Stateful Switchover
Copying an Image onto an RP: Example
Setting the Configuration Register and Boot Variable: Examples
Configuring Frame Relay to Synchronize LMI Sequence Numbers: Example
Verifying SSO Configuration: Examples
Feature Information for Stateful Switchover
Stateful Switchover
First Published: July 22, 2002Last Updated: November 25, 2009Development of the stateful switchover (SSO) feature is an incremental step within an overall program to improve the availability of networks constructed with Cisco IOS XE routers.
SSO is particularly useful at the network edge. Traditionally, core routers protect against network faults using router redundancy and mesh connections that allow traffic to bypass failed network elements. SSO 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 high system availability (HSA), and Router Processor Redundancy (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 SSO feature in Cisco IOS XE Software.
Note
Throughout this document, the term "Route Processor" (RP) is used to describe the route processing engine.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Stateful Switchover" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS XE 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
The Stateful Switchover feature has the following prerequisites:
•
•
Restrictions for Stateful Switchover
General Restrictions for SSO
•
•
•
•
Configuration Mode Restrictions
•
•
Dec 3 04:05:55.350: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync succeededDec 3 04:05:55.418: %RF-5-RF_TERMINAL_STATE: Terminal state reached for (SSO)Switchover Process Restrictions
•
ATM Restrictions
•
–
–
–
–
–
–
–
–
–
–
Cisco ASR 1000 Series Aggregation Services Routers Restrictions
•
•
•
Cisco IOS XE Release 2.2 Restrictions
•
•
•
–
–
–
•
Information About Stateful Switchover
To implement Stateful Switchover, you need to understand the following concepts:
•
•
SSO Overview
Development of the SSO feature is an incremental step within an overall program to improve the availability of networks constructed with Cisco ASR 1000 series routers.
is particularly useful at the network edgeSSO provides protection for network edge devices with dual 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 Cisco networking devices that support dual RPs, SSO takes advantage of RP redundancy to increase network availability. The feature establishes 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 key feature of the Cisco ASR 1000 Series Routers is that SSO can be used to enable a second Cisco IOS XE process on a single RP for software redundancy in the 2-RU and 4-RU chassis systems. These dual Cisco IOS XE packages can consists of the same software packages for backup or different packages for resilient upgrade. This second Cisco IOS XE process acts as a standby process for the active Cisco IOS XE process, and also allows certain subpackages to be upgraded without experiencing any router downtime.
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 XE redundancy features designed to provide progressively higher system and network availability. The specific configuration running on the networking device identifies Cisco IOS XE redundancy modes, which are described in the following sections:
Route Processor Redundancy
Router Processor Redundancy (RPR) allows Cisco IOS XE Software to be booted on the standby processor prior to switchover (a "cold boot"). In RPR, the standby RP loads a Cisco IOS XE 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.
Stateful Switchover Mode
SSO mode provides all the functionality of RPR+ in that the 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").
Table 1 shows redundancy modes available in Cisco IOS XE Release 2.1.
Table 1 Redundancy Modes Available in Cisco IOS XE Release 2.1
ASR 1000
RPR
Yes
SSO
Yes
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:
•
•
The synchronization of configuration information also applies to dual processes on a single RP.
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.
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. Changes to the chassis state due to line card insertion or removal 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
Switchover time is only a few seconds on the Cisco ASR 1000 Series Router. Packets that are switched or routed by the Cisco QuantumFlow Processor (QFP) on the switching fabric card are not impacted by the RP switchover. However, if packets are punted to the RP for further processing, switching and routing will be impacted. 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 Cisco ASR 1000 Series Router has separate RPs and Forwarding Processor (FP). All transit packets are handles by the FP. Therefore, no transit packet loss occurs during RP switchover (dual RPs) or during IOSD process switchover (single RP).
Online Removal of the Active RP
For Cisco ASR 1000 Series Routers that are configured to use SSO, online removal of the active RP automatically forces a stateful switchover to the standby RP.
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 "Troubleshooting and Fault Management" chapter in the Cisco IOS XE Network Management Configuration Guide.
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, 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, ATM, and PPP) or platform-dependent (such as line card drivers). Enhancements to the routing protocols (Cisco Express Forwarding, 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.
The following protocols and applications are SSO-aware:
•
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:
•
•
ATM Stateful Switchover
With stateful switchover, ATM dynamic state information is synchronized between the active RP and standby RP. Thus when the active RP fails, the standby RP can take over without spending excessive time relearning the dynamic state information, and forwarding devices can continue to forward packets with only a few seconds of interruption.
Note
Permanent Virtual Circuits
For ATM to support forwarding during and after switchover, ATM permanent virtual circuits (PVCs) must remain up not only within the networking device, but also within the ATM network.
In an ATM network, all traffic to or from an ATM interface is prefaced with a virtual path identifier (VPI) and virtual channel identifier (VCI). A VPI-VCI pair is considered a single virtual circuit. Each virtual circuit is a private connection to another node on the ATM network. In ATM SSO, the VPI-VCI pair is associated with a virtual circuit descriptor (VCD). ATM SSO uses VCD information in synchronizing VPI-VCI information to the standby RP.
Each virtual circuit is treated as a point-to-point or point-to-multipoint mechanism to another networking device or host and can support bidirectional traffic. On point-to-point subinterfaces, or when static mappings are configured, Inverse Address Resolution Protocol (ARP) need not run. In cases where dynamic address mapping is used, an Inverse ARP protocol exchange determines the protocol address to VPI-VCI mapping for the PVC. This process occurs as soon as the PVC on a multipoint subinterface makes the transition to active. If that process fails for some reason, the remote networking device may drop the Inverse ARP request if it has not yet seen the PVC transition to active. Inverse ARP runs every 60 seconds to relearn the dynamic address mapping information for the active RP.
ATM OAM Managed PVC or SVC Timeout
Operation, Administration, and Maintenance (OAM) F5 loopback cells must be echoed back on receipt by the remote host, thus demonstrating connectivity on the PVC between the router and the remote host. With ATM SSO, OAM loopback cells received on an interface must be echoed within 15 seconds before a PVC or switched virtual circuit (SVC) is declared down. By default, the OAM timeout is set to 10 seconds, followed by at most five retries sent at 1-second intervals. In the worst case, a switchover will begin just before expiration of the 10-second period, meaning that the PVC will go down within 5 seconds on the remote networking device if switchover has not completed within 5 seconds.
Note
Frame Relay Stateful Switchover
With stateful switchover, Frame Relay dynamic state information is synchronized between the active RP and standby RP. Thus when the active RP fails, the standby RP can take over without spending excessive time relearning the dynamic state information, and forwarding devices can continue to forward packets with only a few seconds of interruption (less on some platforms).
Permanent Virtual Circuits
For Frame Relay to support forwarding during and after switchover, Frame Relay PVCs must remain up not only within the networking device, but also within the Frame Relay network.
In many cases the networking devices are connected to a switch, rather than back-to-back to another networking device, and that switch is not running Cisco IOS XE Software. The virtual circuit state is dependent on line state. PVCs are down when the line protocol is down. PVCs are up when the line protocol is up and the PVC status reported by the adjacent switch is active.
On point-to-point subinterfaces, or when static mappings are configured, Inverse ARP need not run. In cases where dynamic address mapping is used, an Inverse ARP protocol exchange determines the protocol address to data-link connection identifier (DLCI) mapping for the PVC. This exchange occurs as soon as the multipoint PVC makes the transition to active. If the exchange fails for some reason, for example, the remote networking device may drop the Inverse ARP request if it has not yet seen the PVC transition to active—any outstanding requests are run off a timer, with a default of 60 seconds.
Keepalive Messages
A crucial factor in maintaining PVCs is the delivery of Local Management Interface (LMI) protocol messages (keepalives) during switchover. This keepalive mechanism provides an exchange of information between the network server and the switch to verify that data is flowing.
If a number of consecutive LMI keepalives messages are lost or in error, the adjacent Frame Relay device declares the line protocol down and all PVCs on that interface are declared down within the Frame Relay network and reported as such to the remote networking device. The speed with which a switchover occurs is crucial to avoid the loss of keepalive messages.
The line protocol state depends on the Frame Relay keepalive configuration. With keepalives disabled, the line protocol is always up as long as the hardware interface is up. With keepalives enabled, LMI protocol messages are exchanged between the networking device and the adjacent Frame Relay switch. The line protocol is declared up after a number of consecutive successful LMI message exchanges.
The line protocol must be up according to both the networking device and the switch. The default number of exchanges to bring up the line protocol is implementation-dependent: Three is suggested by the standards; four is used on a Cisco Frame Relay switch, taking 40 seconds at the default interval of 10 seconds; and two is used on a Cisco IOS XE networking device acting as a switch or when connected back-to-back. This default number could be extended if the LMI "autosense" feature is being used while the LMI type expected on the switch is determined. The number of exchanges is configurable, although the switch and router may not have the same owner.
The default number of lost messages or errors needed to bring down the line is three (two on a Cisco IOS XE router). By default, if a loss of two messages is detected in 15 to 30 seconds, then a sequence number or LMI type error in the first message from the newly active RP takes the line down.
If a line goes down, consecutive successful LMI protocol exchanges (default of four over 40 seconds on a Cisco Frame Relay switch; default of two over 20 seconds on a Cisco IOS XE device) will bring the line back up again.
PPP and Multilink PPP Stateful Switchover
With stateful switchover, specific PPP state information is synchronized between the active RP and standby RP. Thus when the active RP fails, the standby RP can take over without spending excessive time renegotiating the setup of a given link. As long as the physical link remains up, forwarding devices can continue to forward packets with only a few seconds of interruption (less on some platforms). Single-link PPP and Multilink PPP (MLP) sessions are maintained during RP switchover for IP connections only.
PPP and MLP support many Layer 3 protocols such as IPX and IP. Only IP links are supported in SSO. Links supporting non IP traffic will momentarily renegotiate and resume forwarding following a switchover. IP links will forward IP traffic without renegotiation.
A key factor in maintaining PPP session integrity during a switchover is the use of keepalive messages. This keepalive mechanism provides an exchange of information between peer interfaces to verify data and link integrity. Depending on the platform and configuration, the time required for switchover to the standby RP might exceed the keepalive timeout period. PPP keepalive messages are started when the physical link is first brought up. By default, keepalive messages are sent at 10-second intervals from one PPP interface to the other PPP peer.
If five consecutive keepalive replies are not received, the PPP link would be taken down on the newly active RP. Caution should be used when changing the keepalive interval duration to any value less than the default setting.
Only in extremely rare circumstances could the RP switchover time exceed the default 50-second keepalive duration. In the unlikely event this time is exceeded, the PPP links would renegotiate with the peers and resume IP traffic forwarding.
Note
HDLC Stateful Switchover
With stateful switchover, High-Level Data Link Control (HDLC) synchronizes the line protocol state information. Additionally, the periodic timer is restarted for interfaces that use keepalive messages to verify link integrity. Link state information is synchronized between the active RP and standby RP. The line protocols that were up before the switchover remain up afterward as long as the physical interface remains up. Line protocols that were down remain down.
A key factor in maintaining HDLC link integrity during a switchover is the use of keepalive messages. This keepalive mechanism provides an exchange of information between peer interfaces to verify data is flowing. HDLC keepalive messages are started when the physical link is first brought up. By default, keepalive messages are sent at 10-second intervals from one HDLC interface to the other.
HDLC waits at least three keepalive intervals without receiving keepalive messages, sequence number errors, or a combination of both before it declares a line protocol down. If the line protocol is down, SSO cannot support continuous forwarding of user session information in the event of a switchover.
Note
Quality of Service
The modular QoS CLI (MQS)-based QoS feature maintains a database of various objects created by the user, such as those used to specify traffic classes, actions for those classes in traffic policies, and attachments of those policies to different traffic points such as interfaces. With SSO, QoS synchronizes that database between the primary and secondary RP.
IPv6 Support for Stateful Switchover
IPv6 neighbor discovery supports SSO using Cisco Express Forwarding. When switchover occurs, the Cisco Express Forwarding adjacency state, which is checkpointed, is used to reconstruct the neighbor discovery cache.
Line Card Drivers
Platform-specific line card device drivers are bundled with the Cisco IOS XE Software image for SSO and are correct for a specific image, meaning they are designed to be SSO-aware.
Line cards used with the SSO feature periodically generate status events that are forwarded to the active RP. Information includes the line up or down status, and the alarm status. This information helps SSO support bulk synchronization after standby RP initialization and support state reconciliation and verification after a switchover.
Line cards used with the SSO feature also have the following requirements:
•
•
•
Note
Routing Protocols and Nonstop Forwarding
Cisco nonstop forwarding (NSF) works with SSO to minimize the amount of time a network is unavailable to its users following a switchover. When a networking device restarts, all routing peers of that device usually detect that the device went down and then came back up. This down-to-up transition results in what is called a "routing flap," which could spread across multiple routing domains. Routing flaps caused by routing restarts create routing instabilities, which are detrimental to the overall network performance. Cisco NSF helps to suppress routing flaps, thus improving network stability.
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. Data traffic is forwarded through intelligent line cards while the standby RP assumes control from the failed active RP during a switchover. The ability of line cards to remain up through a switchover and to be kept current with the FIB on the active RP is key to Cisco NSF operation.
A key element of Cisco NSF is packet forwarding. In Cisco networking devices, packet forwarding is provided by Cisco Express Forwarding. Cisco Express Forwarding maintains the FIB, and uses the FIB information that was current at the time of the switchover to continue forwarding packets during a switchover. This feature eliminates downtime during the switchover.
Cisco NSF supports the BGP, IS-IS, and OSPF routing protocols. In general, these routing protocols must be SSO-aware to detect a switchover and recover state information (converge) from peer devices. Each protocol depends on Cisco Express Forwarding to continue forwarding packets during switchover while the routing protocols rebuild the Routing Information Base (RIB) tables.
Note
For more information on Cisco NSF, see the "Additional References" section.
Network Management
Network management support for SSO is provided through the synchronization of specific SNMP data between the active and standby RPs. From a network management perspective, this functionality helps to provide an uninterrupted management interface to the network administrator.
Note
For more information on SNMP support for SSO, see the "Additional References" section.
How to Configure Stateful Switchover
The following sections describe the configuration tasks for the SSO feature. Each task in the list is identified as either required or optional.
•
•
•
•
•
•
Copying an Image onto an RP
Before you copy a file to flash memory, be sure that ample space is available in flash memory. Compare the size of the file you are copying to the amount of available flash memory shown. If the space available is less than the space required by the file you will copy, the copy process will not continue and an error message similar to the following will be displayed:
%Error copying tftp://image@server/tftpboot/filelocation/imagename (Not enough space on device).This task explains how to copy a Cisco IOS image onto the active and standby RP devices using TFTP.
SUMMARY STEPS
1.
2.
or
copy tftp harddisk:image
3.
or
copy tftp stby-harddisk:image
4.
DETAILED STEPS
Copying a Consolidated Package or Subpackages onto Active and Standby RPs on the Cisco ASR 1000 Series Router
For examples of copying consolidated packages and subpackages on the Cisco ASR 1000 Series Router, see the Cisco ASR 1000 Series Aggregation Services Routers Software Configuration Guide.
Setting the Configuration Register and Boot Variable
This task describes how to set the boot image file and to modify the software configuration register boot field so that the system boots the proper image. Following the reload, each RP is in its default mode. SSO is the default mode for the Cisco ASR 1000 Series Routers. The default configuration register value is 0x102. However, on a reload, the system is booted with the last saved value.
SUMMARY STEPS
1.
2.
3.
4.
or
no boot system tftp filename [ip-address]
5.
or
boot system tftp filename [ip-address]
6.
7.
8.
9.
DETAILED STEPS
Configuring SSO
The following task describes how to configure SSO.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Configuring Frame Relay SSO to Synchronization LMI Sequence Numbers
This task describes how to configure Frame Relay SSO to synchronize LMI sequence numbers between the active and standby RPs. This procedure is only for devices supporting Frame Relay and is optional.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Verifying SSO Configuration
This task shows how to verify that SSO is configured on the networking device.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Troubleshooting Stateful Switchover
The following sections can help you troubleshoot SSO operation:
•
Possible SSO Problem Situations
This section describes possible situations in which SSO troubleshooting may be needed.
•
Router# show redundancy history•
For example, during the upgrade process different images will be loaded on the RPs for a short period of time. If a switchover occurs during this time, the device will recover in RPR mode.
•
•
This is normal behavior. Until the ISSU procedure is complete, each RP will be running a different software version. While the RPs are running different software versions, the mode will change to RPR. The device will change to SSO mode once the upgrade has completed. For more information on ISSU, see the "In Service Software Upgrade" chapter in the Cisco ASR 1000 Series Aggregation Services Routers Software Configuration Guide.
•
SSO Troubleshooting
The following commands may be used as needed to troubleshoot the SSO feature. These commands do not have to be entered in any particular order.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
progression | status | timer}13.
14.
15.
DETAILED STEPS
Configuration Examples for Configuring Stateful Switchover
This section provides the following configuration examples:
•
•
•
•
Copying an Image onto an RP: Example
The following example shows how to copy an SSO-aware software image to flash memory on each of the RPs:
Router> enableRouter# copy tftp bootflash:asr1000rp1-adventerprisek9.02.01.00.122-33.XNA.binCopying a Consolidated Package or Subpackages onto Active and Standby RPs on the Cisco ASR 1000 Series Router: Examples
For examples of copying consolidated packages and subpackages on the Cisco ASR 1000 Series Router, see the Cisco ASR 1000 Series Aggregation Services Routers Software Configuration Guide.
Setting the Configuration Register and Boot Variable: Examples
The examples in this section configure the configuration register boot variable to boot from flash and then reload the upgraded software:
Router# show versionRouter# configure terminalRouter(config)# no boot system flashRouter(config)# boot system asr1000rp1-adventerprisek9.02.01.00.122-33.XNA.binRouter(config)# config-register 0x2101Router(config)# exitRouter# copy running-config startup-configRouter# reloadConfiguring SSO: Example
In the following example, SSO mode is configured on the on the active RP and standby RP:
Router# configure terminalRouter(config)# redundancyRouter(config-red)# mode ssoRouter(config-red)# exitRouter(config)# exitRouter# copy running-config startup-configFor examples of configuring SSO in single and dual RP configurations on the Cisco ASR 1000 Series Router, see the Cisco ASR 1000 Series Aggregation Services Routers Software Configuration Guide.
Configuring Frame Relay to Synchronize LMI Sequence Numbers: Example
In the following example, Frame Relay SSO is configured to support autosynchronization of LMI sequence numbers between the active RP and standby RP:
Router# configure terminalRouter(config)# frame-relay redundancy auto-sync lmi-sequence-numbersVerifying SSO Configuration: Examples
This section provides the following configuration examples:
•
•
Verifying that SSO Is Configured on the Cisco ASR 1000 Series Router: Examples
In the following example, the show redundancy command with the states keyword is used to verify that SSO is configured on the Cisco ASR 1000 Series Router:
Router# show redundancy statesmy state = 13 -ACTIVEpeer state = 8 -STANDBY HOTMode = DuplexUnit ID = 49Redundancy Mode (Operational) = ssoRedundancy Mode (Configured) = ssoRedundancy State = ssoMaintenance Mode = DisabledManual Swact = enabledCommunications = Upclient count = 67client_notification_TMR = 30000 millisecondsRF debug mask = 0x0Verifying SSO Protocols and Applications on the Cisco ASR Series Router: Example
Enter the show redundancy command with the client keyword to display the list of applications and protocols that have registered as SSO protocols or applications on the Cisco ASR 1000 Series Router:
Router# show redundancy clientsclientID = 0 clientSeq = 0 RF_INTERNAL_MSGclientID = 29 clientSeq = 60 Redundancy Mode RFclientID = 139 clientSeq = 62 IfIndexclientID = 25 clientSeq = 69 CHKPT RFclientID = 1340 clientSeq = 90 ASR1000-RP PlatformclientID = 1501 clientSeq = 91 Cat6k CWAN HAclientID = 78 clientSeq = 95 TSPTUN HAclientID = 305 clientSeq = 96 Multicast ISSU ConsoclientID = 304 clientSeq = 97 IP multicast RF ClieclientID = 22 clientSeq = 98 Network RF ClientclientID = 88 clientSeq = 99 HSRPclientID = 114 clientSeq = 100 GLBPclientID = 1341 clientSeq = 102 ASR1000 DPIDXclientID = 1505 clientSeq = 103 Cat6k SPA TSMclientID = 1344 clientSeq = 110 ASR1000-RP SBC RFclientID = 227 clientSeq = 111 SBC RFclientID = 71 clientSeq = 112 XDR RRP RF ClientclientID = 24 clientSeq = 113 CEF RRP RF ClientclientID = 146 clientSeq = 114 BFD RF ClientclientID = 306 clientSeq = 120 MFIB RRP RF ClientclientID = 1504 clientSeq = 128 Cat6k CWAN InterfaceclientID = 75 clientSeq = 130 Tableid HAclientID = 401 clientSeq = 131 NAT HAclientID = 402 clientSeq = 132 TPM RF clientclientID = 5 clientSeq = 135 Config Sync RF clienclientID = 68 clientSeq = 149 Virtual Template RFclientID = 23 clientSeq = 152 Frame RelayclientID = 49 clientSeq = 153 HDLCclientID = 72 clientSeq = 154 LSD HA ProcclientID = 113 clientSeq = 155 MFI STATIC HA ProcclientID = 20 clientSeq = 171 IPROUTING NSF RF cliclientID = 100 clientSeq = 173 DHCPCclientID = 101 clientSeq = 174 DHCPDclientID = 74 clientSeq = 183 MPLS VPN HA ClientclientID = 34 clientSeq = 185 SNMP RF ClientclientID = 52 clientSeq = 186 ATMclientID = 69 clientSeq = 189 AAAclientID = 118 clientSeq = 190 L2TPclientID = 82 clientSeq = 191 CCM RFclientID = 35 clientSeq = 192 History RF ClientclientID = 90 clientSeq = 204 RSVP HA ServicesclientID = 70 clientSeq = 215 FH COMMON RF CLIENTclientID = 54 clientSeq = 220 SNMP HA RF ClientclientID = 73 clientSeq = 221 LDP HAclientID = 76 clientSeq = 222 IPRMclientID = 57 clientSeq = 223 ARPclientID = 50 clientSeq = 230 FH_RF_Event_DetectorclientID = 1342 clientSeq = 240 ASR1000 SpaFlowclientID = 1343 clientSeq = 241 ASR1000 IF FlowclientID = 83 clientSeq = 255 AC RF ClientclientID = 84 clientSeq = 257 AToM managerclientID = 85 clientSeq = 258 SSMclientID = 102 clientSeq = 273 MQC QoSclientID = 94 clientSeq = 280 Config Verify RF cliclientID = 135 clientSeq = 289 IKE RF ClientclientID = 136 clientSeq = 290 IPSEC RF ClientclientID = 130 clientSeq = 291 CRYPTO RSAclientID = 148 clientSeq = 296 DHCPv6 RelayclientID = 4000 clientSeq = 303 RF_TS_CLIENTclientID = 4005 clientSeq = 305 ISSU Test ClientclientID = 93 clientSeq = 309 Network RF 2 ClientclientID = 205 clientSeq = 311 FEC ClientclientID = 141 clientSeq = 319 DATA DESCRIPTOR RF CclientID = 4006 clientSeq = 322 Network ClockclientID = 225 clientSeq = 326 VRRPclientID = 65000 clientSeq = 336 RF_LAST_CLIENTAdditional References
The following sections provide references related to the Stateful Switchover feature.
Related Documents
High availability commands: complete command syntax, command mode, defaults, usage guidelines, and examples
Cisco nonstop forwarding
"Cisco Nonstop Forwarding" chapter in the Cisco IOS XE High Availability Configuration Guide, Release 2
DHCP proxy client
"ISSU and SSO--DHCP High Availability Features," chapter in the Cisco IOS XE IP Addressing Services Configuration Guide, Release 2
SSO - BFD
"Bidirectional Forwarding Detection" chapter in the Cisco IOS XE IP Routing Protocols, Release 2
SSO HSRP
"Configuring HSRP" chapter in the Cisco IOS XE IP Application Services Configuration Guide, Release 2
SSO and RPR on the Cisco ASR 1000 Series Routers
Cisco ASR 1000 Series Aggregation Services Routers Software Configuration Guide
SSO VRRP
"Configuring VRRP" chapter in the Cisco IOS IP XE Application Services Configuration Guide, Release 2
Basic IPv6 configuration
"Implementing IPv6 Addressing and Basic Connectivity" chapter in the Cisco IOS XE IPv6 Configuration Guide, Release 2
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
Technical Assistance
Feature Information for Stateful Switchover
Table 2 lists the features in this module and provides links to specific configuration information.
For information about a feature in this technology that is not documented here, see the Cisco IOS XE High Availability Features Roadmap.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS XE Software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card, and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Lumin, Cisco Nexus, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0910R)
Any Internet Protocol (IP) addresses or phone numbers used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2002-2009 Cisco Systems, Inc. All rights reserved.
