Configuring RPR and RPR+ Supervisor Engine Redundancy

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

Note•For complete syntax and usage information for the commands used in this chapter, refer to the Cisco IOS Master Command List, Release 12.2SX at this URL:

http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html

•All releases support RPR and RPR+.

•With Release 12.2(18)SXE and later releases, RPR and RPR+ support IPv6 multicast traffic.

•Release 12.2(18)SXD and later releases support nonstop forwarding (NSF) with stateful switchover (SSO) on all supervisor engines (see Chapter 7 "Configuring NSF with SSO Supervisor Engine Redundancy").

This chapter consists of these sections:

•Understanding RPR and RPR+

•Supervisor Engine Redundancy Guidelines and Restrictions

•Configuring Supervisor Engine Redundancy

•Performing a Fast Software Upgrade

•Copying Files to an MSFC

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

Understanding RPR and RPR+

These sections describe supervisor engine redundancy using RPR and RPR+:

•Supervisor Engine Redundancy Overview

•RPR Operation

•RPR+ Operation

•Supervisor Engine Configuration Synchronization

Supervisor Engine Redundancy Overview

Catalyst 6500 series switches support fault resistance by allowing a redundant supervisor engine to take over if the primary supervisor engine fails. Catalyst 6500 series switches support these redundancy modes:

•RPR—Supports a switchover time of 2 or more minutes.

•Route processor redundancy plus (RPR+)—Supports a switchover time of 30 or more seconds.

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 MSFC and PFC 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 MSFC (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.

RPR+ Operation

When RPR+ mode is used, the redundant supervisor engine is fully initialized and configured, which shortens the switchover time. The active supervisor engine checks the image version of the redundant supervisor engine when the redundant supervisor engine comes online. If the image on the redundant supervisor engine does not match the image on the active supervisor engine, RPR redundancy mode is used.

With RPR+, the redundant supervisor engine is fully initialized and configured, which shortens the switchover time if the active supervisor engine fails or if a manual switchover is performed.

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

RPR+ enhances RPR by providing the following additional benefits:

•Reduced switchover time

Depending on the configuration, the switchover time is 30 or more seconds.

•Installed modules are not reloaded

Because both the startup configuration and the running configuration are continually synchronized from the active to the redundant supervisor engine, installed modules are not reloaded during a switchover.

•Online insertion and removal (OIR) of the redundant supervisor engine

RPR+ allows OIR of the redundant supervisor engine for maintenance. When the redundant supervisor engine is inserted, the active supervisor engine detects its presence and begins to transition the redundant supervisor engine to fully initialized state.

•Synchronization of OIR events

•Manual user-initiated switchover using the redundancy force-switchover command

Supervisor Engine Configuration Synchronization

These sections describe supervisor engine configuration synchronization:

•RPR Supervisor Engine Configuration Synchronization

•RPR+ 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 and with RPR+, reload the redundant supervisor engine and MSFC.

RPR Supervisor Engine Configuration Synchronization

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.

RPR+ Supervisor Engine Configuration Synchronization

With RPR+ mode, the following operations trigger configuration synchronization:

•When a redundant supervisor engine first comes online, the startup-config file is copied from the active supervisor engine to the redundant supervisor engine. This synchronization overwrites any existing startup configuration file on the redundant supervisor engine.

•When configuration changes occur during normal operation, redundancy performs an incremental synchronization from the active supervisor engine to the redundant supervisor engine. Redundancy synchronizes user-entered CLI commands incrementally line-by-line from the active supervisor engine to the redundant supervisor engine.

Even though the redundant supervisor engine is fully initialized, it only interacts with the active supervisor engine to receive incremental changes to the configuration files as they occur. You cannot enter CLI commands on the redundant supervisor engine.

Supervisor Engine Redundancy Guidelines and Restrictions

These sections describe supervisor engine redundancy guidelines and restrictions:

•Redundancy Guidelines and Restrictions

•RPR+ Guidelines and Restrictions

•Hardware Configuration Guidelines and Restrictions

•Configuration Mode Restrictions

Redundancy Guidelines and Restrictions

These guidelines and restrictions apply to RPR and RPR+ redundancy modes:

•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 and with RPR+, reload the redundant supervisor engine and MSFC.

•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.

RPR+ Guidelines and Restrictions

These guidelines and restrictions apply to RPR+:

•Network services are disrupted until the redundant supervisor engine takes over and the switch recovers.

•The Forwarding Information Base (FIB) tables are cleared on a switchover. As a result, routed traffic is interrupted until route tables reconverge.

•Static IP routes are maintained across a switchover because they are configured from entries in the configuration file.

•Information about dynamic states maintained on the active supervisor engine is not synchronized to the redundant supervisor engine and is lost on switchover.

These are examples of dynamic state information that is lost at switchover:

–Frame Relay Switched Virtual Circuits (SVCs)

Note Frame Relay-switched DLCI information is maintained across a switchover because Frame Relay-switched DLCI configuration is in the configuration file.

–All terminated PPP sessions

–All ATM SVC information

–All terminated TCP and other connection-oriented Layer 3 and Layer 4 sessions

–BGP sessions

–All Automatic Protection System (APS) state information

•Both supervisor engines must run the same version of Cisco IOS software. If the supervisor engines are not running the same version of Cisco IOS software, the redundant supervisor engine comes online in RPR mode.

•Supervisor engine redundancy does not support nondefault VLAN data file names or locations. Do not enter the vtp file file_name command on a switch that has a redundant supervisor engine.

•Before installing a redundant supervisor engine, enter the no vtp file command to return to the default configuration.

•Supervisor engine redundancy does not support configuration entered in VLAN database mode. Use global configuration mode with RPR+ redundancy (see Chapter 14 "Configuring VLANs").

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 MSFC supports redundant configurations where the supervisor engines and MSFC routers are identical. If they are not identical, one will boot first and become active and hold the other supervisor engine and MSFC 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 an MSFC" 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.

With releases earlier than Release 12.2(17b)SXA, if these requirements are met, the switch functions in RPR+ mode by default.

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 | rpr-plus} 
 
       
 Configures RPR or RPR+. When this command is entered, the redundant supervisor engine is reloaded and begins to work in RPR or RPR+ mode. 
 		 
      
 
      
 
       
 Step 3  
 		 
       
Router# show running-config 
 
       
 Verifies that RPR or RPR+ 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-plus 

 
   
 
    
   
 
    
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 Plus

 
   
 
    
   
 
    
Redundancy Mode (Configured)  = Route Processor Redundancy Plus

 
   
 
    
   
 
    
     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 
        
 		 
        
        
 
         Copies the new Cisco IOS image to the  
         disk0:  
         device or the  
         disk1:  
         device on the active supervisor engine. 
        
 		 
      
 
      
 
         
        
        
 
         Or: 
        
 		 
         
      
 
      
 
         
        
        
 
         Router#  
         copy 
           
         source_device 
         : 
         source_filename 
           
         sup-bootflash: 
         target_filename 
        
 		 
        
        
 
         Copies the new Cisco IOS image to the  
         bootflash:  
         device 
           
         on the active supervisor engine. 
        
 		 
      
 
      
 
         
        
        
 
         Or: 
        
 		 
         
      
 
      
 
         
        
        
 
         Router#  
         copy 
           
         source_device 
         : 
         source_filename 
          { 
         slavedisk0 
          |  
         slavedisk1 
         } 
         : 
         target_filename 
        
 		 
        
        
 
         Copies the new Cisco IOS image to the  
         disk0:  
         device or the  
         disk1:  
         device on the redundant supervisor engine. 
        
 		 
      
 
      
 
         
        
        
 
         Or: 
        
 		 
         
      
 
      
 
         
        
        
 
         Router#  
         copy 
           
         source_device 
         : 
         source_filename 
           
         slavesup-bootflash: 
         target_filename 
        
 		 
        
        
 
         Copies the new Cisco IOS image to the  
         bootflash:  
         device on the redundant supervisor engine. 
        
 		 
      
 
      
 
       
 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 an MSFC 
 
    
   
 Use the following command to copy a file to the bootflash: device on an active MSFC: 
 
    
   
 
    
Router# copy source_device:source_filename bootflash:target_filename 

 
   
 
    
   
 
    
 
   
 
    
   
 Use the following command to copy a file to the bootflash: device on a redundant MSFC: 
 
    
   
 
    
Router# copy source_device:source_filename slavebootflash:target_filename 

 
   
 
   
 
     
   
 
   
 
    
   
 Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page: 
 
    
   
 http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html 
 
    
   
 Participate in the Technical Documentation Ideas forum