Hardware Redundancy

This section focuses on the Catalyst 6500 switches' hardware redundancy capabilities. These features include redundant power supplies, a hot-swappable fan, hot-swappable modules, redundant Supervisor Engines, and redundant Route Processors. Please note that the Catalyst 4500s, 3550s, and 2950s support some of these features, but not necessarily all of them.

Power Supplies

Some of the first things considered in redundancy are your power source and power supplies. Without an Uninterruptible Power Supply (UPS) system, a loss of power, even with redundant power supplies, is going to do no good. Likewise, if you have redundant power supplies, you want to ensure that they are connected to different power circuits. If you connect both power supplies to the same circuit and that circuit fails, your switch also fails. In addition, a fluctuation in a power source can affect the lifetime of a power supply or even destroy it.

Most of Cisco's Catalyst switches support either internal redundant power supplies, or have the option of connecting a redundant external power supply to the switch. On Catalyst 6500 switches, the power supplies can operate in two modes: combined and redundant.

In combined mode, the power is generated from both power supplies and supplied to the switch. This mode is necessary if a single power supply doesn't have sufficient power to supply to all the cards in the switch's chassis. In this mode, if one of the two power supplies fails and the remaining power supply doesn't have enough power to power up the cards in the chassis, the switch shuts down enough modules so that it can remain up.

In redundant mode, the primary power supply supplies power to the switch while the other is in standby mode. If the primary power supply fails, the standby power supply supplies power to the chassis. In this mode, no power sharing occurs between the two power supplies.

To configure redundant power supplies on a 6500 switch, use the following command:

 Switch(config)# power redundancy-mode combined|redundant 

If you want to power-down a module in the chassis of the switch, use the following command:

 Switch(config)# no power enable module slot_# 

Enter the slot number of the card that you want to power-down. If you just want to power-cycle a card without rebooting the switch, use the following command:

 Switch(config)# power cycle module slot_# 

This command turns off the specified card for 5 seconds and then turns it back on.

To display the status of the power supplies, use the show power command, like this:

 Router# show power system power redundancy mode = redundant system power total = 27.460A system power used = 13.990A system power available = 13.470A FRU-type      #  current  admin state  oper power-supply  1  27.460A  on           on module        1  3.300A   on           on module        5  2.800A   on           on module        6  1.900A   on           on 

Supervisor Engines

The Supervisor Engines (SEs) support two types of redundancy: redundancy for the SEs themselves and redundancy for the feature cards installed on the SEs. The Supervisor Engine is the brains of the switch and contains the IOS software. SEs are installed in slots 1 and 2 in the 6500 chassis. By default, when the switch boots up, the first slot becomes the primary SE and the second slot becomes the secondary SE. The secondary SE is in standby mode and doesn't do anything except monitor the primary SE. The one exception to this is that the Gigabit Ethernet uplink interfaces on the standby SE are active and they can process traffic. If the primary SE fails, the secondary SE initiates a switchover within seconds.

When setting up redundant SEs, the SEs must go in slots 1 and 2. One SE is active and the other is in standby mode. The uplink interfaces of the standby SE can be used even though the SE is in a standby state.

RPR

Starting with IOS 12.1(13)E and later, the Catalyst 6500 supports SE redundancy with both Route Processor Redundancy and Route Processor Redundancy Plus (RPR+). These two features allow hardware redundancy for the Multilayer Switch Feature Card (MSFC) and Policy Feature Card (PFC or PFC2). This essentially provides Layer 3 redundancy for the Catalyst 6500.

RPR provides a Supervisor Engine redundancy for route processing (routing). One SE is primary and the other is secondary. When the switch boots, the RPR that boots up first (slot 1 or slot 2), becomes the primary SE. The MSFC and PFC/PFC2 are used on the primary while these cards are in a standby mode on the secondary SE. When the primary MSFC/PFC fails, it can take between 2 4 minutes for the secondary SE's MSFC/PFC to take over. The reason for the slow switchover is that when the secondary SE boots up, it does not initialize its MSFC/PFC cards.

RPR Features

RPR supports automatic startup of both SEs and has the primary SE automatically synchronize the bootvar files with the secondary SE. (The bootvar files are used to boot up and configure the SEs.) The two SEs use hardware signals to detect each other and to determine who will be playing the primary and secondary roles. Every 60 seconds, the primary SE synchronizes its clock with the secondary SE. When the MSFC and PFC fail on the primary SE and the secondary SE promotes itself to a primary role, the former primary SE becomes the secondary. In this role, even if its MSFC/PFC have failed, it can still provide SE redundancy. Another nice feature of RPR is that it supports fast software upgrades. Upgrading the primary unit automatically causes the secondary to by synchronized with the same information. This is also true of configuration changes: making a configuration change on the primary is automatically copied to the secondary.

RPR Events

Any of the following events causes RPR to perform a switchover:

• A manual switchover is initiated from the CLI.

• Either the MSFC or PFC fails on the primary SE.

• There is a clock synchronization failure between the primary and secondary SEs.

Remember the three items that can cause RPR to perform a switchover.

When a switchover occurs, the secondary SE (now the primary) recycles power on all switching modules (except itself). As this is occurring, the MSFC card, with its Layer 2 and Layer 3 protocol configurations, is activated. All ACLs are then reprogrammed by the now-primary SE to be processed in hardware by the MSFC/PFC.

RPR+ Overview

The main difference between RPR and RPR+ is that the secondary SE is fully initialized and configured the MSFC and PFC on the secondary are operational. When the primary fails, the secondary almost immediately handles these functions. It takes only between 30 60 seconds for this switchover to occur.

It's important to point out that with RPR+, the secondary SE's MSFC and PFC are operational. When you make configuration changes on the primary SE, they're automatically synchronized to the secondary SE. This includes both running and startup configurations. Please note that during the bootup of the SEs, the primary SE copies both of these configurations to the secondary. After bootup, any configuration changes done on the primary are copied to the secondary only the change itself is copied, which reduces overhead processing on the SEs.

Actually, you can make configuration changes only on the primary the secondary only keeps tabs on the primary and accepts and processes synchronization information. Also, card state information is synchronized between the primary and secondary SEs, including MSFC and PFC information.

Here is a list of advantages that RPR+ has over RPR:

• Faster switchover time: 30 60 seconds instead of 2 4 minutes.

• The promoted secondary SE does not reset its modules.

• You can hot-swap SEs without causing problems. Cisco calls this online insertion and removal (OIR). You can easily add or remove SEs without affecting the RPR+ process. When hot-swapping, the same switchover time period applies.

Remember the advantages that RPR+ has over RPR as listed in the bullet points.

It's important to point out that during an SE switchover or an RPR or RPR+ switchover, there will be some disruption. Some traffic could be dropped and FIB, adjacency, and CEF tables must be rebuilt.

RPR+ Guidelines and Restrictions

Both SEs must be in slots 1 and 2 of the chassis. Each SE has its own components, including console ports and flash memory. When making a console connection to the switch, don't use a Y cable to connect to both console ports use separate cables. Both SEs must have the same version of the IOS installed. If not, when the two SEs boot up, the secondary SE operates in RPR mode. Also, the configuration register (controls the bootup process of the SE) must be set to autoboot failure to do this will disable RPR+. The network boot option is not supported if you want to use RPR+.

There are a few restrictions when configuring an SE using RPR+. First, you must wait until after the initial synchronization takes place when the two SEs have just booted up. If you try to make a configuration change during this time period, you'll get the following message:

 Config mode locked out till standby initializes. 

Second, you cannot use the VLAN Database Privilege EXEC mode commands to configure your VLANs you must do it from Configuration mode. Third, SNMP changes made on the primary are not automatically synchronized to the secondary SE. You must execute the copy running-config startup-config command on the primary SE.

While using RPR+, only the primary SE is processing traffic while the secondary is in a standby state. The exception to this is the Gigabit uplink ports, which are in an active state. There will be a disruption in traffic during a switchover. When a failure occurs on the primary SE's MSFC/PFC, the primary first performs a core dump. When the core dump is completed, the secondary SE can start processing.

It can take up to 15 minutes for a core dump to complete! Therefore, if you're concerned about convergence, you might want to disable core dumps on your switch. The disadvantage of this is that if there is a problem, you won't have any detailed information to send to Cisco.

If you're entering a configuration command on the primary when a switchover occurs, the configuration change is lost. During a switchover, the FIB and routing tables are cleared and must be rebuilt by the newly promoted SE. The exceptions to this are any static routes that have been configured. Basically, any dynamically learned information is lost, but statically configured information is maintained.

RPR+ Configuration and Verification

Enabling RPR+ and verifying its operation is a simple process. To enable redundancy, use the following command:

 Switch(config)# redundancy 

This enables RPR. To enable RPR+, also execute the following command:

 Switch(config)# mode rpr-plus 

All configuration is done on the primary SE. Use the redundancy command followed by the mode rpr-plus command to enable RPR+.

When you've enabled either RPR or RPR+, use the show redundancy command to verify the operation of RPR/RPR+. Using the switchover parameter produces this output:

 Switch# show redundancy switchover Switchovers this system has experienced : 1 Uptime since this supervisor switched to active : 1 minute Total system uptime from reload : 2 hours, 47 minutes 

In this example, you can see that one switchover has taken place. Using the states parameter produces this output:

 Switch# 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 

In this example, this switch is the primary switch (ACTIVE state) and RPR has been configured and is operational.