Catalyst Supervisor Engine 32 PISA IOS Software Configuration Guide, 12.2ZY
Configuring RPR Supervisor Engine Redundancy
Downloads: This chapterpdf (PDF - 137.0KB) The complete bookPDF (PDF - 12.8MB) | Feedback

Configuring RPR Supervisor Engine Redundancy

Table Of Contents

Configuring RPR Supervisor Engine Redundancy

Understanding RPR

Supervisor Engine Redundancy Overview

RPR Operation

Supervisor Engine Configuration Synchronization

Supervisor Engine Redundancy Guidelines and Restrictions

Redundancy Guidelines and Restrictions

Hardware Configuration Guidelines and Restrictions

Configuration Mode Restrictions

Configuring Supervisor Engine Redundancy

Configuring Redundancy

Synchronizing the Supervisor Engine Configurations

Displaying the Redundancy States

Performing a Fast Software Upgrade

Copying Files to the Redundant Supervisor Engine


Configuring RPR Supervisor Engine Redundancy


This chapter describes how to configure supervisor engine redundancy using route processor redundancy (RPR).


NoteFor complete syntax and usage information for the commands used in this chapter, refer to the Catalyst Supervisor Engine 32 PISA Cisco IOS Command Reference, Release 12.2ZY, at this URL:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2ZY/command/reference/cmdref.html

For information about nonstop forwarding (NSF) with stateful switchover (SSO), see Chapter 5 "Configuring NSF with SSO Supervisor Engine Redundancy."


This chapter consists of these sections:

Understanding RPR

Supervisor Engine Redundancy Guidelines and Restrictions

Configuring Supervisor Engine Redundancy

Performing a Fast Software Upgrade

Copying Files to the Redundant Supervisor Engine

Understanding RPR

These sections describe supervisor engine redundancy using RPR:

Supervisor Engine Redundancy Overview

RPR Operation

Supervisor Engine Configuration Synchronization

Supervisor Engine Redundancy Overview


Note When a redundant supervisor engine is in standby mode, the two Gigabit Ethernet interfaces on the redundant supervisor engine are always active.


Catalyst 6500 series switches support fault resistance by allowing a redundant supervisor engine to take over if the primary supervisor engine fails. RPR supports a switchover time of 2 or more minutes.

The following events cause a switchover:

A hardware failure on the active supervisor engine

Clock synchronization failure between supervisor engines

A manual switchover

RPR Operation

RPR supports the following features:

Auto-startup and bootvar synchronization between active and redundant supervisor engines

Hardware signals that detect and decide the active or redundant status of supervisor engines

Clock synchronization every 60 seconds from the active to the redundant supervisor engine

A redundant supervisor engine that is booted but not all subsystems are up: if the active supervisor engine fails, the redundant supervisor engine become fully operational

An operational supervisor engine present in place of the failed unit becomes the redundant supervisor engine

Support for fast software upgrade (FSU) (See the "Performing a Fast Software Upgrade" section.)

When the switch is powered on, RPR runs between the two supervisor engines. The supervisor engine that boots first becomes the RPR active supervisor engine. The Multilayer Switch Feature Card and Policy Feature Card become fully operational. The PISA and PFC3B on the redundant supervisor engine come out of reset but are not operational.

In a switchover, the redundant supervisor engine become fully operational and the following occurs:

All switching modules power up again

Remaining subsystems on the PISA (including Layer 2 and Layer 3 protocols) are brought up

Access control lists (ACLs) are reprogrammed into supervisor engine hardware


Note In a switchover, there is a disruption of traffic because some address states are lost and then restored after they are dynamically redetermined.


Supervisor Engine Configuration Synchronization


Note Configuration changes made through SNMP are not synchronized to the redundant supervisor engine. After you configure the switch through SNMP, copy the running-config file to the startup-config file on the active supervisor engine to trigger synchronization of the startup-config file on the redundant supervisor engine.


During RPR mode operation, the startup-config files and the config-register configurations are synchronized by default between the two supervisor engines. In a switchover, the new active supervisor engine uses the current configuration.

Supervisor Engine Redundancy Guidelines and Restrictions

These sections describe supervisor engine redundancy guidelines and restrictions:

Redundancy Guidelines and Restrictions

Hardware Configuration Guidelines and Restrictions

Configuration Mode Restrictions

Redundancy Guidelines and Restrictions

These guidelines and restrictions apply to RPR redundancy modes:

When a redundant supervisor engine is in standby mode, the two Gigabit Ethernet interfaces on the redundant supervisor engine are always active.

Supervisor engine redundancy does not provide supervisor engine mirroring or supervisor engine load balancing. Only one supervisor engine is active.

Configuration changes made through SNMP are not synchronized to the redundant supervisor engine. After you configure the switch through SNMP, copy the running-config file to the startup-config file on the active supervisor engine to trigger synchronization of the startup-config file on the redundant supervisor engine .

Supervisor engine switchover takes place after the failed supervisor engine completes a core dump. A core dump can take up to 15 minutes. To get faster switchover time, disable core dump on the supervisor engines.

Hardware Configuration Guidelines and Restrictions

For redundant operation, the following guidelines and restrictions must be met:

Cisco IOS running on the supervisor engine and the PISA supports redundant configurations where the supervisor engines and PISA routers are identical. If they are not identical, one will boot first and become active and hold the other supervisor engine and PISA in a reset condition.

Each supervisor engine must have the resources to run the switch on its own, which means all supervisor engine resources are duplicated, including all Flash devices.

Make separate console connections to each supervisor engine. Do not connect a Y cable to the console ports.

Both supervisor engines must have the same system image (see the "Copying Files to the Redundant Supervisor Engine" section).


Note If a newly installed redundant supervisor engine has the Catalyst operating system installed, remove the active supervisor engine and boot the switch with only the redundant supervisor engine installed. Follow the procedures in the current release notes to convert the redundant supervisor engine from the Catalyst operating system.


The configuration register in the startup-config must be set to autoboot (see the "Modifying the Boot Field" section).


Note There is no support for booting from the network.


Configuration Mode Restrictions

The following configuration restrictions apply during the startup synchronization process:

You cannot perform configuration changes during the startup (bulk) synchronization. If you attempt to make configuration changes during this process, the following message is generated:

Config mode locked out till standby initializes
 
   

If configuration changes occur at the same time as a supervisor engine switchover, these configuration changes are lost.

Configuring Supervisor Engine Redundancy

These sections describe how to configure supervisor engine redundancy:

Configuring Redundancy

Synchronizing the Supervisor Engine Configurations

Displaying the Redundancy States

Configuring Redundancy

To configure redundancy, perform this task:

 
Command
Purpose

Step 1 

Router(config)# redundancy

Enters redundancy configuration mode.

Step 2 

Router(config-red)# mode rpr

Configures RPR mode. When this command is entered, the redundant supervisor engine is reloaded and begins to work in RPR mode.

Step 3 

Router# show running-config

Verifies that RPR mode is enabled.

Step 4 

Router# show redundancy states

Displays the operating redundancy mode.

This example shows how to configure the system for RPR and display the redundancy state:

Router> enable 
Router# configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# redundancy 
Router(config-red)# mode rpr 
Router(config-red)# end 
Router# show redundancy states 
       my state = 13 -ACTIVE
     peer state = 1  -DISABLED
           Mode = Simplex
           Unit = Primary
        Unit ID = 1
 
   
Redundancy Mode (Operational) = Route Processor Redundancy 
Redundancy Mode (Configured)  = Route Processor Redundancy 
     Split Mode = Disabled
   Manual Swact = Disabled  Reason: Simplex mode
 Communications = Down      Reason: Simplex mode
 
   
   client count = 11
 client_notification_TMR = 30000 milliseconds
          keep_alive TMR = 4000 milliseconds
        keep_alive count = 0
    keep_alive threshold = 7
           RF debug mask = 0x0
 
   
Router#

Synchronizing the Supervisor Engine Configurations

During normal operation, the startup-config and config-registers configuration are synchronized by default between the two supervisor engines. In a switchover, the new active supervisor engine uses the current configuration.


Note Do not change the default auto-sync configuration.


Displaying the Redundancy States

To display the redundancy states, perform this task:

Command
Purpose

Router# show redundancy states

Displays the redundancy states.


This example shows how to display the redundancy states:

Router# show redundancy states 
my state = 13 -ACTIVE
     peer state = 8  -STANDBY HOT
           Mode = Duplex
           Unit = Primary
        Unit ID = 1
 
   
Redundancy Mode (Operational) = Route Processor Redundancy Plus
Redundancy Mode (Configured)  = Route Processor Redundancy Plus
     Split Mode = Disabled
   Manual Swact = Enabled
 Communications = Up
 
   
   client count = 11
 client_notification_TMR = 30000 milliseconds
          keep_alive TMR = 9000 milliseconds
        keep_alive count = 0
    keep_alive threshold = 18
           RF debug mask = 0x0
 
   
Router#

Performing a Fast Software Upgrade

The fast software upgrade (FSU) procedure supported by RPR allows you to upgrade the Cisco IOS image on the supervisor engines without reloading the system.


Note If you are performing a first-time upgrade to RPR from EHSA, you must reload both supervisor engines. FSU from EHSA is not supported.


To perform an FSU, perform this task:

 
Command
Purpose

Step 1 

Router# copy source_device:source_filename {disk0 | disk1}:target_filename

Or:

Router# copy source_device:source_filename sup-bootflash:target_filename

Or:

Router# copy source_device:source_filename slavedisk0:target_filename

Or:

Router# copy source_device:source_filename slavesup-bootflash:target_filename

Copies the new Cisco IOS image to bootflash on both supervisor engines.

Step 2 

Router# config terminal

Router(config)# config-register 0x2102

Router(config)# boot system flash device:file_name

Configures the supervisor engines to boot the new image.

Step 3 

Router# copy running-config start-config

Saves the configuration.

Step 4 

Router# hw-module {module num} reset

Reloads the redundant supervisor engine and brings it back online (running the new version of the Cisco IOS software).

Note Before reloading the redundant supervisor engine, make sure you wait long enough to ensure that all configuration synchronization changes have completed.

Step 5 

Router# redundancy force-switchover

Conducts a manual switchover to the redundant supervisor engine. The redundant supervisor engine becomes the new active supervisor engine running the new Cisco IOS image. The modules are reloaded and the module software is downloaded from the new active supervisor engine.

The old active supervisor engine reboots with the new image and becomes the redundant supervisor engine.

Note To perform an EHSA to RPR FSU, use the reload command in Step 5.

This example shows how to perform an FSU:

Router# config terminal 
Router(config)# config-register 0x2102 
Router(config)# boot system flash disk0:image_name 
Router# copy running-config start-config 
Router# hw-module reset 
Router# redundancy force-switchover 
Router#

Copying Files to the Redundant Supervisor Engine

Use the following command to copy a file to the disk0: device on a redundant supervisor engine:

Router# copy source_device:source_filename slavedisk0:target_filename  

Use the following command to copy a file to the bootdisk: device on a redundant supervisor engine:

Router# copy source_device:source_filename slavesup-bootdisk:target_filename  

Use the following command to copy a file to the bootdisk: device on a redundant PISA:

Router# copy source_device:source_filename slavebootdisk:target_filename