Table of Contents

GRP Redundant Processor Support

Feature Summary

Platforms

Prerequisites

Supported MIBs and RFCs

Functional Description

Configuration Tasks

Configuration Example

Command Reference

Debug Commands

GRP Redundant Processor Support

Feature Summary

The GRP redundant processor feature allows you to install two gigabit route processors (GRPs) in a Cisco 12000 series router. One GRP functions as the primary processor. The primary GRP supports all normal GRP operation. The other GRP functions as the secondary processor. The secondary GRP monitors the primary and will take over normal GRP operations if it detects a failure in the primary GRP.

The GRP redundant processor feature is not a hot standby system wherein the secondary GRP duplicates the state of the primary. The benefit of having the secondary GRP monitor the primary, rather than duplicate the primary, is that a software failure is unlikely to affect both processors. The tradeoff is that network services will be disrupted while the secondary GRP takes over and the router recovers. The recovery happens faster, however, than if the router performed a cold restart.

The primary and secondary GRP can be placed in any available card slot in the router chassis. You may want to consider physical access and cable locations when choosing where to place the GRPs.

Each GRP must have the resources to run the router on its own, which means all GRP resources are duplicated. In other words, each GRP has its own Flash device, Ethernet, serial, and console port connections. The console port connections do not use a "Y" cable. Instead, you connect a separate terminal console cable and monitor to each GRP.

You can access the secondary GRP resources while it is in standby mode. For example, you can use the copy EXEC command to transfer an image to the secondary GRP flash device. (Refer to "Device Access," later in this publication.) By default, the startup-config on the secondary GRP is always synchronized to the startup-config on the primary.

There are two common ways to use GRP redundant processor support. You can run identical Cisco IOS software on both GRPs, which protects against GRP hardware failure. Alternatively, you can run different Cisco IOS images on each GRP. This method is useful, say, when you want to run a newer Cisco IOS image on one GRP and revert to an older Cisco IOS image if you encounter problems.

Benefits

The GRP is no longer a single point of hardware failure. Any permanent hardware failure in the primary GRP is recovered by the secondary GRP, which increases the level of network service and reliability demanded by customers.

The GRP redundant processor feature is implemented with no impact on the GSR per-line switching performance, where packet routing is performed by Cisco express forwarding (CEF) in the line cards.

Restrictions

This section describes situations you must avoid and other considerations relevant to using GRP redundant processor features.

• Booting from the network is not currently supported by the GRP redundant processor feature.
  
  
• A maximum of two GRP cards may be installed in a Cisco 12000 series router chassis. The GRP redundant processor feature supports a primary and a secondary GRP.
  
  
• The GRP redundant processor feature is disabled if any Cisco IOS 11.2 GS software prior to release 11.2(15)GS2 is running on any GRP installed in the router chassis.
  
  
• The secondary GRP uses a slot in the router chassis that might otherwise be available for a line card. Therefore, in a dual-GRP system, the maximum per-chassis throughput may be less in comparison to a single-GRP system with a line card in that slot.
  
  

Cisco IOS software prior to 11.2(15)GS2 does not support redundant processors and will interfere with redundant system operation. We recommend that you install release 11.2(15)GS2 software on the bootflash: devices on the GRP and that you remove earlier versions of the Cisco IOS software.

Platforms

This feature is supported on these platforms:

• Cisco 12000 series router
  
  

Prerequisites

You must have a second GRP to install in your Cisco 12000 series router. Carefully review the information in "Installing Second GRP and Configuring Hardware Backup Task List" before installing the second GRP.

Prior to installing a second GRP, you must upgrade the Cisco IOS software on the existing GRP to a version that supports the GSR redudundancy feature.

The second GRP requires a separate terminal connected to its serial console port, and it requires a separate Ethernet connection.

Supported MIBs and RFCs

This feature supports the following MIBs:

• OldCiscoChassisMIB
  
  

For descriptions of supported MIBs and how to use MIBs, see Cisco's MIB website on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.

No RFCs are supported by this feature.

Functional Description

This section provides additional information on GRP redundant processor implementation.

• Booting and System Images
  
  
• Redundancy Arbitration
  
  
• Secondary Console
  
  
• Device Access
  
  
• Local Ethernet
  
  
• Failover
  
  
• Field Diagnostics
  
  
• System Logs
  
  
• Crash Dumps
  
  
• Additional Diagnostic Aids
  
  
• Additional GRPs
  
  

Booting and System Images

On hardware reset, each GRP in a dual GRP system will boot the Cisco IOS image specified in the startup-config. The image specification is identified in a ROM monitor variable, and it is this variable, in combination with the config-register settings, that determines the boot image. In basic redundant GRP operations, the two GRPs run identical Cisco IOS images and identical configurations. User and configuration commands assist this duplication of software and data.

It is also possible to run dual GRPs with different IOS images and configurations in the two GRPs. This is useful if you want to experiment with a different IOS version or try new configuration features while providing for automated fallback to a previous version.

When a GRP that supports redundancy detects another GRP running an earlier version of Cisco IOS software that does not support redundancy, the former GRP will reload itself and enter a wait state. This action allows the latter GRP to operate without interference so that it can be reconfigured and loaded with Cisco IOS software that supports redundant processors.

Redundancy Arbitration

After the GRPs have booted the Cisco IOS software, but before they parse the startup-config, the two GRPs arbitrate to decide which one should be the primary and which one should be the secondary. If all else is equal, the GRP in the lowest- numbered slot will become the primary. If the GRPs differ in some way, such as running different versions of software or firmware, the arbitration mechanism makes the best choice as determined by the arbitration algorithms. These may account for the versions of IOS running on the GRPs, how recent the startup-configs are, and whether the startup-config was saved in this chassis.

Once the arbitration mechanism selects a primary GRP, it will load its startup-config. If the startup-config does not explicitly disallow it, the primary GRP ensures that the startup-config on the secondary GRP is identical to that on the primary GRP. This synchronization typically involves copying the startup-config to the secondary GRP. The primary also loads the linecards and completes the remainder of the initialization.

Choosing the correct primary GRP is important. If only one of the two GRPs has a valid startup-config, that GRP becomes the primary. If a GRP with an invalid startup-config became primary, that invalid configuration could be copied to the other GRP, destroying the correct version. Avoiding an invalid startup-config is why the arbitration mechanism evaluates whether a GRP has a startup-config that was saved while in this router chassis, and whether the startup-config is the most recent one saved in the chassis.

You can override most of the arbitration mechanism and specify that the GRP in a particular slot is the primary whenever the system boots. See the command description for the redundancy prefer EXEC command for usage guidelines.

Secondary Console

The console port on the secondary GRP appears directly connected to a vty port on the primary GRP. This allows either console to be used to monitor and control the router. However, if there is a permanent failure on one GRP, you can use the console connected directly to the other GRP. This is why you have separate connections to the console ports of both GRPs.

Device Access

When the GSR is running in redundant mode, the primary GRP can access the secondary GRP NVRAM and Flash.

Most users will want to keep the startup-config file on the secondary GRP identical to the startup-config file on the primary GRP. Automatic synchronization is enabled by default and can be configured by using the auto-sync main-CPU redundancy configuration command. In auto-sync mode, changes to the primary startup-config file are automatically applied to the secondary.

No equivalent synchronization mechanism exists for the Flash devices. The Flash devices must be synchronized manually if you want to keep the Flash on the secondary GRP identical to the Flash in on the primary GRP.

When using file management commands such as copy and delete, you can specify the command affects the secondary GRP by adding "sec-" to the device name. For example,

copy slot0: sec-slot0:

Device names that accept sec- are as follows:

sec-slot0:
sec-slot1:
sec-bootflash:
sec-nvram:
 

Whenever you update the startup-config file on the secondary GRP, that action updates the ROM monitor variables and the configuration register on the secondary GRP.

These settings may not be exact copies of the primary's ROM monitor variables and configuration register. Instead, the variables and settings are set to appropriate values, as determined by the primary GRP, which may differ from those on the primary due to specific hw-module global configuration commands. The end result is that any ROM and configuration register settings on the secondary GRP are overwritten by the values chosen by the primary GRP.

Local Ethernet

The GSR router provides one Ethernet port for each GRP. However, software restrictions limit the router to using only the Ethernet port on the primary GRP. The MAC address for the Ethernet port is held in the chassis NVRAM, while the IP address is be taken from the startup-config. The same MAC address and, typically, the same IP address will be used regardless of which GRP is primary.

The router loses no functionality by not using the Ethernet port on the secondary. For security reasons, access to the secondary is mediated by the primary. Restricting Ethernet access to the primary Ethernet port fits into this access model.

There are some consequences due to these restrictions, including the following:

• Network booting from local Ethernet is not currently allowed. Booting is restricted to Flash.
  
  
• If a primary GRP fails, it does not attempt to use its Ethernet to send a core dump. Instead, it informs the secondary GRP that a dump is available. When the secondary is ready to process the dump, it will request the crash data from the failed primary, then send it to the network destination defined in the exception dump global configuration command.
  
  

Failover

The term failover describes the event when one GRP card takes over operation from another. A failover can be forced, by entering the redundancy force-failover EXEC command, or a failover occurs when the primary GRP fails and the secondary GRP takes over.

The secondary GRP monitors so-called heartbeat messages from the primary GRP. If no heartbeat messages are detected for a few seconds, the secondary takes over router operations from the failed primary. The primary also monitors heartbeat messages from the secondary and attempts to reload the secondary if the heartbeats cease.

When failover occurs, it interrupts system operation momentarily. The following events occur during failover:

• The failed primary GRP will be reset and reloaded, assuming the GRP is properly configured.
  
  
• Linecards are reloaded to bring them to a known state.
  
  
• The router stops passing traffic.
  
  
• Route information is lost.
  
  
• All connections are lost.
  
  
• The secondary GRP card takes over as the primary GRP. Because this formerly-secondary GRP card has separate image and configuration files, it can act as the sole processor. It will establish connections with any peer routers to discover route information. The routing tables are thereby regenerated and downloaded to the linecards.
  
  

When a primary GRP detects a fatal hardware or software error, it sends a message to the secondary GRP. In this instance, the secondary takes over immediately, without waiting the few seconds for the heartbeat detection logic to discover the failure.

The failover event is logged, and can be viewed via the show redundancy arbitration EXEC command.

Field Diagnostics

You can run field diagnostics on the secondary GRP, from the primary GRP, while the router is handling traffic. Make certain before you start the diagnostics that the console you are using is not connected via the secondary GRP. When the diagnostics finish running, the secondary GRP remains at the ROM monitor prompt and must be manually rebooted.

System Logs

The primary GRP broadcasts system log messages to the secondary, where they are saved. When a failover occurs, you can see the system log messages that preceded this event by issuing the show  log  slot  number EXEC command on the new primary, where the slot number is that of the failed primary.

Issuing the show  log  slot  number command, where the slot number is that of a linecard rather than the slot number of the failed GRP, shows messages sent to the previous primary, followed by a failover message and the messages that were sent to the new primary.

Crash Dumps

Using the exception dump global configuration command, the GRP can be configured to create a core file (also called a crash dump) when it fails. When the primary GRP fails, it waits for the secondary GRP to become the new primary. Once the new primary GRP is running, it checks its configuration. If exception dump is enabled, it receives the core files from the failed GRP. The primary writes the core files to the network the same as it would for any failed line card.

A timer runs on the failed GRP. If the secondary GRP does not take over as the new primary, the failed primary GRP will reboot and resume operation as the primary. If the failed GRP reboots, it loses the core file.

Additional Diagnostic Aids

The show redundancy EXEC command shows the current redundancy status. Various options to this command can display additional details of the arbitration mechanism, traces of the arbitration protocol, or details of the secondary GRP.

The show boot EXEC command shows details of both primary and secondary GRP boot parameters.

The show user EXEC command is useful to discover which console port you are using--- the console port on the primary GRP, the console port on the secondary GRP, or some other connection.

Additional GRPs

The redundant support mechanism is designed for two GRPs in a single chassis. If three or more GRPs are installed in a router chassis, the arbitration mechanism identifies a primary and secondary GRP and temporarily disables any additional GRPs from participating in the arbitration process.

Configuration Tasks

By using GRP redundant processor support on the Cisco 12000 series router, you improve system availability by installing two GRPs in a Cisco 12000 series router. One GRP functions as the primary processor. The primary GRP supports all normal GRP operation. The other GRP functions as the secondary processor. The secondary GRP monitors the primary and will take over normal GRP operations if it detects a failure in the primary GRP.

Review the following sections before beginning the GRP redundancy configuration tasks:

• Using GRP Redundancy for Hardware and Software Protection
  
  
• Understanding System Requirements
  
  
• Configuration Tasks Overview
  
  

Using GRP Redundancy for Hardware and Software Protection

There are two common ways to use GRP redundant processor support, namely:

• Simple hardware backup
  
  

This method protects against a GRP card failure. The primary and secondary GRP cards are configured with the same software image and configuration information. The startup-config information on both GRPs is synchronized automatically, which ensures that the configuration information on both GRPs remains identical.

• Software error protection
  
  

This method protects against critical Cisco IOS software errors in a particular release. The primary and secondary GRP cards are configured with different software images, but with the same configuration information. If you are using new or experimental Cisco IOS software, consider using the software error protection method.

You can also use GRP redundant processor support for advanced implementations. For example, you can configure the GRP cards with the following:

• Similar software versions, but different configuration files
  
  
• Different software images and different configuration files
  
  

Understanding System Requirements

To configure GRP redundant processor operation, you must have a Cisco 12000 series router containing one GRP processor card and a second GRP processor card available to install as the secondary GRP.

You must have a version of Cisco IOS software installed that supports the GRP redundant processor feature in a Cisco 12000 series router. Table 1 lists the minimum Cisco IOS software releases and image names for GRP redundant processor support.

Configuration Tasks Overview

Specific tasks for GRP redundant processor configuration on a Cisco 12000 series router are described in the following sections:

• Installing Second GRP and Configuring Hardware Backup Task List
  
  
• Configuring Software Error Protection Task List
  
  
• Managing The Primary and Secondary GRP Task List
  
  
• Monitor and Maintain GRP Redundant Processor Operation Task List
  
  

Installing Second GRP and Configuring Hardware Backup Task List

When installing a second GRP in a Cisco 12000 series router, complete the tasks in the following sections. All tasks in the following list are required for configuring simple hardware backup.

• Verify Cisco IOS Software Version on the Installed GRP
  
  
• Verify Cisco IOS Software Installed in Bootflash
  
  
• Install Firmware Upgrades
  
  
• Configure Redundancy on the Installed GRP
  
  
• Prepare the Flash Device for the New GRP
  
  
• Install the New GRP and Boot to ROM Monitor Prompt
  
  
• Boot the Primary and Secondary GRPs in Sequence
  
  
• Verify Redundant Operation
  
  
• Verify and Update Cisco IOS Software on Secondary GRP
  
  

Verify Cisco IOS Software Version on the Installed GRP

To verify that the Cisco IOS software version is one that supports the GRP redundancy feature, perform the following task, beginning in privileged EXEC mode:

Examine the output and verify that the Cisco IOS software version and image name match what is shown in Table 1. If necessary, install a newer version of the Cisco IOS software. The Cisco IOS 11.2 document Configuration Fundamentals Configuration Guide, in the chapter "Loading Images and Configuration Files" contains complete procedures for installing system software into the router Flash device.

Verify Cisco IOS Software Installed in Bootflash

In addition to the normal system image, verify that the system image(s) on the bootflash device supports dual GRP operation. Perform the following task, beginning in privileged EXEC mode:

-----date/time------ name
Oct 11 1998 19:07:25 gsr-boot-mz.112-15GS2

Install Firmware Upgrades

The system may detect that the hardware contains obsolete firmware for such things as the fabric loader and the ROM monitor. If you see messages at boot time that warn you of obsolete or older versions of firmware, install the firmware upgrades before you install the second GRP.

To define the default secondary GRP, perform the following task, beginning in privileged EXEC mode:

Configure Redundancy on the Installed GRP

To configure the installed GRP for redundancy operation, perform the following tasks, beginning in privileged EXEC mode:

Use the show redundancy EXEC command to display redundancy information currently configured on the GRP. Look for the line

Prepare the Flash Device for the New GRP

The tasks in this section prepare the Flash device on the new GRP by copying the contents of the existing GRP Flash device to the new GRP Flash device. The steps below assume that the existing GRP has a Flash device installed in PCMCIA slot 0 and that the system image file is located on that device.

To prepare the Flash device for the new GRP, perform the following tasks, beginning in privileged EXEC mode:

Install the New GRP and Boot to ROM Monitor Prompt

To this point, you have completed the following:

• Configured the existing GRP to operate in redundant mode.
  
  
• Copied the contents of the existing GRP Flash device to the new GRP Flash device.
  
  
• Prepared the new GRP for installation into the router chassis.
  
  

To install the new GRP and boot it to the ROM monitor prompt, perform the following task:

Boot the Primary and Secondary GRPs in Sequence

For the final phase of preparing your router to operate with redundant processors, you will install and boot the original (primary) GRP then boot the new (secondary) GRP. To boot the primary and secondary GRPs in sequence, perform the following tasks:

boot slot0:gsr-boot-mz.112-15GS2 

When the new, secondary GRP boots, it should be recognized by the primary GRP. If console logging is enabled, the following message is displayed on the primary and the secodary GRP consoles:

%MBUS-6-GRP_STATUS:GRP in Slot # Mode = MBUS Secondary
 

Verify Redundant Operation

To verify redundant operation, perform the following task, beginning in EXEC mode:

The following excerpt from the show redundancy command shows that a primary and a secondary GRP are installed and recognized by the router:

show redundancy
Primary   GRP in slot 8:
Secondary GRP in slot 1:
 

The following excerpt from the show boot command shows that the boot variables (BOOT, CONFIG_FILE, configuration register) for both GRPs are the same:

show boot
BOOT variable = slot0:gsr-p-mz,1;
CONFIG_FILE variable = nvram:
Current CONFIG_FILE variable = nvram:
Configuration register is 0x2
...
Secondary is in slot 1
Secondary BOOT variable = slot0:gsr-p-mz,1;
Secondary CONFIG_FILE variable = nvram:
Secondary configuration register is 0x2
 

Verify and Update Cisco IOS Software on Secondary GRP

After the system boots with the software that supports GRP redundancy, you can verify and update the Cisco IOS software on the secondary GRP. Perform the following task, beginning in privileged EXEC mode:

-----date/time------ name
Oct 11 1998 19:07:25 gsr-boot-mz.112-15GS2

Configuring Software Error Protection Task List

To configure software error protection, the primary GRP and the secondary GRP run different images. Complete the tasks in the following sections to configure the primary and secondary GRP to run the two selected images. You must have two GRPs installed in the router and they must be running identical images. Refer to "Installing Second GRP and Configuring Hardware Backup Task List," earlier in this publication.

This feature is not required for normal GRP operations.

Complete the tasks in the following list to configure different images on the primary and secondary GRP. The first two tasks are required.

• Copy the System Images to Flash Devices
  
  
• Configure the GRPs to Boot Different Images
  
  

Copy the System Images to Flash Devices

To copy system images to Flash devices, perform the following task, beginning in privileged EXEC mode:

Configure the GRPs to Boot Different Images

In the next task, you configure the primary and secondary GRP to boot different system images. The task steps assume that the primary GRP is installed in card slot 1 and the secondary GRP is installed in card slot 2.

Perform the following task, beginning in privileged EXEC mode:

You can verify that the different boot files are configured for each GRP by using the show boot EXEC command, as follows:

router# show boot
   BOOT variable = slot0:image1,1;
   ....
   Secondary BOOT variable = slot0:image2,1;
   ....
 

Managing The Primary and Secondary GRP Task List

The tasks in the following sections show how to manage the primary and secondary GRPs. You can select and deselect a preferred primary GRP, and configure the router for single-GRP operation. These tasks are optional:

• Configure A Preferred Primary
  
  
• Remove a Preferred Primary Configuration
  
  
• Revert to Single GRP Operation
  
  

Configure A Preferred Primary

The arbitration process determines which GRP will become the primary and which will serve as the secondary. When the primary GRP and the secondary GRP are configured to boot different system images, the GRP that boots the most recent version is chosen, by default, as the primary GRP.

However, you can override the arbitration process and specify which GRP will be the primary. To configure a preferred primary GRP, perform the following task, beginning in privileged EXEC mode:

Remove a Preferred Primary Configuration

To remove a preferred primary GRP configuration, perform the following task, beginning in privileged EXEC mode:

Revert to Single GRP Operation

You can revert to single GRP operation in the router and disable the redundant GRP feature. Determine which GRP to remove from redundant operation. Note the slot number of that GRP, which you will use when you reconfigure the router for single-GRP operation.

To revert to single-GRP operation, perform the following task, beginning in privileged EXEC mode:

The unused GRP reloads and remains at the ROM monitor prompt until you remove it from the router chassis or you reload it by using the ROM monitor boot command. You need not disable a GRP via the command line interface. Simply removing one of the GRPs will cause the router to revert to redundant operation. Reverting to single-GRP operation by using the command line interface is useful when you suspect problems with a GRP but cannot get to the router to pull out the GRP card.

Monitor and Maintain GRP Redundant Processor Operation Task List

To monitor and maintain GRP redundant processor operation, complete the tasks in the following sections:

• Troubleshoot a Failed GRP Card
  
  
• Display Information about Primary and Secondary GRP Cards
  
  
• Display Logs for Primary and Secondary GRP Cards
  
  
• Alphanumeric LED Messages
  
  

Troubleshoot a Failed GRP Card

When a new primary GRP card takes over mastership of the router, it automatically reboots the failed GRP card as the secondary GRP card.

You can also manually reload a failed, inactive GRP card from the primary console. This task returns the card to the active secondary state. If the primary GRP fails, the secondary will be able to become the primary. To manually reload the inactive GRP card, perform the following task from global configuration mode:

Display Information about Primary and Secondary GRP Cards

You can also display information about both the primary and secondary GRP cards. To do so, perform any of the following tasks from EXEC mode:

Display Logs for Primary and Secondary GRP Cards

You can display the logging information about the primary and secondary GRP cards. To do so, perform the following tasks from EXEC mode:

The log information shows what activity was occuring on the card at the time of failure.

Alphanumeric LED Messages

Table 2 shows additional alphanumeric LED messages that may be displayed when a GRP is running a version of Cisco IOS software that supports GRP redundancy.

Configuration Example

The following configuration example shows excerpts from a basic GRP redundant processor setup. Specific configurations for the various interfaces and line cards are ommitted from this example.

!
hostname Router
!
boot system flash slot0:gsr-p-mz
enable password xyzzy
.....
redundancy
 main-cpu
  auto-sync startup-config
.....
exception core-file /tfpboot/myname/myrouter.core
exception protocol ftp
exception dump 123.45.67.89 
exception suffix slot-number
...
ip ftp source-interface Ethernet0
ip ftp username myname
ip ftp password mypassword
ip host myhost 123.45.67.90
...
end

Command Reference

This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 11.3 command references.

• auto-sync
  
  
• hw-module boot system
  
  
• hw-module config-register
  
  
• hw-module secondary reload
  
  
• main-cpu
  
  
• redundancy
  
  
• redundancy force-failover
  
  
• redundancy prefer
  
  
• show boot
  
  
• show redundancy
  
  

auto-sync

Use the auto-sync main-CPU redundancy configuration command to define whether the startup-config, boot variables, and config-register on the secondary GRP will be synchronized to the values currently stored on the primary GRP. Use the no form of the command to negate an auto-sync selection.

Syntax Description

Default

Auto-sync is performed.

Command Mode

Main-CPU redundancy

Usage Guidelines

This command first appeared in Cisco IOS Release 11.2 GS.

Two GRP cards must be installed in the router for this command to take effect.

All synchronizations move from the primary GRP to the secondary GRP.

An auto-sync between the primary GRP and the secondary GRP happens when the command is entered. There is a momentary pause at the terminal console while the synchronization occurs.

Whenever the primary GRP startup-config changes, a copy is sent to the secondary startup-config. The secondary startup-config is also synchronized when the secondary first boots.

The config-register and boot variables on the secondary are also synchronized to values specified in the startup-config. You can use hw-module global configuration commands to specify different boot images and config-register settings on the primary and the secondary.

Example

The following example configures synchronization between the primary and secondary GRP:

router(config)# redundancy
router(config-r)# main-cpu
router(config-r-mc)# auto-sync startup-config 
 

Related Commands

main-cpu

redundancy

hw-module boot system

Use the hw-module boot  system global configuration command to define system boot parameters when these are different on the primary GRP and the secondary GRP. Use the no form of this command to remove the startup system image specification.

hw-module slot number boot system flash [device:][filename]
no hw-module slot number boot system flash [device:][filename]

Syntax Description

Default

The route processor uses the values set by the boot system command, when no other explicit boot parameters are defined for a particular slot.

The router uses the configuration register settings to determine the default system image filename. The router forms the default boot filename by starting with the word cisco and then appending the octal equivalent of the boot field number in the configuration register, followed by a hyphen (-) and the processor type name (cisconn-cpu). See the appropriate hardware installation guide for details on the configuration register and default filename. See also the hw-module  config-register command.

Command Mode

Global configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.2 GS.

For this command to work, the config-register command must be set properly.

Use this command to specify different boot images for the primary GRP and the secondary GRP.

You can also enter several boot system commands to provide a fail-safe method for booting your router. The router stores and executes the boot system commands in the order in which you enter them in the configuration file. If you enter multiple boot commands of the same type, the router tries them in the order in which they appear in the configuration file. If a boot system command entry in the list specifies an invalid device, the router skips that entry.

Example

The following example instructs the GRP in chassis slot 3 to boot from an image located on the Flash memory card inserted in PCMCIA slot 0, and the GRP in chassis slot 0 to boot a different image located on its Flash memory card:

hw-module slot 3 boot system flash slot0:gsr-p-mz
hw-module slot 0 boot system flash slot0:gsr-p-mz.new
 

Related Commands

hw-module config-register

hw-module config-register

Use the hw-module config-register global configuration command to define different system configuration register parameters for the primary GRP and the secondary GRP. Use the no version of the command to restore default configuration register parameters.

Syntax Description

Default

When no parameters are modified by using this command, the values configured via the config-register global configuration command.

Command Mode

Global configuration

Usage Guidelines

This command first appeared in Cisco IOS Release 11.2 GS.

Use this command to set the configuration registers to different values on the primary or secondary GRP. You need not use this command when you want the same values on both the primary and secondary GRP.

Example

The following example sets the configuration register for the GRP installed in chassis slot 3:

hw-module slot 3 config-register 0x02
 

Related Commands

hw-module boot system

hw-module secondary reload

Use the hw-module secondary reload EXEC command to reload the designated secondary GRP.

Syntax Description

This command has no keywords or arguments.

Default

None

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.2 GS.

When the secondary GRP is reloaded, there is no interruption to the primary GRP activity. The secondary GRP will boot to whatever level is set by means of the configuration register (for example, only to ROM monitor prompt).

This command executes immediately and does not ask for confirmation.

Example

The following example reloads the secondary GRP from the configuration specified by the cards boot variables and configuration settings:

hw-module secondary reload
 
*Oct  2 10:20:36.866: %MBUS-6-MGMTSECRELOAD: Secondary in slot 1 reloaded by operator command
 
%MBUS-6-GRP_STATUS: GRP in Slot 1 Mode = MBUS Secondary

Related Commands

redundancy prefer

main-cpu

Use the main-cpu redundancy configuration command to enter main-CPU configuration mode.

Syntax Description

This command has no keywords or arguments.

Default

None

Command Mode

Redundancy

Usage Guidelines

This command first appeared in Cisco IOS Release 11.2 GS.

It is not necessary to have two GRP cards installed in the router before you use this command.

Example

The following example shows how to enter main-CPU configuration mode:

router(config-r)# main-cpu
 

Related Commands

configure

redundancy

Use the redundancy global configuration command to enter redundancy configuration mode.

Syntax Description

This command has no keywords or arguments.

Default

None

Command Mode

Global

Usage Guidelines

This command first appeared in Cisco IOS Release 11.2 GS.

It is not necessary to have two GRP cards installed in the router before you use this command.

After you enter redundancy configuration mode, you can enter the main-cpu command. The main-cpu command places you in the main-CPU redundancy configuration mode, which allows you to specify CPU redundancy characteristics.

Example

The following example enters redundancy configuration mode:

router(config)# redundancy 
 

Related Commands

configure

redundancy force-failover

redundancy prefer

redundancy force-failover

Use the redundancy force-failover EXEC command to force the secondary GRP to become the primary GRP.

Syntax Description

This command has no keywords or arguments.

Default

None

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.2 GS.

The router is interrupted while the processing services are enabled on the newly established primary GRP.

The secondary, as part of the process of taking over as the new primary, resets the old primary.

The following list suggests a few situtations where you might use the redundancy force-failover command:

• Prior to removing a primary GRP for maintenance. You may want to force the secondary to take over operation as the primary GRP.
  
  
• After loading a new software image on the secondary. You can force the new software to run, leaving a prior version of software on the old primary as backup.
  
  
• When remotely testing failover operation on a system. You can force a failover by using the redundancy force-failover command, rather than physically pulling the primary GRP out of the router.
  
  

Example

The following example forces the secondary GRP to become the primary GRP:

redundancy force-failover 
Proceed with failover? [confirm]n 
 

Pressing the enter key or a y accepts the action. Press n to disallow the action.

Related Commands

redundancy

redundancy prefer

Use the redundancy prefer EXEC command to define which card slot in a Cisco 12000 will contain the preferred primary GRP.

Syntax Description

Default

None

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.2 GS.

Use this command when you wish to override the arbitration scheme for determining which slot contains the primary GRP, or to explicitly define which slot contains the primary GRP.

Use this command to define a preference for the slot that contains the primary GRP. The arbitration scheme considers this preference, however, defining a preference does not guarantee that preference will be observed. Under normal circumstances, a GRP in the preferred slot will become the primary. The arbitration scheme may overide that preference should the preference conflict with other arbitration data. For example, if the GRP in the preferred slot is new to the chassis and likely to have an inappropriate startup-config, the other GRP will instead become the primary.

If no GRP is installed in the preferred slot, the arbitration scheme determines which GRP will be primary.

When you specify redundancy prefer none, the backplane NVRAM is initialized and existing values are stored.

Example

The following example defines card slot 8 as containing the primary GRP:

redundancy prefer slot 8 
 

Related Commands

redundancy

show boot

Use the show boot EXEC command to display GRP boot information.

Syntax Description

This command has no keywords or arguments.

Default

None

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.0.

Example

The following example displays boot information:

show boot
 
BOOT variable = slot0:gsr-p-mz,1;
CONFIG_FILE variable = nvram:
Current CONFIG_FILE variable = nvram:
Configuration register is 0x2
CHASSIS_SN variable = 66300963
CONFGEN variable = 419
 
Secondary is in slot 1
Secondary BOOT variable = slot0:gsr-p-mz,1;
Secondary CONFIG_FILE variable = nvram:
Secondary configuration register is 0x2
Secondary CHASSIS_SN variable = 66300963
Secondary CONFGEN variable = 419
 
 

Table 3 describes selected fields from the show boot command output.

Related Commands

hw-module config-register

redundancy prefer

show redundancy

Use the show redundancy EXEC command to display redundancy status information.

Syntax Description

Default

None

Command Mode

Privileged EXEC

Usage Guidelines

This command first appeared in Cisco IOS Release 11.2 GS.

When used with no keywords, this command displays a basic summary of GRP redundancy status. The all keyword displays all available information. Use the arbitration, secondary, or trace keywords to display selected subsets of GRP redundancy status.

You cannot combine keywords.

Examples

The following example displays basic GRP redundancy information from the Cisco 12000:

show redundancy
 
Primary   GRP in slot 2:
Secondary GRP in slot 1:
Preferred GRP:  none
Auto synch: startup-config
 

The following example displays arbitration GRP redundancy information in the Cisco 12000:

show redundancy arbitration 
 
Primary   GRP in slot 2:substate = p_redundant
Secondary GRP in slot 1:
Choice of primary due to failover initiated by primary in slot 1
Reason for failover:crash
Preferred GRP: none
 Chassis holds:  chassis s/n 66300963   config stamp 496
 Local GRP holds:chassis s/n 66300963   config stamp 496
Information from last arbitration period:
GRP Slot  1:   chassis s/n 66300963   config stamp 495
  IOS 11.2 redundancy v3  date 1998-10-14
  Mem size 128M GRP s/n CAB0147001B
GRP Slot  2:   chassis s/n 66300963   config stamp 495
  IOS 11.2 redundancy v3  date 1998-10-14
  Mem size 128M GRP s/n 04496038
known:          1 2 
allowed:        0 1 2 3 4 5 6 7 8 9 10 11 
preferred:      
compatible       1 2 
chassis_match:  1 2 
cfg_stamp_match:1 2 
latest_cfg:     
latest_ios:     1 2 
largest_mem:    1 2
 
 

The following example displays basic secondary GRP redundancy information from the Cisco 12000:

show redundancy secondary
 
Version information for secondary in slot 1:
Cisco Internetwork Operating System Software 
IOS (tm) GS Software (GSR-P-M), Experimental Version 11.2(19980829:002140) [ghall-bfr_112 2063]
Copyright (c) 1986-1998 by cisco Systems, Inc.
Compiled Wed 14-Oct-98 02:30 by ghall
 

The following example displays all GRP redundancy information from the Cisco 12000:

show redundancy all 
 
Primary   GRP in slot 8: substate = p_redundant
Secondary GRP in slot 1:
Choice of primary due to arbitration judgement of this GRP
 no other GRP
Preferred GRP:  9
Allowed   GRPs: 0 1 2 3 4 5 6 7 8 9 10 11
 Chassis holds:   chassis s/n 66300963   config stamp 419
 Local GRP holds: chassis s/n 66300963   config stamp 419
Information from last arbitration period:
GRP Slot  1:    chassis s/n 66300963   config stamp 418
  IOS arb ver 2  date 1998-10-01
  Mem size 128M GRP s/n CAB0147001B
GRP Slot  8:    chassis s/n 66300963   config stamp 418
  IOS 11.2 redundancy v3 date 1998-10-01
  Mem size 32M GRP s/n 04496038
known:           1 8
preferred:       9
compatible       1 8
chassis_match:   1 8
cfg_stamp_match: 1 8
latest_cfg:
latest_ios:      1 8
largest_mem:     1
NOTICE Unequal GRP memory sizes: 32M in slot 8, 128M in slot 1
Auto synch: startup-config 
 
Version information for secondary in slot 1:
Cisco Internetwork Operating System Software 
IOS (tm) GS Software (GSR-P-M), Experimental Version 11.2(19980829:002140) [ghall-bfr_112 2063]
Copyright (c) 1986-1998 by cisco Systems, Inc.
Compiled Wed 14-Oct-98 02:30 by ghall
 
 
State Machine Latest Events:
 -- (Current Time is 40287.000)
|     Timestamp |  State      Substate     Event                   Count
|     40274.260 |  primary    p_redundant  MSG_SECONDARY            20
|     40274.632 |  primary    p_redundant  TICK_COUNTDOWN           19
|     40274.760 |  primary    p_redundant  MSG_SECONDARY            20
State Machine Significant Events:
 -- (Current Time is 40324.856)
|     Timestamp |  State      Substate     Event                   Count
|         7.440 |  arb        a_alone      TICK_EXPIRY              0 ->
|               |  primary    p_judge
|         7.552 |  primary    p_judge      DECIDED_STANDALONE       0 ->
|               |  primary    p_standalone
|        17.136 |  primary    p_standalon  MGMT_DEBUG_CHANGE        0
|       347.804 |  primary    p_standalon  MSG_BETTER_BID           0
|       347.808 |  primary    p_standalon  MSG_BETTER_BID           0
|       348.928 |  primary    p_standalon  DECIDED_PRIMARY          20 ->
|               |  primary    p_redundant
|     38329.840 |  primary    p_redundant  DECIDED_PRIMARY          20
|     39531.056 |  primary    p_redundant  operator reload          4 ->
 
 

Table 4 describes selected fields from the show redundancy command output. Not all fields are described.

Related Commands

redundancy

redundancy prefer

Debug Commands

This section describes debug commands and test commands useful for troubleshooting the GRP redundancy feature.

• debug gsr redundancy
  
  

debug gsr redundancy

Use the debug gsr redundancy debug command to display information about the status of redundancy operations. The no form of this command disables debugging output.

Usage Guidelines

Use this command to display continuous output of the various state changes and messages that pass between the primary GRP and secondary GRP.

Sample Display

The following display shows sample debug gsr redundancy output.

router# debug gsr redundancy
*Feb 25 12:55:30.998:redundancy:send msg_primary
*Feb 25 12:55:30.998:redundancy:primary p_redundant, TICK_COUNTDOWN:
*Feb 25 12:55:30.998:redundancy:enq MSG_SECONDARY
*Feb 25 12:55:30.998:redundancy:primary p_redundant, MSG_SECONDARY:
*Feb 25 12:55:31.498:redundancy:enq TICK_COUNTDOWN
 

Table 5 shows describes the fields and messages shown in the sample debug gsr redundancy output. Not all fields or values are described.