- Index
- Preface
- Product Overview
- Command-Line Interfaces
- Smart Port Macros
- Virtual Switching Systems (VSS)
- Enhanced Fast Software Ugrade (eFSU)
- NSF with SSO Supervisor Engine Redundancy
- RPR Supervisor Engine Redundancy
- Interface Configuration
- UniDirectional Link Detection (UDLD)
- Power Management and Environmental Monitoring
- EnergyWise
- Online Diagnostics
- Onboard Failure Logging
- Switch Fabric Functionality
- Cisco IP Phone Support
- Power over Ethernet
- Layer 2 LAN Ports
- Flex Links
- EtherChannels
- mLACP for Server Access
- IEEE 802.1ak MVRP and MRP
- VLAN Trunking Protocol (VTP)
- VLANs
- Private VLANs (PVLANs)
- Private Hosts
- IEEE 802.1Q Tunneling
- Layer 2 Protocol Tunneling
- STP and MST
- Optional STP Features
- Layer 3 Interface Configuration
- Unidirectional Ethernet (UDE) and unidirectional link routing (UDLR)
- Multiprotocol Label Switching (MPLS)
- L2VPN Advanced VPLS (A-VPLS)
- IP Unicast Layer 3 Switching
- IPv6 Multicast Layer 3 Switching
- MLD Snooping for IPv6 Multicast Traffic
- IPv4 Multicast Layer 3 Switching
- IGMP Snooping and MVR for IPv4 Multicast Traffic
- Configuring MVR for IPv4 Multicast Traffic
- IPv4 IGMP Filtering and Router Guard
- PIM Snooping
- IPv4 Multicast VPN Support
- PFC QoS
- AutoQoS
- MPLS QoS
- PFC QoS Statistics Data Export
- Network Security
- AutoSecure
- Cisco IOS ACL Support
- Cisco TrustSec (CTS)
- Port ACLs (PACLs) and VLAN ACLs (VACLs)
- Denial of Service Protection
- Control Plane Policing (CoPP)
- DHCP Snooping
- IP Source Guard
- Dynamic ARP Inspection
- Traffic Storm Control
- Unknown Unicast and Multicast Flood Control
- Network Admission Control (NAC)
- IEEE 802.1X Port-Based Authentication
- Web-Based Authentication
- Port Security
- NetFlow
- NetFlow Data Export (NDE)
- Call Home
- System Event Archive (SEA)
- Backplane Platform Monitoring
- SPAN, RSPAN, and ERSPAN
- SNMP IfIndex Persistence
- Top-N Reports
- Layer 2 Traceroute Utility
- Mini Protocol Analyzer
- Ethernet Services Line Cards
- Online Diagnostic Tests
- Acronyms
Configuring RPR Supervisor Engine Redundancy
This chapter describes how to configure supervisor engine redundancy using route processor redundancy (RPR).
Note•For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS Master Command List, at this URL:
http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html
•Cisco ME 6500 Series Ethernet switches do not support redundancy.
•In RPR redundancy mode, the ports on a Supervisor Engine 720-10GE in standby mode are disabled.
•RPR supports IPv6 multicast traffic.
•Release 12.2(33)SXH and later releases do not support Route Processor Redundancy Plus (RPR+).
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
This chapter consists of these sections:
•Supervisor Engine Redundancy Guidelines and Restrictions
•Configuring Supervisor Engine Redundancy
•Performing a Fast Software Upgrade
Understanding RPR
These sections describe RPR supervisor engine redundancy:
•Supervisor Engine Redundancy Overview
•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. 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 route processor (RP) 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 RP (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:
•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 SP and RP supports redundant configurations where the supervisor engines are identical. If they are not identical, one will boot first and become active and hold the other supervisor engine 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.
•Except during an FSU, both supervisor engines must have the same system image (see the "Copying Files to the RP" 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 must be set to 0x2102 (config-register 0x2102).
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:
•Synchronizing the Supervisor Engine Configurations
•Displaying the Redundancy States
Configuring Redundancy
To configure redundancy, perform this task:
This example shows how to configure the system for RPR:
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
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:
|
|
---|---|
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
Redundancy Mode (Configured) = Route Processor Redundancy
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
In this example, the system cannot enter the redundancy state because the second supervisor engine is disabled or missing:
Router# show redundancy states
my state = 13 -ACTIVE
peer state = 1 -DISABLED
Mode = Simplex
Unit = Primary
Unit ID = 1
Redundancy Mode (Operational) = rpr
Redundancy Mode (Configured) = rpr
Redundancy State = Non Redundant
Maintenance Mode = Disabled
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
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.
•FSU from an IOS image to a modular IOS image is not supported. FSU from a modular IOS image to an IOS image is not supported. (CSCsb07831)
To perform an FSU, perform this task:
|
|
|
---|---|---|
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 module redundant_spervisor_reset
Router# redundancy force-switchover
Copying Files to the RP
Use the following command to copy a file to the bootflash: device on an active RP:
Router# copy source_device:source_filename bootflash:target_filename
Use the following command to copy a file to the bootflash: device on a redundant RP:
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