The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
First Published: January 8, 2009
This document describes high availability and redundancy features of the Supervisor card on the Cisco RF Gateway 10 (RFGW-10) Universal Edge Quadrature Amplitude Modulation (UEQAM).
High availability is a critical requirement in networks to provide continuous access to applications and data. It is required to minimize downtime and ensure maximum productivity in a network.
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 1:1 Supervisor Card Redundancy” section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS, Catalyst OS, 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.
This section describes the types of high availability, supervisor redundancy, and the need and cause for a Supervisor switchover on the Cisco RFGW-10:
The Cisco RFGW-10 supports two redundant Supervisor cards—one Active card and one Standby card. In a switchover, the standby Supervisor card takes over the active Supervisor card. Running the Supervisor card in RPR or SSO operating mode enables Supervisor redundancy.
The Cisco RF Gateway 10 Supervisor Engine 7-E uplink ports are not recommended for data or management traffic in Supervisor Redundancy Mode.
The Supervisor 7-E card has four uplink ports on its front panel. Only the top two ports are active in redundancy mode. However, in redundancy mode, packet loss occurs in the traffic paths between the uplink ports on the standby Supervisor card and the switch fabric on the active Supervisor card. There is no packet loss for uplink ports on active supervisors.
The uplink ports on the Cisco RFGW-10 DS-384 and the Cisco RFGW-10 DS-48 line cards are recommended for data and management traffic.
In a switchover scenario, if the active Supervisor card fails and the Standby card takes over or a manual switchover is performed, the standby Supervisor card becomes the active Supervisor. The standby Supervisor card is automatically initialized with the startup configuration of the active Supervisor card, thus shortening the switchover time.
The switchover time for a Supervisor card in RPR mode could vary from 30 seconds or longer depending on the configuration. The switchover time for a Supervisor card in SSO mode is less than 1 second.
In addition to the minimal switchover time, Supervisor redundancy supports:
Note Before removing a Supervisor card from the chassis at runtime, ensure that the card is in the standby mode. If the card is in active mode, execute the redundancy force-switchover command to change the card to the standby mode, and then remove the card from the chassis.
Tip While performing a software upgrade, load the new image on the standby Supervisor card. This minimizes the switchover downtime on the Supervisor card.
Some of the possible causes that can trigger a switchover from the active Supervisor card to the standby Supervisor card are:
In Route Processor Redundancy (RPR) mode, the standby Supervisor card completes its initialization but suspends just before parsing the startup-config. The standby Supervisor card monitors the active Supervisor card, and switches over when it detects a failure on the active Supervisor card. When the standby Supervisor card becomes active, the TCC cards and all the line cards in the chassis are reset, and the startup-config is parsed. There is a traffic outage in this mode because the line cards are reset.
The switchover time of the active Supervisor card can be 30 seconds or more depending on the configuration.
The following are synchronized between the active and the standby Supervisor cards:
The following are not synchronized between the active and standby Supervisor cards:
The standby Supervisor card loads a Cisco IOS software image at startup and initializes itself in standby mode. In the event of a switchover, the standby Supervisor card reinitializes itself as the active Supervisor card, reloads all the line cards, and restarts the system. Because all line cards are reloaded, adjacent routers detect the physical link failure for most types of point-to-point connections. The standby Supervisor card parses the complete configuration, completes the booting sequence, resets the modules to perform self diagnostics, waits for the modules to come online and builds routing tables, MAC address tables, and dynamic protocols.
In Stateful Switchover (SSO) mode, the standby Supervisor card is fully initialized and configured. This allows SSO to shorten the switchover time if the active Supervisor card fails, or if a manual switchover is performed. Both the startup and running configurations are continually synchronized from the active to the standby Supervisor cards, and the line cards are not reset during a switchover. The interfaces remain up during this transfer, so neighboring routers do not detect a physical link flap (the link does not go down and come back up).
The line cards, Layer 2 protocols, and application state information are synchronized and the standby Supervisor card is in a “hot” standby ready state to take over immediately. As the standby Supervisor card recognizes the hardware link status of every link, ports that were previously active remain active after a switchover has taken place.
The following are synchronized between the active and the standby Supervisor cards:
The following are not synchronized between the active and the standby Supervisor cards:
In the event of a switchover, the standby Supervisor card becomes the active Supervisor card. As the standby Supervisor card is continuously synchronized with the startup and running configuration, switchover downtime is minimal. The state information synchronization (often called “checkpointing”) from the active Supervisor card to the standby Supervisor card occurs at normal run time. At the switchover, the newly active Supervisor card immediately uses the state information previously synchronized (checkpointed).
The line cards are not reset as part of the switchover. The Supervisor card reconciles the line card state information with its own state information on switchover. SSO-aware features or protocols such as DHCP protocols are check pointed during switchover. Non-SSO aware features or protocols such as OSPF, BGP, Multicast PIM and IGMP, and L2VPNv3 protocols are quickly available on the standby as the standby Supervisor card is completely initialized.
SSO provides a faster switchover compared to Route Processor Redundancy (RPR) by fully initializing and configuring the standby Supervisor card. By using check pointed state information, the time required for routing protocols to converge is minimized. As protocol information, application information, and user session information are maintained during the switchover, improved network availability is provided and line cards continuously forward network traffic with no loss of sessions.
The following activities can be performed on the standby Supervisor card.
|
|
---|---|
Lists the contents of the standby bootflash: device or slot0. |
|
delete slavebootflash: <filename> or delete slaveslot0: <filename> |
|
The following features are supported for Supervisor Redundancy in SSO mode.
The running configuration and the startup configuration are synchronized from the active Supervisor card to the standby Supervisor card. The running configuration is synchronized line by line. The commands are executed on the active Supervisor card and then on the standby Supervisor card. Parser Return Code (PRC) is used to verify the active and standby Supervisor card have the same path of execution for the command.
All interfaces and ports are synchronized as part of the configuration.
Syslog alarms are synchronized to the standby Supervisor card at run time. Active alarms reside on each line card. On a Supervisor switchover, the newly active Supervisor card receives the alarms from the line cards.
The state of line cards progresses through events such as line card insertion, line card removal, line card partial reset, and line card full reset. These events and the corresponding line card states are check pointed from the active Supervisor card to the standby Supervisor card. At the Supervisor switchover, the newly active Supervisor card continues to manage the line cards with the check pointed state information.
The RF switch management maintains state information on all the RF switch cards, whether or not the card is present in the system. The state information is synchronized from the active Supervisor to the standby Supervisor card whenever the RF switch is inserted or removed.
In the Cisco IOS Release12.2(50)SQ, DEPI is configured in one of the two modes—manual mode via static DEPI path configuration or protocol mode via dynamic DEPI protocol. In DEPI manual mode, the Supervisor switchover does not affect the statically configured DEPI connections. Hence, the switchover interruption to DEPI data traffic is in subseconds.
In DEPI protocol mode, the DEPI control plane is SSO-unaware as the underlying IOS L2TPv3 protocol is SSO-unaware. Neither the L2TPv3 protocol state nor the DEPI state is checkpointed from the active Supervisor card to the standby Supervisor card. During Supervisor switchover, the DEPI control plane and data plane are recovered as follows with minimal service outage time:
The Video SSO feature is available in Cisco IOS Release 12.2(50)SQ1 and later.
Video sessions on the Cisco RFGW-10 are either unicast or multicast sessions created manually or remotely using Generic QAM Interface (GQI). At run time, the video session state information is check pointed from the active Supervisor card to the standby Supervisor card.
Unicast video sessions continue to forward traffic during Supervisor card switchover with about one second outage time.
Multicast video sessions may experience a longer outage time during Supervisor card switchover. For a small number of SDV sessions (for example, 1,000), the outage time is typically less than 4 seconds. For a large number of SDV sessions (for example, 10,000), the outage time is around 10 seconds. This is because, in Cisco IOS Release 12.2(50)SQ1, the underlying multicast function is not SSO-aware although the video session state is synchronized to the standby Supervisor card. The SSO performance of multicast video sessions will be improved in a future release.
To configure Supervisor uplink, use the following command in configuration mode:
When Supervisor uplink is configured, only specific uplink ports are active and available for uplink connectivity. If you try to configure other uplink ports, an error message similar to the following is displayed:
Table 1 , Table 2 , and Table 3 show the valid port configurations for uplink.
Table 1 Only 10-Gigabit Ethernet Ports for Uplink
|
|
|
|
---|---|---|---|
Table 2 Only Gigabit Ethernet Ports for Uplink
|
|
|
|
---|---|---|---|
Table 3 Both 10-Gigabit Ethernet and Gigabit Ethernet Ports for Uplink
|
|
|
|
---|---|---|---|
This section describes how to do a manual switchover between the active and standby Supervisor cards on the Cisco RFGW-10:
To force the active Supervisor card to standby mode and the standby to active, use the redundancy force-switchover command in privileged EXEC mode:
Before the redundancy command is used, ensure that the active and standby Supervisor cards have a high availability Cisco IOS image installed and configured for Route Processor Redundancy (RPR) mode. Before the system switches over, it verifies that the standby Supervisor card is ready to take over. If the current running configuration is different from the startup configuration, the system prompts to save the running configuration before the switchover is performed.
A manual switchover is performed for one of the following reasons:
The following example shows a switchover being initiated manually:
Note Press enter or y to confirm the action to begin the switchover. If you press any other key, the switchover is aborted.
The following example shows a switchover failure because the standby Supervisor card is either not ready, not available, or not installed:
To reset the standby Supervisor card or to reset both the active and standby Supervisor cards, use the redundancy reload command in privileged EXEC mode:
Use peer to reload only the standby Supervisor card and use shelf to reload both the active and standby Supervisor cards.
The following example shows how to reset the standby Supervisor card:
Note Press enter or y to confirm the action to begin the switchover. If you press any other key, the switchover is aborted.
The following example shows the system response when a standby Supervisor card is not installed in the router:
The following example shows how to reload both Supervisor cards:
Note Press enter or y to confirm the action to begin the switchover. If you press any other key, the switchover is aborted.
The following commands are used to perform a manual switchover from the active Supervisor card to the standby Supervisor card:
Note The redundancy force-failover main-cpu command is not supported in SSO mode.
This section describes how to configure 1:1 Supervisor card redundancy in Cisco RFGW-10:
This section describes how to configure Route Processor Redundancy (RPR).
6. auto-sync {startup-config | config_register | bootvar | standard}
The following example shows how to enter RPR and main-CPU redundancy mode:
This section describes how to configure Stateful Switchover (SSO).
The following example shows how to enter SSO redundancy mode:
This section describes how to verify 1:1 Supervisor Card Redundancy in Cisco RFGW-10:
The following is a sample output of the show redundancy command showing Supervisor Redundancy RPR mode configured the on the Cisco RFGW-10:
To verify the current Supervisor redundancy status, use the following command in user EXEC or privileged EXEC mode:
The following is sample output of the show redundancy clients command:
The following is sample output of the show redundancy counters command:
The following is sample output of the show redundancy history command:
The following is sample output of the show redundancy states command:
The following is a sample output of the show redundancy command showing Supervisor redundancy SSO mode configured using the on the Cisco RFGW-10:
To verify the current Supervisor redundancy status, use the following command in user EXEC or privileged EXEC mode:
The following is sample output of the show redundancy clients command:
The following is sample output of the show redundancy counters command:
The following is sample output of the show redundancy history command:
The following is sample output of the show redundancy states command:
The following sections provide references related to 1:1 Supervisor Card Redundancy feature.
|
|
---|---|
Cisco RF Gateway 10 Command Reference http://www.cisco.com/en/US/docs/cable/rf_gateway/command/reference/RFGW-10_Book.html |
|
Cisco RF Gateway 10 Software Feature and Configuration Guide http://www.cisco.com/en/US/docs/cable/rf_gateway/feature/guide/rfgw_scg.html |
|
|
---|---|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature. |
|
|
---|---|
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature. |
Table 4 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS, Catalyst OS, and 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 Table 4 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.