Catalyst 6500 Series Software Configuration Guide, 8.7 - Configuring Redundancy [Cisco Catalyst 6500 Series Switches]

Table Of Contents

Configuring Redundancy

Understanding How Supervisor Engine Redundancy Works

Configuring Redundant Supervisor Engines on the Switch

Synchronization Process Initiation

Redundant Supervisor Engine Configuration Guidelines and Restrictions

Verifying the Standby Supervisor Engine Status

Forcing a Switchover to the Standby Supervisor Engine

High Availability

High-Availability Overview

High-Availability Supported Features

High-Availability Configuration Guidelines

Versioning Overview

CLI Commands

Loading a Different but Compatible Image on the Standby Supervisor Engine

Configuring Supervisor Engine Redundancy Using NSF with SSO

Supervisor Engine Synchronization Examples

Synchronizing the Run-Time Image with the Bootstring

Synchronizing the Boot Images on the Active and Standby Supervisor Engines

MSFC Redundancy

Dual MSFC Redundancy

Hardware and Software Requirements

Layer 3 Redundancy for a Single Chassis

Routing Protocol Peering

Access Control List Configuration

Dual MSFC Operational Model for Redundancy and Load Sharing

Understanding Failure Scenarios

Configuring Redundancy with HSRP

Configuration Examples

MSFC Configuration Synchronization Overview

Enabling or Disabling Configuration Synchronization

High-Availability Redundancy Configuration Examples

Single Router Mode Redundancy

Hardware and Software Requirements

SRM Redundancy Configuration Guidelines

Configuring Single Router Mode Redundancy on Supervisor Engine 720

Configuring Single Router Mode Redundancy on Supervisor Engine 1 or Supervisor Engine 2

Specifying the Transition Time on the Newly Designated Active Router

Upgrading Images with Single Router Mode Enabled

Getting Out of Single Router Mode

Manual-Mode MSFC Redundancy

Hardware and Software Requirements

Manual-Mode MSFC Redundancy Guidelines

Accessing the Standby MSFC

Manually Booting the MSFC

Setting the MSFC Configuration Register

MSFC Recovery Procedures

Configuring Redundancy

This chapter describes how to configure the redundant supervisor engines and how to configure redundancy on the Multilayer Switch Feature Cards (MSFCs) on the Catalyst 6500 series switches.

This chapter consists of these sections:

•Understanding How Supervisor Engine Redundancy Works

•Configuring Redundant Supervisor Engines on the Switch

•MSFC Redundancy

Note For information on configuring MSFC redundancy using Cisco nonstop forwarding (NSF) with stateful switchover (SSO), see Chapter 24, "Configuring NSF with SSO MSFC Redundancy."

Caution The dual MSFCs in a single chassis are designed to be used in redundant mode only and must have identical configurations. See the "MSFC Redundancy" section for detailed information.

We do not support configurations where the MSFCs are not configured identically.

Note Except where specifically differentiated, the information and procedures in this chapter apply to Supervisor Engine 32 with PFC3B/PFC3BXL, Supervisor Engine 720 with PFC3A/PFC3B/PFC3BXL, Supervisor Engine 2 with PFC2, and Supervisor Engine 1 with PFC.

Note The term MSFC is used throughout this publication to refer to MSFC, MSFC2, MSFC2A, and MSFC3 except where specifically differentiated.

For more information about installing the redundant Catalyst 6500 series supervisor engines, refer to the Catalyst 6500 Series Switch Module Installation Guide. For syntax and usage information for the commands that are used in this chapter, refer to the Catalyst 6500 Series Switch Command Reference publication.

Understanding How Supervisor Engine Redundancy Works

Note The redundant supervisor engines must be of the same type with the same model feature card. The WS-X6K-SUP1-2GE and the WS-X6K-SUP1A-2GE (both without PFCs) are compatible for redundancy. For supervisor engines with PFCs, the PFCs must be identical for redundancy (two PFCs, two PFC2s, two PFC3As, two PFC3Bs, or two PFC3BXLs).

When you install two supervisor engines, the first supervisor engine to come online becomes the active module; the second supervisor engine goes into standby mode. All administrative and network management functions, such as SNMP, command-line interface (CLI) console, Telnet, Spanning Tree Protocol (STP), Cisco Discovery Protocol (CDP), and VLAN Trunking Protocol (VTP) are processed on the active supervisor engine.

On the standby supervisor engine, the console port is inactive, the module status shows as "standby," and the status for the uplink ports is shown normally.

For Supervisor Engine 1 and Supervisor Engine 2, you must install the redundant supervisor engines in slots 1 and 2 of the chassis. The Supervisor Engine 720 and Supervisor Engine 32 slot requirements are as follows: With a 3-slot chassis, install Supervisor Engine 720 and Supervisor Engine 32 in either slot 1 or 2. With a 6-slot or a 9-slot chassis, install Supervisor Engine 720 and Supervisor Engine 32 in either slot 5 or 6. With a 13-slot chassis, install Supervisor Engine 720 and Supervisor Engine 32 in either slot 7 or 8. You must install redundant supervisor engines in both slots.

The redundant supervisor engines are hot swappable. The system continues to operate with the same configuration after switching over to the redundant supervisor engine.

Note To allow you to control the booting of each supervisor engine separately, the configuration registers are not synchronized between the supervisor engines.

Note The switchover time from the active supervisor engine to the standby supervisor engine does not include the spanning-tree convergence time.

At power-up, both supervisor engines run initial module-level diagnostics. Assuming that both supervisor engines pass this level of diagnostics, the two supervisor engines communicate over the backplane, allowing them to cooperate during the switching-bus diagnostics. The supervisor engine in slot 1 becomes active, and the supervisor engine in slot 2 enters standby mode. If the software versions of the two supervisor engines are different, or if the NVRAM configuration of the two supervisor engines is different, the active supervisor engine automatically downloads its software image and configuration to the standby supervisor engine.

Note The terms slot 1 and slot 2 refer to the redundant supervisor engines. As noted earlier, Supervisor Engine 720 and Supervisor Engine 32 have different slot requirements.

If the background diagnostics on the active supervisor engine detect a major problem or an exception occurs, the active supervisor engine resets. The standby supervisor engine detects that the active supervisor engine is no longer running and becomes active. The standby supervisor engine can detect if the active supervisor engine is not functioning and can force a reset, if necessary. If the reset supervisor engine comes online again, it enters standby mode.

If you hot insert a second supervisor engine, the second module communicates with the active supervisor engine after completing its initial module-level diagnostics. Because the active supervisor engine is already switching traffic on the backplane, no switching-bus diagnostics are run for the second supervisor engine because running diagnostics can disrupt the normal traffic. The second supervisor engine immediately enters standby mode. The active supervisor engine downloads the software image and configuration to the standby supervisor engine, if necessary.

The supervisor engines use two flash images: the boot image and the run-time image. The boot image filename, which is specified in the BOOT environment variable, is stored in NVRAM. The run-time image is the boot image that the ROM monitor uses to boot the supervisor engine. After the system boots, the run-time image resides in dynamic RAM (DRAM).

When you power up or reset a switch with the redundant supervisor engines, synchronization occurs to ensure that the run-time and boot images on the standby supervisor engine are the same as the images on the active supervisor engine.

The supervisor engines can have different run-time and boot images. If the boot image and the run-time image are the same, and you change the BOOT environment variable or overwrite or destroy the current boot image on the flash device that was used to boot the system, the run-time and boot images will differ. Whenever you reconfigure the boot image, the active supervisor engine synchronizes its current boot image with the standby supervisor engine.

The boot image is read directly into the flash file system. You can perform operations (such as copy, delete, undelete, and so on) on the files that are stored on flash memory devices, and you can store the boot image of the active supervisor engine in the standby supervisor engine bootflash. For more information about using the flash file system, see Chapter 26, "Working With the Flash File System."

Supervisor Engine 1 and Supervisor Engine 2 have a Flash PC card (PCMCIA) slot (slot0) in addition to the onboard flash memory; this slot can hold a Flash PC card that can store additional boot images. The keywords for the slot are slot0: for linear flash devices and disk0: for ATA flash devices.

Note The term Flash PC card is used throughout this publication in place of the term PCMCIA card.

Supervisor Engine 720 has two CompactFlash Type II slots. The CompactFlash Type II slots support the CompactFlash Type II Flash PC cards. The keywords for the slots on the active Supervisor Engine 720 are disk0: and disk1:. The keywords for the slots on a redundant Supervisor Engine 720 are slavedisk0: and slavedisk1:. Supervisor Engine 32 has one CompactFlash Type II slot. The CompactFlash Type II slot supports the CompactFlash Type II Flash PC cards. The keyword for the slot on the active Supervisor Engine 32 is disk0:. The keyword for the slot on a redundant Supervisor Engine 32 is slavedisk0:.

Because you can store multiple boot images, you must specify the name of the boot file image and the location of the image file in the flash file system to boot and synchronize properly. For information about how to specify the name and location of the boot image, see Chapter 25, "Modifying the Switch Boot Configuration."

In the synchronization process, the active supervisor engine checks the standby supervisor engine run-time image to make sure that it matches its own run-time image. The active supervisor engine checks three conditions:

•If it needs to copy its boot image to the standby supervisor engine

•If the standby supervisor engine bootstring needs to be changed

•If the standby supervisor engine needs to be reset

The following section describes the conditions that can initiate the flash synchronization. For examples of how the system synchronizes the supervisor engine flash images with various configurations, see the "Supervisor Engine Synchronization Examples" section.

Configuring Redundant Supervisor Engines on the Switch

These sections describe how to configure the redundant supervisor engines:

•Synchronization Process Initiation

•Redundant Supervisor Engine Configuration Guidelines and Restrictions

•Verifying the Standby Supervisor Engine Status

•Forcing a Switchover to the Standby Supervisor Engine

•High Availability

•Configuring Supervisor Engine Redundancy Using NSF with SSO

Synchronization Process Initiation

These conditions initiate the synchronization of the run-time and boot images on the active and standby supervisor engines:

•Time stamp mismatch between the run-time images on the active and standby supervisor engines—The active supervisor engine synchronizes its run-time image with the standby supervisor engine if the time stamps of their respective run-time images differ when the system is booted or reset.

•Time stamp mismatch between the boot images on the active and standby supervisor engines—The active supervisor engine synchronizes its boot image with the standby supervisor engine if the time stamps of their respective boot images differ when the system is booted or reset, or if you change the BOOT environment variable.

•Current boot image overwritten—If you overwrite the current boot image that is stored on one of the flash devices, the file system management module detects this event and initiates synchronization. The active supervisor engine copies its new boot image to the standby supervisor engine.

•BOOT environment variables changed—If you change the BOOT environment variables to specify a different default boot image, the active supervisor engine initiates the boot-image synchronization. The NVRAM configuration module detects this event and calls the flash synchronization function with the next probable boot filename by looking at the boot configuration parameter.

•Flash PC cards with the same boot-image filename—If you change the flash device on either the active or standby supervisor engine and the new flash device contains a boot image that has the same name (but a different time stamp) as the boot image from the previous flash device, the flash file management module initiates synchronization.

•Current run-time image deleted—If you delete the current run-time image from the flash device, the flash file management module prompts you to verify that you want to delete the current run-time image. If you confirm the deletion, the flash file management module initiates flash synchronization and informs the NVRAM configuration module of the change. The NVRAM configuration module examines the BOOT environment variable to determine the next probable image to boot and calls the flash synchronization function using the new image name.

Redundant Supervisor Engine Configuration Guidelines and Restrictions

These conditions and events can cause the synchronization of the images between the redundant supervisor engines to fail or to produce unexpected results:

•Downloading a new image to the active supervisor engine

When you download a new image to the active supervisor engine, it is copied to the file system (in bootflash or on a Flash PC card). Because you may or may not have configured this image as the boot image, the newly downloaded image is not copied to the standby supervisor engine automatically.

To initiate the synchronization function between the active and standby supervisor engines, you must configure this newly downloaded image as the boot image on the active supervisor engine. Synchronization occurs when you change the boot variable. To run the new image, you must reset the system.

•Unable to find the current run-time image

If the active supervisor engine is unable to find the current run-time image on any of the flash devices, it signals an error condition. If you insert or reset the standby supervisor engine, flash synchronization does not occur. In addition, the STATUS LED on the standby supervisor engine turns red and the system generates a syslog error message.

•Active supervisor engine in slot 2

When the active supervisor engine is in slot 2, the standby supervisor engine is in slot 1. If you change the configuration to specify a new boot image and then reset the system, the supervisor engine in slot 1 becomes the active supervisor engine and loads its default boot image, canceling the configuration changes that you have just made. To avoid this problem, the switch prompts you for flash synchronization as soon as you change the boot file configuration.

Verifying the Standby Supervisor Engine Status

You can verify the status of the standby supervisor engine by using the CLI commands described in this section.

Note The show module command output provides information about the installed daughter cards. The show test command provides information about the onboard application-specific integrated circuits (ASICs).

To verify the status of the standby supervisor engine, perform one or more of these tasks:

Task

Command

Show the status of the standby supervisor engine.

show module [mod]

Show the state of the standby supervisor engine uplink ports.

show port [mod[/port]]

Show diagnostic test results for the standby supervisor engine.

show test [mod]

This example shows how to check the status of the standby supervisor engine by entering the show module and show test commands:
Console> (enable) show module 2
Mod Slot Ports Module-Type               Model               Status
--- ---- ----- ------------------------- ------------------- --------
2   2    2     1000BaseX Supervisor      WS-X6K-SUP1-2GE     ok
Mod Module-Name         Serial-Num
--- ------------------- -----------
2                       SAD02330231
Mod MAC-Address(es)                        Hw     Fw         Sw
--- -------------------------------------- ------ ---------- -----------------
2   00-e0-14-0e-f5-6c to 00-e0-14-0e-f5-6d 0.404  4.2(2038)  4.2(0.24)VAI50
    00-e0-14-0e-f5-6e to 00-e0-14-0e-f5-6f
    00-10-7b-bb-2b-00 to 00-10-7b-bb-2e-ff
Mod Sub-Type            Sub-Model           Sub-Serial  Sub-Hw
--- ------------------- ------------------- ----------- ------
2   L2 Switching Engine WS-F6020            SAD02350211 0.101
Console> (enable)
Console> (enable) show test 2
Module 2 : 2-port 1000BaseX Supervisor
Network Management Processor (NMP) Status: (. = Pass, F = Fail, U = Unknown)
  ROM:  .   Flash-EEPROM: .   Ser-EEPROM: .   NVRAM: .   EOBC Comm: .
Line Card Status for Module 1 : PASS
Port Status :
  Ports 1  2
  -----------
        .  .
Line Card Diag Status for Module 2  (. = Pass, F = Fail, N = N/A)
 Module 2
  Cafe II Status :
        NewLearnTest:             .
        IndexLearnTest:           .
        DontForwardTest:          .
        DontLearnTest:            .
        ConditionalLearnTest:     .
        BadBpduTest:              .
        TrapTest:                 .
 Loopback Status [Reported by Module 2] :
  Ports 1  2
  -----------
        .  .
Console> (enable) 
Forcing a Switchover to the Standby Supervisor Engine

You can force a switchover to the standby supervisor engine by resetting the active supervisor engine.

Note Resetting the active supervisor engine disconnects any open Telnet sessions.

To force a switchover to the standby supervisor engine, perform this task in privileged mode:

Task

Command

Reset the active supervisor engine (where mod is the number of the active supervisor engine).

reset mod

In addition, you can also force a switchover to the standby supervisor engine by setting the CISCO-STACK-MIB moduleAction variable to reset(2) on the active supervisor engine. When the switchover occurs, the system sends a standard SNMP warm-start trap to the configured trap receivers.

This example shows the console output on the active supervisor engine when you force a switchover from the active to the standby supervisor engine:
Console> (enable) reset 1
This command will force a switch-over to the standby Supervisor module.
Do you want to continue (y/n) [n]? y
Console> (enable) 12/07/1998,17:04:39:SYS-5:Module 1 reset from Console//
System Bootstrap, Version 3.1(2)
Copyright (c) 1994-1997 by cisco Systems, Inc.
System Bootstrap, Version 3.1(2)
Copyright (c) 1994-1997 by cisco Systems, Inc.
Presto processor with 32768 Kbytes of main memory
Autoboot executing command: "boot bootflash:cat6000-sup.5-4-1a.bin"
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
Uncompressing file:  ###########################################################
System Power On Diagnostics
NVRAM Size .. .................512KB
ID Prom Test ..................Passed
DPRAM Size ....................16KB
DPRAM Data 0x55 Test ..........Passed
DPRAM Data 0xaa Test ..........Passed
DPRAM Address Test ............Passed
Clearing DPRAM ................Done
System DRAM Memory Size .......32MB
DRAM Data 0x55 Test ...........Passed
DRAM Data 0xaa Test ...........Passed
DRAM Address Test  ............Passed
Clearing DRAM .................Done
EARLII ........................Present
EARLII RAM Test ...............Passed
EARL Serial Prom Test .........Passed
Level2 Cache ..................Present
Level2 Cache test..............Passed
Boot image: bootflash:cat6000-sup.5-4-1a.bin
Downloading epld sram device please wait ...
Programming successful for Altera 10K50 SRAM EPLD
This module is now in standby mode.
Console is disabled for standby supervisor
This example shows the console output on the standby supervisor engine when you force a switchover from the active to the standby supervisor engine:
Cisco Systems Console
Enter password:
12/07/1998,17:04:43:MLS-5:Multilayer switching is enabled
12/07/1998,17:04:43:MLS-5:Netflow Data Export disabled
12/07/1998,17:04:44:SYS-5:Module 2 is online
12/07/1998,17:04:45:SYS-5:Module 5 is online
12/07/1998,17:04:45:SYS-5:Module 7 is online
12/07/1998,17:04:45:SYS-5:Module 3 is online
12/07/1998,17:04:52:MLS-5:Route Processor 172.20.52.6 added
12/07/1998,17:05:10:SYS-5:Module 8 is online
12/07/1998,17:05:14:SYS-5:Module 9 is online
12/07/1998,17:05:22:SYS-5:Module 4 is online
12/07/1998,17:06:13:SYS-5:Module 1 is in standby mode
Supervisor image synchronization process will start in 10 seconds
12/07/1998,17:06:37:SYS-5:Ports on standby supervisor(Module 1) are UP
12/07/1998,17:06:41:SYS-5:Active supervisor is synchronizing the NMP image.
12/07/1998,17:06:44:SYS-5:The active supervisor has synchronized the NMP image.
Console>
High Availability

High availability allows you to minimize the switchover time from the active supervisor engine to the standby supervisor engine if the active supervisor engine fails.

Prior to this feature, fast switchover ensured that a switchover to the standby supervisor engine happened quickly. However, with fast switchover, because the state of the switch features before the switchover was unknown, you had to reinitialize and restart all the switch features when the standby supervisor engine assumed the active role.

High availability removes this limitation; high availability allows the active supervisor engine to communicate with the standby supervisor engine, keeping feature protocol states synchronized. Synchronization between the supervisor engines allows the standby supervisor engine to take over in the event of a failure.

In addition, high availability provides a versioning option that allows you to run the different software images on the active and standby supervisor engines.

These features are discussed in these sections:

•High-Availability Overview

•High-Availability Supported Features

•High-Availability Configuration Guidelines

•Versioning Overview

•CLI Commands

•Loading a Different but Compatible Image on the Standby Supervisor Engine

High-Availability Overview

For high availability, a system database is maintained on the active supervisor engine and the updates are sent to the standby supervisor engine for any change of data in the system database. The active supervisor engine communicates and updates the standby supervisor engine when any state changes occur, ensuring that the standby supervisor engine knows the current protocol state of the supported features. The standby supervisor engine knows the current protocol states for all modules, ports, and VLANs; the protocols can initialize with this state information and start running immediately.

The active supervisor engine controls the system bus (backplane), sends and receives the packets to and from the network, and controls all modules. The protocols run on the active supervisor engine only.

The standby supervisor engine is isolated from the system bus and does not switch packets, but it does receive the packets from the switching bus to learn and populate its Layer 2 forwarding table for Layer 2-switched flows. In addition, the standby supervisor engine receives the packets from the switching bus to learn and populate tables for the Layer 3-switched flows. The standby supervisor engine does not participate in forwarding any packets and does not communicate with any modules.

If you enable high availability when the standby supervisor engine is running, the image version compatibility is checked and if found compatible, the database synchronization is started. High-availability compatible features continue from the saved states on the standby supervisor engine after a switchover.

When you disable high availability, the database synchronization is not done and all features must restart on the standby supervisor engine after a switchover.

If you change high availability from enabled to disabled, synchronization from the active supervisor engine is stopped and the standby supervisor engine discards all the current synchronization data.

If you change high availability from disabled to enabled, synchronization from the active to the standby supervisor engine is started (if the standby supervisor engine is present and its image version is compatible).

NVRAM synchronization occurs regardless of high availability being enabled or disabled (if there are compatible NVRAM versions on the two supervisor engines).

If you do not install a standby supervisor engine during the system bootup, the active supervisor engine detects this and the database updates are not queued for synchronization. Similarly, when you reset or remove the standby supervisor engine, the synchronization updates are not queued and any pending updates in the synchronization queue are discarded. When you hot insert or restart a second supervisor engine that becomes the standby supervisor engine, the active supervisor engine downloads the entire system database to the standby supervisor engine. Only after this global synchronization is completed, the active supervisor engine queues and synchronizes the individual updates to the standby supervisor engine.

Note When you hot insert or restart a second supervisor engine, it might take a few minutes for the global synchronization to complete.

High-Availability Supported Features

The high-availability features for the Catalyst 6500 series switch are classified into three categories (see Table 23-1):

•Supported features—High availability is fully supported; the feature's database is synchronized from the active supervisor engine to the standby supervisor engine.

•Compatible features—High availability is not supported; the feature's database is not synchronized from the active supervisor engine to the standby supervisor engine. However, you can enable the compatible features when you enable high availability.

•Incompatible features—High availability is not supported. The feature's database is not synchronized from the active supervisor engine to the standby supervisor engine. You cannot enable the incompatible features if you enable high availability, and you cannot enable high availability if you enable these incompatible features.

Table 23-1 High-Availability Feature Support

Supported Features

Compatible Features

Incompatible Features

CEF

ASLB

Dynamic VLAN

COPS-DS

CDP

GVRP

COPS-PR

GMRP

Protocol filtering

DTP

IGMP snooping

EtherChannel

RMON

Cisco IOS ACLs

RSVP

MLS

SNMP

PAgP

Telnet sessions

QoS

UplinkFast

SPAN

VTP pruning

STP

Trunking

UDLD

VACLs

VTP

Port security

802.1x

High-Availability Configuration Guidelines

This section describes the guidelines for configuring high availability:

•High availability does not preserve the routing table entries on the active MSFC because high availability is not run on the Cisco IOS software. However, you can configure both MSFCs on the active and standby supervisor engines with the same configuration to preserve the routing table entries across the active and standby MSFCs. You can then configure HSRP on the MSFCs to provide automatic routing backup. See the "MSFC Redundancy" section for detailed information.

•The timers and statistics are not synchronized from the active to the standby supervisor engine.

•The MLS flows are preserved from the active supervisor engine to the standby supervisor engine.

•On the 802.1X ports, only the authorized and unauthorized states are synchronized from the active to the standby supervisor engine. The ports in any other state are initialized or restarted after switchover occurs.

•The 802.1X record updates are minimized by grouping similar types of updates into a single record.
The active supervisor engine sends the record to the standby supervisor engine when a variable in the record changes.

•The 802.1X reauthentication timers for the authorized ports restart after the switchover occurs.

•The port security statistics are not synchronized from the active to the standby supervisor engine.

•When you enable high availability or hot insert a standby supervisor engine on a switch that has secure ports, all the per-port and MAC-related information is synchronized from the active to the standby supervisor engine.

Versioning Overview

With high-availability versioning enabled, you can have two different but compatible images on the active and standby supervisor engines. The active supervisor engine exchanges image version information with the standby supervisor engine and determines whether the images are compatible for enabling high availability. If the active and standby supervisor engines are not running compatible image versions, you cannot enable high availability.

Image versioning is supported in supervisor engine software releases 5.4(1) and later. With versioning enabled, high availability is fully supported with the active and standby supervisor engines running different images as long as the images are compatible. The only fully compatible images are as follows:

Note There is no software image version compatibility in the 8.x software release train. This includes major releases such as 8.1(x) to 8.2(x) to 8.3(x) and so on. This also includes subreleases such as 8.1(1) to 8.1(2), 8.2(1) to 8.2(2) and so on.

•Supervisor Engine 1

–5.5(3) and 5.5(4)

–6.1(3) and 6.1(4)

–6.2(2) and 6.2(3)

–6.3(2) and 6.3(3)

–6.3(4) and 6.3(5)

–6.3(6) and 6.3(7)

•Supervisor Engine 2

–6.1(3) and 6.1(4)

–6.2(2) and 6.2(3)

–6.3(2) and 6.3(3)

Images that are compatible with all modules except Gigabit Ethernet switching modules are as follows:

•Supervisor Engine 1

–5.4(3) and 5.4(4)

–5.5(3) and 5.5(5)

–5.5(4) and 5.5(5)

Images that are compatible with Gigabit Ethernet switching modules but not compatible with 10/100BASE-T modules are as follows:

•Supervisor Engine 1

–5.5(6a) and 5.5(7)

Images that are compatible with all modules except the SFM/SFM2 and fabric-enabled modules are as follows:

•Supervisor Engine 2

–6.3(4) and 6.3(5)

–6.3(6) and 6.3(7)

Note Attempting to run incompatible image versions could result in configuration loss.

Note When you install two supervisor engines, the first supervisor engine to come online becomes the active module; the second supervisor engine goes into standby mode. If two supervisor engines are installed in your system, at power up the supervisor engine in slot 1 becomes active, and the supervisor engine in slot 2 enters standby mode. If the software versions of the two supervisor engines are different, or if the NVRAM configuration of the two supervisor engines is different, and if you do not enable versioning, the active supervisor engine automatically downloads its software image and configuration to the standby supervisor engine.

CLI Commands

This section describes the CLI commands for high availability and versioning.

Enabling or Disabling High Availability

High availability is disabled by default. To enable or disable high availability, perform this task in privileged mode:

Task

Command

Enable or disable high availability.

set system highavailability {enable | disable}

This example shows how to enable high availability:
Console> (enable) set system highavailability enable
System high availability enabled.
Console> (enable) 
This example shows how to disable high availability:
Console> (enable) set system highavailability disable
System high availability disabled.
Console> (enable) 
Enabling or Disabling High-Availability Versioning

High-availability versioning is disabled by default. To enable or disable high-availability versioning, perform this task in privileged mode:

Task

Command

Enable or disable high-availability versioning.

set system highavailability versioning {enable | disable}

This example shows how to enable high-availability versioning:
Console> (enable) set system highavailability versioning enable
Image versioning enabled.
Console> (enable) 
This example shows how to disable high-availability versioning:
Console> (enable) set system highavailability versioning disable
Image versioning disabled.
Console> (enable) 
Showing High-Availability Settings and Operational Status

The show system highavailability command displays the following:

•High-availability setting (enabled or disabled)

•Versioning setting (enabled or disabled)

•High-availability operational status (based on whether the standby supervisor engine is present and operational). The operational status field displays one of the following:

–OFF (high-availability-not-enabled): The high availability option in NVRAM is disabled.

–OFF (standby-supervisor-not-present): The standby supervisor engine is not installed.

–OFF (standby-supervisor-image-incompatible): The standby supervisor engine is running a different image than the active supervisor engine and it is not version compatible (the versioning option in NVRAM is enabled). No synchronization is done (even a configuration change in NVRAM on the active supervisor engine cannot be propagated to the standby supervisor engine because of the version incompatibility).

–OFF (standby-supervisor-image-nvram-only-compat): The standby supervisor engine is running a different image than the active supervisor engine (the versioning option in NVRAM is enabled) and the image is only NVRAM compatible (a configuration change in NVRAM on the active supervisor engine is propagated to the standby supervisor engine). However, high availability cannot be supported.

–OFF (standby-supervisor-not-operational-yet): The standby supervisor engine is detected but is not operational (not online yet).

–OFF (high-availability-not-operational-yet): The standby supervisor engine is operational (online), but high availability is not operational yet (when the system is booted from reset, it takes a few minutes before high availability is operational).

–ON: High availability is operational. The active supervisor engine's features have started queuing their state changes for synchronizing to the standby supervisor engine.

To display the high-availability configuration and operational states, perform this task:

Task

Command

Display the high-availability configuration and operational states.

show system highavailability

This example shows how to display the high-availability configuration and operational states:
Console> (enable) show system highavailability
Highavailability: disabled
Highavailability versioning: disabled
Highavailability Operational-status: OFF (high-availability-not-enabled)
Console> (enable)
This example shows how to enable high availability:
Console> (enable) set system highavailability enable
System high availability enabled.
Console> (enable)
Console> (enable) show system highavailability
Highavailability: enabled
Highavailability versioning: disabled
Highavailability Operational-status: ON
Console> (enable)
Loading a Different but Compatible Image on the Standby Supervisor Engine

Use this procedure to load a new image on the standby supervisor engine that is different from the image on the active supervisor engine. From the active supervisor engine console port, perform these steps (active supervisor engine is in slot 1):

Step 1 Enable high availability versioning.
Console> (enable) set system highavailability versioning enable
System high availability enabled.
Console> (enable) 
Step 2 Download the new image to the active supervisor engine bootflash.
Console> (enable) copy tftp:image2.bin bootflash
IP address or name of remote host []? 172.20.52.3
8763532 bytes available on device bootflash, proceed (y/n) [n]? y
.
.
.
Console> (enable)
Step 3 Copy the new image to the standby supervisor engine bootflash.
Console> (enable) copy bootflash:image2.bin 2/bootflash:
5786532 bytes available on device bootflash, proceed (y/n) [n]? y
.
.
.
Console> (enable)
Step 4 Modify the BOOT environment variable so that the standby supervisor engine boots the new image.
Console> (enable) set boot system flash bootflash:image2.bin prepend 2
BOOT variable = bootflash:image2.bin,1;slot0:image1.bin,1
Console> (enable)
Step 5 To boot the new image, reset the standby supervisor engine.
Console> (enable) reset 2
This command will reset the system.
Do you want to continue (y/n) [n]? y 
.
.
.
Console> (enable)
Configuring Supervisor Engine Redundancy Using NSF with SSO

Cisco NSF works with SSO to minimize the amount of time that a network is unavailable to its users following a switchover while continuing to forward the IP packets.

For information about configuring NSF with SSO, refer to "Configuring Supervisor Engine Redundancy using NSF with SSO" in the Catalyst 6500 Series Cisco IOS Software Configuration Guide, 12.2SX at this URL:. http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/nsfsso.html.

Supervisor Engine Synchronization Examples

These sections explain what happens when the synchronization function encounters certain conditions:

•Synchronizing the Run-Time Image with the Bootstring

•Synchronizing the Boot Images on the Active and Standby Supervisor Engines

Note In the following examples, the number 1 following the filename in the bootstring (for example, bootflash:f1,1) indicates the number of Trivial File Transfer Protocol (TFTP) boot retries that are attempted. However, the supervisor engine does not support TFTP booting. The number is included in these examples to be consistent with Cisco IOS conventions.

Note These examples are not intended to cover every possible condition.

Synchronizing the Run-Time Image with the Bootstring

This section contains four examples in which the active supervisor engine run-time image is synchronized with the standby supervisor engine.

Example 1: Run-time image not synchronized

The configuration for example 1 is as follows:

•The active supervisor engine configuration is as follows (if the image in the standby supervisor engine is identical to the image in the active supervisor engine, the output is the same):

–Run-time image: bootflash:f1

–Bootstring: bootflash:f1,1

–Bootflash: f1

•The time stamp for f1 on the active supervisor engine is the same as f1 on the standby supervisor engine.

•The expected results are as follows:

–The active supervisor engine f1 image is not copied to the standby supervisor engine.

–The standby supervisor engine bootstring is not modified.

–The standby supervisor engine is not reset.

Example 2: File copied, bootstring changed, standby supervisor engine reset

The configuration for example 2 is as follows:

•The active supervisor engine configuration is as follows:

–Run-time image: bootflash:f1

–Bootstring: bootflash:f1,1

–Bootflash: f1

•The standby supervisor engine configuration is as follows:

–Run-time image: bootflash:f2

–Bootstring: bootflash:f2,1

–Bootflash: f2

•The time stamp for f1 on the active supervisor engine is not the same as f2 on the standby supervisor engine.

•The expected results are as follows:

–The active supervisor engine copies f1 to the standby supervisor engine and renames the file RTSYNC_f1.

–The standby supervisor engine bootflash is modified to the following: f2, RTSYNC_f1.

–The standby supervisor engine bootstring is modified to the following: bootflash:RTSYNC_f1,1;f2,1;.

–The standby supervisor engine is reset.

Example 3: File not copied, bootstring changed, standby supervisor engine reset

The configuration for example 3 is as follows:

•The active supervisor engine configuration is as follows:

–Run-time image: bootflash:f1

–Bootstring: bootflash:f1,1

–Bootflash: f1

•The standby supervisor engine configuration is as follows:

–Run-time image: bootflash:f2

–Bootstring: bootflash:f2,1

–Bootflash: f1,f2

•The time stamp for f1 on the active supervisor engine is the same as f1 on the standby supervisor engine but is not the same as f2 on the standby supervisor engine.

•The expected results are as follows:

–The active supervisor engine run-time image is synchronized to the standby supervisor engine.

–The active supervisor engine f1 image is not copied to the standby supervisor engine.

–The standby supervisor engine bootstring is modified to the following: f1,1;f2,1;.

–The standby supervisor engine is reset.

Example 4: Oldest bootflash file deleted, bootflash squeezed

The configuration for example 4 is as follows:

•The active supervisor engine configuration is as follows:

–Run-time image: bootflash:f1

–Bootstring: bootflash:f1,1

–Bootflash: f1

•The standby supervisor engine configuration is as follows:

–Run-time image: bootflash:f2

–Bootstring: bootflash:f2,1;

–Bootflash: f2, f3, f4 (less than 1 MB left on device)

•The time stamp for f1 on the active supervisor engine is not the same as f2 on the standby supervisor engine. The f2 time stamp is older than f3, and the f3 time stamp is older than f4.

•The expected results are as follows:

–The active supervisor engine run-time image is synchronized with the standby supervisor engine.

–The active supervisor engine attempts to copy its f1 image to the standby supervisor engine.

–Because there is not enough space on the standby supervisor engine bootflash, the redundant synchronization function finds the oldest file, deletes it, and squeezes bootflash.

–The active supervisor engine copies the f1 image to the standby supervisor engine and renames it RTSYNC_f1.

–The standby supervisor engine bootflash is modified to the following: f3, f4, RTSYNC_f1.

–The standby supervisor engine bootstring is modified to the following: RTSYNC_f1,1;f2,1;.

–The standby supervisor engine is reset.

Synchronizing the Boot Images on the Active and Standby Supervisor Engines

This section contains four examples in which the bootstrings on the active and standby supervisor engines are synchronized.

Example 1: Unable to allocate the boot image

The configuration for this example is as follows:

•The active supervisor engine configuration is as follows:

–Run-time image: bootflash:f1

–Bootstring: bootflash:f1,1;

–Bootflash: f1

•The standby supervisor engine configuration is as follows:

–Run-time image: bootflash:f1

–Bootstring: bootflash:f1,1;

–Bootflash: f1

•The time stamp for f1 on the active supervisor engine is the same as f1 on the standby supervisor engine.

•The system attempts to modify the active supervisor engine bootstring to the following: f2,1;.

•The expected results are as follows:

–The active supervisor engine is unable to allocate f2, causing the synchronization to fail.

–An error is recorded in syslog.

–The active supervisor engine f1 image is not copied to the standby supervisor engine.

–The standby supervisor engine bootstring is not modified.

–The standby supervisor engine is not reset.

Example 2: File copied, bootflash modified, standby supervisor engine not reset

The configuration for this example is as follows:

•The active supervisor engine configuration is as follows:

–Run-time image: bootflash:f1

–Bootstring: bootflash:f1,1;

–Bootflash: f1,f2

•The standby supervisor engine configuration is as follows:

–Run-time image: bootflash:f1

–Bootstring: bootflash:f1,1;

–Bootflash: f1

•The time stamp for f1 on the active supervisor engine is the same as f1 on the standby supervisor engine.

•You modify the active supervisor engine bootstring to the following: f2,1;.

•The expected results are as follows:

–The active supervisor engine copies its f2 image to the standby supervisor engine and renames it BTSYNC_f2.

–The standby supervisor engine bootflash is modified to the following: f1, BTSYNC_f2.

–The standby supervisor engine bootstring is modified to the following: bootflash:BTSYNC_f2,1;f1,1;.

–The standby supervisor engine is not reset.

Example 3: File not copied, bootstring modified, standby supervisor engine not reset

The configuration for this example is as follows:

•The active supervisor engine configuration is as follows:

–Run-time image: bootflash:f1

–Bootstring: bootflash:f1,1;

–Bootflash: f1,f2

•The standby supervisor engine configuration is as follows:

–Run-time image: bootflash:f1

–Bootstring: bootflash:f1,1;

–Bootflash: f1,f2

•The time stamp for f1 on the active supervisor engine is the same as f1 on the standby supervisor engine; the time stamp for f2 on the active supervisor engine is the same as f2 on the standby supervisor engine.

•The active supervisor engine bootstring is modified to the following: f2,1; f1,1;.

•The expected results are as follows:

–The active supervisor engine f1 image is not copied to the standby supervisor engine.

–The standby supervisor engine bootstring is modified to the following: bootflash:f2,1;bootflash:f1,1;.

–The standby supervisor engine is not reset.

Example 4: File copied, oldest file deleted, bootflash squeezed, bootstring modified, standby supervisor engine not reset

The configuration for this example is as follows:

•The active supervisor engine configuration is as follows:

–Run-time image: bootflash:f1

–Bootstring: bootflash:f1,1;

–Bootflash: f1,f2

•The standby supervisor engine configuration is as follows:

–Run-time image: bootflash:f1

–Bootstring: bootflash:f1,1;

–Bootflash: f0,f1,f3 (less than 1 MB left on device)

•The time stamp for f1 on the active supervisor engine is the same as f1 on the standby supervisor engine. The time stamp for f0 is older than f1, and the time stamp for f1 is older than f3.

•The active supervisor engine bootstring is modified to the following: bootflash:f2,1;bootflash:f1,1;

•The expected results are as follows:

–The active supervisor engine attempts to copy its f2 image to the standby supervisor engine.

–Because there is not enough space available on the standby supervisor engine bootflash, the redundant synchronization function finds the oldest file (f0), deletes it, and squeezes bootflash.

–The active supervisor engine copies its f2 image to the standby supervisor engine and renames it BTSYNC_f2.

–The standby supervisor engine bootflash is modified to the following: f1, f3, BTSYNC_f2.

–The standby supervisor engine bootstring is modified to the following: bootflash:BTSYNC_f2,1;bootflash:f1,1;.

MSFC Redundancy

MSFC redundancy is described in these sections:

•Dual MSFC Redundancy

•Single Router Mode Redundancy

•Manual-Mode MSFC Redundancy

Note For information on configuring MSFC redundancy using Cisco nonstop forwarding (NSF) with stateful switchover (SSO), see Chapter 24, "Configuring NSF with SSO MSFC Redundancy."

Note Single router mode redundancy is the only supported MSFC redundancy option for Supervisor Engine 720 and Supervisor Engine 32.

Dual MSFC Redundancy

Caution You must configure both MSFCs identically. Table 23-2 summarizes the identical requirements and the exceptions for Layer 3 redundancy for a single switch chassis.

We do not support configurations where the MSFCs are not configured identically.

These sections describe how to configure MSFC redundancy:

•Hardware and Software Requirements

•Layer 3 Redundancy for a Single Chassis

•Routing Protocol Peering

•Access Control List Configuration

•Dual MSFC Operational Model for Redundancy and Load Sharing

•Understanding Failure Scenarios

Hardware and Software Requirements

To configure Layer 3 redundancy, you must have at least one of the following configurations:

•A single chassis with two identical supervisor engine daughter card configurations:

–Supervisor Engine 1 with Policy Feature Card (PFC) and MSFC or MSFC2 (both supervisor engines must have the same type of MSFC)

–Supervisor Engine 2 with PFC2 and MSFC2

•Two chassis with a supervisor engine in each—You must have at least one supervisor engine in each chassis. Each supervisor engine must be equipped with a PFC and an MSFC.

Note Each MSFC must be running the same release of Cisco IOS software.

Layer 3 Redundancy for a Single Chassis

In a single Catalyst 6500 series chassis, you can have the redundant supervisor engines, each with an MSFC. You can configure Hot Standby Router Protocol (HSRP) on the MSFCs to provide transparent default gateway redundancy for the IP hosts in the network. HSRP configuration can coexist with the IPX and AppleTalk configuration on the same interfaces.

If one MSFC fails, HSRP allows one MSFC (router) to assume the function automatically of the other MSFC. Combined with the high-availability feature of supervisor engine software release 5.4(1), this configuration provides an added level of redundancy for your network.

Caution You must configure both MSFCs identically. Table 23-2 summarizes the identical requirements and the exceptions for Layer 3 redundancy for a single switch chassis.

Table 23-2 Single Chassis Layer 3-Redundancy Requirements

Identical Requirements— Global and Interface Levels

Exceptions—Interface Level

Exceptions—Global Level

•Both MSFCs must have the following:

–Same routing protocols

–Same static routes

–Same default routes

–Same policy routes

–Same VLAN interfaces

–Same Cisco IOS ACLs¹, ²

•All interfaces must have the same administrative status

•HSRP standby commands

•IP address commands³

•IPX network3

•IP default-gateway

•IPX internal-network

•IPX default-route

¹The dynamic and reflexive ACLs, which are based on actual data flow, may be programmed by either MSFC.

²In addition to defining the same ACLs on both MSFCs, you must also apply the ACLs to the same VLAN interfaces in the same direction on both MSFCs.

³The IP or IPX addresses do not have to be identical on both MSFCs, but there must be an IP or IPX address configured on both MSFCs.

For information on specifying the alternate configurations for the interface and global level exceptions that are listed in Table 23-2, see the "alt Keyword Usage" section.

The redundant supervisor engines must have identical hardware (MSFC and PFC). See the "Hardware and Software Requirements" section for more information.

Note For the MSFC and MSFC2 memory requirements, refer to the Release Notes for MSFC publication at this URL: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/relnotes/index.htm

Routing Protocol Peering

In a redundant supervisor engine and dual MSFC configuration, one supervisor engine is fully operational (active) and the other supervisor engine is in standby mode; however, both MSFCs are operational (in terms of programming the PFC on the active supervisor engine) and act as independent routers.

Note PFC: With the PFC, MLS entries can be associated with either MSFC (based on which MSFC routed the first packet). Only the PFC on the active supervisor engine switches the packets.

Note PFC2: With PFC2, only the designated MSFC programs the forwarding information base (FIB), the adjacency table, Cisco IOS software, and policy routing ACLs on the active supervisor engine. If you configure static routes or policy routing, you must have the identical configuration on both MSFCs. If you have a static route on the nondesignated MSFC that is not on the designated MSFC, that route will not be programmed in the PFC2.

Both MSFCs are operational from a routing protocol peering perspective. For example, if you have two MSFCs in a single Catalyst 6500 series switch chassis, each configured with interface VLAN 10 and VLAN 21, the MSFCs are peered to each other over these VLANs. Combined with a dual chassis and dual MSFC design for the same VLANs, each MSFC has 6 peers: its peer in the same chassis and the 2 MSFCs in the second chassis (3 in VLAN 10 and 3 in VLAN 21). See Figure 23-1.

Figure 23-1 Dual Chassis and Dual MSFC Peering

Although the MSFCs (from a peering perspective) act as independent routers, the two MSFCs in the chassis operate at the same time, have the same interfaces, and run the same routing protocols.

If you combine high availability on the supervisor engines with HSRP on the MSFCs, you have the following Layer 2 and Layer 3 redundancy mechanisms:

•Layer 2 redundancy for the supervisor engines (one active and one in standby)—If the active supervisor engine fails (the MSFC installed on it will also fail), both Layer 2 and Layer 3 functions roll over to the redundant supervisor engine and MSFC combination.

•Layer 3 redundancy and load sharing for the two MSFCs—If one MSFC fails, the other MSFC takes over almost immediately (using HSRP) without any Layer 2 disruption (the active supervisor engine continues to forward Layer 2 traffic).

The Layer 3 entries that are programmed by the failed MSFC on the active supervisor engine are used until they gracefully age out and are replaced by the Layer 3 entries that are populated by the newly active MSFC. Aging takes 4 minutes and allows the newly active MSFC to repopulate the MLS entries using its XTAG value, while concurrently hardware-switching flows that are yet to be aged. In addition, this process prevents a newly active MSFC from being overwhelmed with the initial flow traffic.

Note Each MSFC has its own XTAG value to identify itself as the MLS Route Processor. MSFC #1 (on the active supervisor engine) has an XTAG of 1, and MSFC #2 (on the standby supervisor engine) has an XTAG of 2.

Only Supervisor Engine 1 uses the XTAG values; XTAG values are not used on Supervisor Engine 2.

Caution For same-chassis Layer 3 redundancy to function as expected, the configuration on each MSFC must be the same (see Table 23-2).

Note Table 23-2 lists the configuration exceptions. For example, in Figure 23-1, there are 4 MSFCs on VLAN 10; each MSFC has different IP addresses and HSRP priorities.

Access Control List Configuration

If you use the Cisco IOS access control lists (ACLs) on the MSFC, you must configure the ACLs on both MSFCs identically, globally, and at the interface level. Only the designated MSFC (the MSFC to come online first or the MSFC that has been online the longest) programs the PFC with ACL information.

The active supervisor engine's PFC multilayer switches the packets (CEF [Cisco Express Forwarding] for PFC2) after consulting with its ACL ASIC to determine whether a packet is forwarded or not, depending on the Cisco IOS ACL that is configured. If a designated MSFC fails, the new designated MSFC must reprogram the PFC for static ACLs. For consistent results, both MSFCs must have identical ACL configurations, including the static ACLs.

Note In addition to defining the same ACLs on both MSFCs, you must also apply the ACLs to the same VLAN interfaces on both MSFCs.

Note The dynamic and reflexive ACLs, which are based on the actual data flow, may be programmed by either MSFC.

Note PFC: For detailed information on the hardware and software handling of the Cisco IOS ACLs with the PFC, see the "Hardware and Software Handling of Cisco IOS ACLs with PFC" section on page 15-10.

Note PFC2: For detailed information on the hardware and software handling of the Cisco IOS ACLs with PFC2, see the "Hardware and Software Handling of Cisco IOS ACLs with PFC2 and PFC3A/PFC3B/PFC3BXL" section on page 15-13.

To determine the status of the designated MSFC, enter the show fm features or the show redundancy command:
Router-15# show redundancy 
Designated Router: 1 Non-designated Router:2
Redundancy Status: non-designated
Config Sync AdminStatus  : enabled
Config Sync RuntimeStatus: enabled
Router-16# show redundancy
Designated Router: 1 Non-designated Router:2
Redundancy Status: designated
Config Sync AdminStatus  : enabled
Config sync RuntimeStatus: enabled
Dual MSFC Operational Model for Redundancy and Load Sharing

Figure 23-2 shows a typical access and distribution layer building block with multiple VLANs in an access layer switch. Because there is no Layer 2 loop, HSRP is used for convergence and load sharing. Switches S1 and S2 have a supervisor engine with an MSFC in slot 1 (Sup #1/MSFC #1) and in slot 2 (Sup #2/MSFC #2). Sup #1 is active and Sup #2 is in standby mode in both switches. High availability is enabled on the supervisor engines. The supervisor engines automatically perform image and configuration synchronization; you must manually synchronize the images and configurations on the MSFCs.

Figure 23-2 Dual MSFC Operational Model for Redundancy and Load Sharing—VLANs 10 and 21

In Figure 23-2, you should configure redundancy and load sharing as follows:

•VLAN 10 (even-numbered VLANs)—Configure MSFC #1 in Switch S1 as the primary HSRP router (priority 110), and configure MSFC #2 as the standby router (priority 109).

•VLAN 21 (odd-numbered VLANs)—Configure MSFC #1 in Switch S2 as the primary HSRP router (priority 110), and configure MSFC #2 as the standby router (priority 109).

Load sharing is achieved by having the even-numbered VLANs routed by Switch S1 and the odd-numbered VLANs routed by Switch S2. In a complete switch failure, the remaining switch would service both the even and odd VLANs.

You can achieve further load sharing by using MSFC #2 in Switch S1 as the primary HSRP router for VLAN 12 and MSFC #2 as the primary HSRP router in Switch S2 for VLAN 23 (see Figure 23-3).

Figure 23-3 Dual MSFC Operational Model for Redundancy and Load Sharing—
VLANs 10, 12, 21, and 23

Only the active HSRP router for a VLAN will respond with the HSRP MAC address for ARP requests to the HSRP IP address. The active HSRP router will in turn ARP for the end stations' MAC address and populate its ARP cache. By using both MSFCs in a single chassis to share the HSRP duties for the even VLANs, you can share the control plane ARP traffic. In an MSFC failure, only the ARP entries on the affected VLAN would need to be relearned.

The tradeoff for this level of redundancy and load sharing is the added complexity of keeping track of the even and odd VLANs on the MSFCs within a Catalyst 6500 series switch chassis.

The MLS entries are created for the packets arriving at the HSRP MAC addresses and those packets arriving with the router's real MAC addresses. HSRP is used for unicast traffic first-hop redundancy; for traffic that is received through another router attached to VLAN 10, for example, the actual MAC address of Sup #1/MSFC #1 is used.

Understanding Failure Scenarios

These five examples describe the possible failure scenarios within a single chassis with dual supervisor engines and dual MSFCs (see Figure 23-4) when you enable high availability. The designated MSFC refers to the MSFC that is used to program the ACL ASIC for the static ACLs.

Note While the examples are specific to the PFC, the failover scenarios for the PFC2/MSFC2 would be similar for handling the ACLs and the CEF table entries. On a Supervisor Engine 2, the designated MSFC2 programs many of the ASICs on the PFC2 including building the CEF table. In a designated MSFC2 HSRP failover to the nondesignated MSFC2, the PFC2 continues to function with the CEF table that is programmed by the previously designated MSFC2. Similar to the process with the MLS cache in a Supervisor Engine 1/MSFC configuration, the newly designated MSFC2 reprograms the CEF table with its own entries and the old entries age out.

Figure 23-4 Single Chassis with Dual Supervisor Engines and Dual MSFCs

Failure Case 1: Designated MSFC #1 Fails

This sequence occurs when the designated MSFC #1 fails:

1. The MLS entries for MSFC #1 gracefully age out of the Sup #1 Layer-3 cache, while MSFC #2 takes temporary ownership of these MLS entries using its XTAG value.

2. The MLS entries for MSFC #2 are not affected.

3. MSFC #2 removes all the dynamic and reflexive ACLs that are programmed in the hardware by MSFC #1.

4. MSFC #2 reprograms the static ACLs in the Sup #1 ACL ASIC because it is now the designated MSFC.

Failure Case 2: Nondesignated MSFC #2 Fails

This sequence occurs when the nondesignated MSFC #2 fails:

1. The MLS entries for MSFC #2 gracefully age out of the Sup #1 Layer 3 cache, while MSFC #1 takes temporary ownership of these MLS entries using its XTAG value.

2. The MLS entries from MSFC #1 are not affected.

3. MSFC #1 removes all the dynamic and reflexive ACLs that are programmed in the hardware by MSFC #2.

4. MSFC #1 remains the designated MSFC.

Failure Case 3: Active Sup #1 Fails

This sequence occurs when the active supervisor engine (Sup #1) fails:

1. Because the Layer 3 state is maintained, the MLS entries of MSFC #1 gracefully age out of the Sup #2 Layer 3 cache while MSFC #2 takes temporary ownership of these MLS entries using its XTAG value.

2. The standby supervisor engine maintains the Layer 2 state so that there is no Layer 2 convergence time.

3. MSFC #2 removes all the dynamic and reflexive ACLs that are programmed in the hardware by MSFC #1.

4. MSFC #2 reprograms the static ACLs in the Sup #2 ACL ASIC. MSFC #2 is now the designated MSFC.

Failure Case 4: Standby Sup #2 Fails

This sequence occurs when the standby supervisor engine (Sup #2) fails:

1. The MLS entries for MSFC #2 gracefully age out of the Sup #1 Layer 3 cache while MSFC #1 takes temporary ownership of these MLS entries using its XTAG value.

2. The MLS entries from MSFC #1 are not affected.

3. MSFC #1 removes all the dynamic and reflexive ACLs that are programmed in the hardware by MSFC #2. MSFC #1 remains the designated MSFC.

Failure Case 5: New or Previously Failed Supervisor Comes Back Online

This sequence occurs when the previously failed supervisor engine (Sup #2) comes online:

1. Sup #1 continues to be the active supervisor engine.

2. Sup #2 synchronizes its image and configuration with Sup #1 (unless high-availability versioning is enabled).

3. MSFC #2 (on Sup #2) comes up. If the HSRP preempt for VLAN 21 is configured, then MSFC #2 becomes HSRP active. The MLS entries for MSFC #1 are purged and then relearned through MSFC #2.

4. MSFC #1 remains the designated MSFC for the static ACLs.

Configuring Redundancy with HSRP

Although the supervisor engine software high-availability feature maintains the protocol state between the redundant supervisor engines, you need to configure HSRP for failover between the redundant MSFCs. HSRP is used to provide first-hop, unicast redundancy. You can configure one or more HSRP groups on the MSFC VLAN interfaces to provide automatic routing backup for your network. Each VLAN interface in an HSRP group shares a virtual IP address and MAC address. You can configure the end stations and the other devices to use the HSRP address as the default gateway so that if one router interface fails, the service is not interrupted to those devices.

The interface with the highest HSRP priority is the active interface for that HSRP group.

Note PFC2: The PFC2 supports a maximum of 16 unique HSRP group numbers. You can use the same HSRP group numbers in different VLANs. If you configure more than 16 HSRP groups, this restriction prevents use of the VLAN number as the HSRP group number.

Note PFC2: Identically numbered HSRP groups use the same virtual MAC address, which might cause errors if you configure bridging on the MSFC.

Do not enter the standby use-bia option in an HSRP configuration. The MLS entries are not created when you enter the standby use-bia option. When the standby use-bia option is configured, if an HSRP active interface goes up and down, there will be no router CAM address for the standby VLAN interface. Without the router CAM entry, no shortcuts are created. This problem is independent of any MSFC Cisco IOS release. (This problem is documented in caveat CSCdz17169.)

To configure HSRP on an MSFC VLAN interface, perform this task in interface configuration mode:

Task

Command

Step 1

Enable HSRP and specify the HSRP IP address. If you do not specify a group_number, group 0 is used. To assist in troubleshooting, configure the group number to match the VLAN number.

Router(config-if)# standby [group_number] ip [ip_address]

Step 2

Specify the priority for the HSRP interface. Increase the priority of at least one interface in the HSRP group (the default is 100). The interface with the highest priority becomes active for that HSRP group.

Router(config-if)# standby [group_number] priority priority

Step 3

Configure the interface to preempt the current active HSRP interface and become active if the interface priority is higher than the priority of the current active interface.

Router(config-if)# standby [group_number] preempt [delay delay]

Step 4

(Optional) Set the HSRP hello timer and holdtime timer for the interface. The default values are 3 (hello) and 10 (holdtime). All interfaces in the HSRP group should use the same timer values.

Router(config-if)# standby [group_number] timers hellotime holdtime

Step 5

(Optional) Specify a clear-text HSRP authentication string for the interface. All interfaces in the HSRP group should use the same authentication string.

Router(config-if)# standby [group_number] authentication string

This example shows how to configure an interface as part of HSRP group 100:
Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# interface vlan100
Router(config-if)# standby 100 ip 172.20.100.10
Router(config-if)# standby 100 priority 110
Router(config-if)# standby 100 preempt
Router(config-if)# standby 100 timers 5 15
Router(config-if)# standby 100 authentication Secret
Router(config-if)# ^Z
Router# 
Configuration Examples

This section describes three configuration options for achieving redundancy:

•Example 1: Two Chassis with One Supervisor Engine and One MSFC Each

•Example 2: Single Chassis with Dual Supervisor Engines and MSFCs

•Example 3: Double Chassis with Dual Supervisor Engines and MSFCs

For the following examples, the designated MSFC is on the active supervisor engine. To determine the status of the designated MSFC, enter the show fm features or the show redundancy command. This example shows that Router-16 is the designated MSFC:
Router-15# show redundancy
Designated Router: 1 Non-designated Router:2
Redundancy Status: non-designated
Config Sync AdminStatus  : enabled
Config Sync RuntimeStatus: enabled
Router-16# show redundancy
Designated Router: 1 Non-designated Router:2
Redundancy Status: designated
Config Sync AdminStatus  : enabled
Config sync RuntimeStatus: enabled
Example 1: Two Chassis with One Supervisor Engine and One MSFC Each

In Figure 23-5, high availability cannot be configured on the supervisor engines, but HSRP can be configured on the MSFCs.

Figure 23-5 Two Chassis with One Supervisor Engine and One MSFC Each

This example shows how to configure HSRP on the MSFC in Switch S1:
Console> (enable) switch console 15
Trying Router-15...
Connected to Router-15.
Type ^C^C^C to switch back...
Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# interface vlan10
Router(config-if)# standby 10 ip 172.20.100.10
Router(config-if)# standby 10 priority 110 
Router(config-if)# standby 10 preempt
Router(config-if)# standby 10 timers 5 15
Router(config-if)# standby 10 authentication Secret
Router(config-if)# interface vlan21
Router(config-if)# standby 21 ip 192.20.100.21
Router(config-if)# standby 21 priority 109 
Router(config-if)# standby 21 preempt
Router(config-if)# standby 21 timers 5 15
Router(config-if)# standby 21 authentication Secret
Router(config-if)# ^Z
Router# ^C^C^C
This example shows how to configure HSRP on the MSFC in Switch S2:
Console> (enable) switch console 15
Trying Router-15...
Connected to Router-15.
Type ^C^C^C to switch back...
Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# interface vlan10
Router(config-if)# standby 10 ip 172.20.100.10
Router(config-if)# standby 10 priority 109 
Router(config-if)# standby 10 preempt
Router(config-if)# standby 10 timers 5 15
Router(config-if)# standby 10 authentication Secret
Router(config-if)# interface vlan21
Router(config-if)# standby 21 ip 192.20.100.21
Router(config-if)# standby 21 priority 110 
Router(config-if)# standby 21 preempt
Router(config-if)# standby 21 timers 5 15
Router(config-if)# standby 21 authentication Secret
Router(config-if)# ^Z
Router# ^C^C^C
Example 2: Single Chassis with Dual Supervisor Engines and MSFCs

In Figure 23-6, high availability is configured on the supervisor engines, and HSRP is configured on the MSFCs.

Figure 23-6 Single Chassis with Redundant Supervisor Engines and MSFCs

This example shows how to configure HSRP on the MSFC in Switch S1:
Console> (enable) switch console 15
Trying Router-15...
Connected to Router-15.
Type ^C^C^C to switch back...
Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# interface vlan10
Router(config-if)# standby 10 ip 172.20.100.10
Router(config-if)# standby 10 priority 110 
Router(config-if)# standby 10 preempt
Router(config-if)# standby 10 timers 5 15
Router(config-if)# standby 10 authentication Secret
Router(config-if)# interface vlan21
Router(config-if)# standby 21 ip 192.20.100.21
Router(config-if)# standby 21 priority 109 
Router(config-if)# standby 21 preempt
Router(config-if)# standby 21 timers 5 15
Router(config-if)# standby 21 authentication Secret
Router(config-if)# ^Z
Router# ^C^C^C
Console> (enable) switch console 16
Trying Router-16...
Connected to Router-16.
Type ^C^C^C to switch back...
Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# interface vlan10
Router(config-if)# standby 10 ip 172.20.100.10
Router(config-if)# standby 10 priority 109 
Router(config-if)# standby 10 preempt
Router(config-if)# standby 10 timers 5 15
Router(config-if)# standby 10 authentication Secret
Router(config-if)# interface vlan21
Router(config-if)# standby 21 ip 192.20.100.21
Router(config-if)# standby 21 priority 110
Router(config-if)# standby 21 preempt
Router(config-if)# standby 21 timers 5 15
Router(config-if)# standby 21 authentication Secret
Router(config-if)# ^Z
Router# ^C^C^C
Example 3: Double Chassis with Dual Supervisor Engines and MSFCs

Figure 23-7 shows two Catalyst 6500 series switches (S1 and S2), each with a supervisor engine and MSFC in slot 1 (Sup #1/MSFC #1) and slot 2 (Sup #2/MSFC #2). Because there is no Layer-2 loop, HSRP is used for convergence and load sharing. In both switches, Sup #1 is the active supervisor engine, and Sup #2 is the standby supervisor engine.

Figure 23-7 Dual MSFC Operational Model for Redundancy and Load Sharing

This example shows how to configure HSRP on the MSFC in Switch S1:
Console> (enable) switch console 15
Trying Router-15...
Connected to Router-15.
Type ^C^C^C to switch back...
Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# interface vlan10
Router(config-if)# standby 10 ip 172.20.100.10
Router(config-if)# standby 10 priority 110
Router(config-if)# standby 10 preempt
Router(config-if)# standby 10 timers 5 15
Router(config-if)# standby 10 authentication Secret
Router(config-if)# interface vlan21
Router(config-if)# standby 21 ip 192.20.100.21
Router(config-if)# standby 21 priority 108
Router(config-if)# standby 21 preempt
Router(config-if)# standby 21 timers 5 15
Router(config-if)# standby 21 authentication Secret
Router(config-if)# ^Z
Router# ^C^C^C
Console> (enable) switch console 16
Trying Router-16...
Connected to Router-16.
Type ^C^C^C to switch back...
Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# interface vlan10
Router(config-if)# standby 10 ip 172.20.100.10
Router(config-if)# standby 10 priority 109
Router(config-if)# standby 10 preempt
Router(config-if)# standby 10 timers 5 15
Router(config-if)# standby 10 authentication Secret
Router(config-if)# interface vlan21
Router(config-if)# standby 21 ip 192.20.100.21
Router(config-if)# standby 21 priority 107
Router(config-if)# standby 21 preempt
Router(config-if)# standby 21 timers 5 15
Router(config-if)# standby 21 authentication Secret
Router(config-if)# ^Z
Router# ^C^C^C
This example shows how to configure HSRP on the MSFC in Switch S2:
Console> (enable) switch console 15
Trying Router-15...
Connected to Router-15.
Type ^C^C^C to switch back...
Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# interface vlan10
Router(config-if)# standby 10 ip 172.20.100.10
Router(config-if)# standby 10 priority 108
Router(config-if)# standby 10 preempt
Router(config-if)# standby 10 timers 5 15
Router(config-if)# standby 10 authentication Secret
Router(config-if)# interface vlan21
Router(config-if)# standby 21 ip 192.20.100.21
Router(config-if)# standby 21 priority 110
Router(config-if)# standby 21 preempt
Router(config-if)# standby 21 timers 5 15
Router(config-if)# standby 21 authentication Secret
Router(config-if)# ^Z
Router# ^C^C^C
Console> (enable) switch console 16
Trying Router-16...
Connected to Router-16.
Type ^C^C^C to switch back...
Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# interface vlan10
Router(config-if)# standby 10 ip 172.20.100.10
Router(config-if)# standby 10 priority 107
Router(config-if)# standby 10 preempt
Router(config-if)# standby 10 timers 5 15
Router(config-if)# standby 10 authentication Secret
Router(config-if)# interface vlan21
Router(config-if)# standby 21 ip 192.20.100.21
Router(config-if)# standby 21 priority 109
Router(config-if)# standby 21 preempt
Router(config-if)# standby 21 timers 5 15
Router(config-if)# standby 21 authentication Secret
Router(config-if)# ^Z
Router# ^C^C^C
MSFC Configuration Synchronization Overview

MSFC high availability allows for automatic synchronization of the startup configuration and running configuration between the designated MSFC (the MSFC to come online first or the MSFC that has been online the longest) and the nondesignated MSFC. High-availability redundancy is disabled by default.

Caution Configuration synchronization is only supported for the IP and IPX configurations. Before enabling synchronization, you must ensure that both MSFCs have identical configurations for all protocols. If you are using AppleTalk, DECnet, VINES, or any other routing, you must manually ensure that identical configurations are on both MSFCs for all protocols.

To determine the status of the designated MSFC, enter the show fm features or the show redundancy command:
Router-15# show redundancy
Designated Router: 1 Non-designated Router:2
Redundancy Status: non-designated
Config Sync AdminStatus  : enabled
Config Sync RuntimeStatus: enabled
Router-16# show redundancy
Designated Router: 1 Non-designated Router:2
Redundancy Status: designated
Config Sync AdminStatus  : enabled
Config sync RuntimeStatus: enabled
High-availability redundancy provides the startup and running configuration synchronization.

When you enable high-availability redundancy, the startup configuration of both MSFCs is updated when you enter either of these commands on the designated MSFC:

•write mem

•copy source startup-config

When you enable high-availability redundancy, every configuration command that is executed on the designated MSFC is sent to the nondesignated MSFC. In addition, the running configuration synchronization is updated when you enter the copy source running-config command on the designated MSFC.

These sections provide information about the MSFC configuration synchronization:

•Configuration Synchronization States

•alt Keyword Usage

Configuration Synchronization States

The two states for the configuration synchronization are as follows:

•Config Sync AdminStatus—Signifies what the user has configured for this feature at that moment

•Config Sync RuntimeStatus—Enabled only when the following occurs:

–The Config Sync AdminStatus is enabled on both the designated and nondesignated MSFCs

–The designated and nondesignated MSFCs are running compatible images

When you enable the Config Sync RuntimeStatus, the following occurs:

•No configuration mode is available on the CLI of the nondesignated MSFC; EXEC mode is available

•The alt keyword is available and required (see the "alt Keyword Usage" section for more information on the alt keyword)

•The running and startup configurations are synchronized

When the Config Sync RuntimeStatus is in disabled mode, the following occurs:

•Configuration mode is available on the CLI of both MSFCs

•The alt keyword is available but optional

•The running and startup configurations are not synchronized

The various configuration and operation cases are covered in the "High-Availability Redundancy Configuration Examples" section.

alt Keyword Usage

When you enable the Config Sync RuntimeStatus, the configuration mode on the nondesignated MSFC is disabled; only the EXEC mode is still available. The configuration of both MSFCs is made through the console or a Telnet session on the designated MSFC.

To configure both MSFCs from a single console, enter the alt keyword to specify an alternate configuration. When specifying the alternate configuration, the configuration that is specified before the alt keyword relates to the MSFC on the supervisor engine in slot 1 of the switch; the configuration that is specified after the alt keyword relates to the MSFC on the supervisor engine in slot 2.

Note You must enter the alt keyword when you enable Config Sync AdminStatus.

Table 23-3 shows the interface and global configuration commands that contain the alt keyword.

Table 23-3 Interface and Global Configuration Commands Containing the alt Keyword

Interface Configuration Commands

Global Configuration Commands

•[no] standby [group_number] ip [ip_address [secondary]] alt [no] standby [group_number] ip [ip_address [secondary]]

•[no] standby [group_number] priority priority [preempt [delay delay]] alt [no] standby [group_number] priority priority [preempt [delay delay]]

•[no] ip address ip_address mask [secondary] alt [no] ip address ip_address mask [secondary]

•[no] ipx network network [encapsulation encapsulation_type [secondary]] [alt [no] ipx network network [encapsulation encapsulation_type [secondary]]]

•[no] hostname hostname alt hostname hostname

•[no] ip default-gateway ip_address alt [no] ip default-gateway ip_address

•router bgp autonomous_system
bgp router-id ip_address [alt ip_address]

•router ospf process_id
router-id ip_address [alt ip_address]

This example shows how to use the alt keyword when entering the ip address command:
Router-1(config-if)# ip address 1.2.3.4 255.255.255.0 alt ip address 1.2.3.5 255.255.255.0
Enabling or Disabling Configuration Synchronization

To enable high-availability redundancy, perform this task in privileged mode:

Task

Command

Step 1

Enable redundancy.

redundancy

Step 2

Enable high availability.

high-availability

Step 3

Enable or disable configuration synchronization.

[no] config-sync

This example shows how to enable high-availability redundancy and configuration synchronization (Router-15 is the designated MSFC):
Console>(enable) session 15
Trying Router-15...
Connected to Router-15.
Escape character is '^]'.
Router-15> enable
Router-15# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router-15(config)# redundancy 
Router-15(config-r)# high-availability 
Router-15(config-r-ha)# config-sync 
Router-15(config-r-ha)# end
Note When you enable high-availability redundancy, the configuration mode is disabled on the nondesignated MSFC; only EXEC mode is available.

In this example, Router-16 is the nondesignated MSFC; high-availability redundancy and configuration synchronization are enabled:
Console>(enable) session 16
Trying Router-16...
Connected to Router-16.
Escape character is '^]'.
Router-16> enable
Router-16# configure terminal
Config mode is disabled on non-designated Router, please configure from designated Router
High-Availability Redundancy Configuration Examples

This section describes the different scenarios for enabling high availability and configuration synchronization:

•Scenario 1: Enabling Configuration Synchronization on Both MSFCs

•Scenario 2: Disabling Configuration Synchronization on the Designated MSFC

•Scenario 3: Designated MSFC Comes Up

•Scenario 4: Nondesignated MSFC Comes Up

•Scenario 5: Designated MSFC Goes Down

Scenario 1: Enabling Configuration Synchronization on Both MSFCs

This scenario assumes that both MSFCs are up.

When you enable the configuration synchronization on both MSFCs, the IP addresses on all the interfaces are checked first. If an IP address is specified for the designated MSFC but is not specified for the nondesignated MSFC, a message is displayed indicating the first interface for which the alternate IP address was not specified.

After checking the IP addresses, the HSRP addresses are checked. If an HSRP address is specified for the designated MSFC but not specified for the nondesignated MSFC, a message is displayed indicating the first interface for which the alternate HSRP (standby) address was not specified.

After checking the HSRP addresses, the IPX network address is checked.

The designated MSFC is configured first. This example shows a missing alternate configuration for the VLAN 1 interface:
Router-16# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router-16(config)# redundancy
Router-16(config-r)# high-availability
Router-16(config-r-ha)# config-sync
Alternate IP address missing for Vlan1
The alternate configuration is missing. The auto-config sync can not be enabled
Note When specifying the alternate IP configuration, the configuration that is specified before the alt keyword relates to the MSFC on the supervisor engine in slot 1 of the switch; the configuration that is specified after the alt keyword relates to the MSFC on the supervisor engine in slot 2. See the "alt Keyword Usage" section for more information.

This example shows how to specify the alternate configuration for VLAN 1:
Router-16(config)# interface vlan 1
Router-16(config-if)# ip address 70.0.70.4 255.255.0.0 alt ip address 70.0.70.5 
255.255.0.0
Router-16(config-if)# exit
This example shows that high-availability redundancy is accepted:
Router-16(config)# redundancy 
Router-16(config-r)# high-availability 
Router-16(config-r-ha)# config-sync 
Router-16(config-r-ha)# end
Router-16#
00:03:31: %SYS-5-CONFIG_I: Configured from console by console
Because the Config Sync AdminStatus on the nondesignated MSFC is disabled, the Config Sync RuntimeStatus on the designated MSFC will remain in disabled mode. The following message is displayed on the designated MSFC:
00:17:05: %RUNCFGSYNC-6-SYNCEVENT: 
Non-Designated Router is now online 
High-Availability Redundancy Feature is not enabled on the Non-Designated Router
This example shows how to enable the configuration synchronization feature on the nondesignated MSFC:
Router-151(config)# redundancy 
Router-15(config-r)# high-availability 
Router-15(config-r-ha)# config-sync 
Router-15(config-r-ha)# end
Router-15# 
00:03:31: %SYS-5-CONFIG_I: Configured from console by console
Note When you enable high-availability redundancy, the configuration mode is disabled on the console of the nondesignated MSFC; only EXEC mode is available.

This message, which acknowledges that the high-availability redundancy is enabled and that the configuration mode is automatically exited, is displayed on the nondesignated MSFC:
00:18:57: %RUNCFGSYNC-6-SYNCEVENT: 
The High-Availability Redundancy Feature is enabled 
The config mode is no longer accessible
Router-15#
00:19:41: %RUNCFGSYNC-6-SYNCEVENT: 
Non-Designated Router is now online 
Running Configuration Synchronization will begin in 1 minute
A 1-minute timer will start, allowing for the nondesignated MSFC to stabilize. When the timer expires, a snapshot of the current running configuration is sent to the nondesignated MSFC. This message is displayed before the running configuration is synchronized:
00:20:41: %RUNCFGSYNC-6-SYNCEVENT: 
Syncing Running Configuration to the Non-Designated Router
00:20:41: %RUNCFGSYNC-6-SYNCEVENT: 
Syncing Startup Configuration to the Non-Designated Router
These examples show that the designated MSFC and nondesignated MSFC have the same running configuration after synchronization:
<designated MSFC>
Router-16# show running-config
Building configuration...
Current configuration:
!
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Router-15 alt hostname Router-16
!
boot bootldr bootflash:c6msfc-boot-mz.120-7.XE1
!
ip subnet-zero
!
ip cef
redundancy
 high-availability
 config-sync
cns event-service server
!
!
!
interface Vlan1
 ip address 70.0.70.4 255.255.0.0 alt ip address 70.0.70.5 255.255.0.0
!
interface Vlan10
ip address 192.10.10.1 255.255.255.0 alt ip address 192.10.10.2 255.255.255.0
 no ip redirects
 shutdown
 standby ip 192.20.20.1 alt standby ip 192.20.20.1
!
ip classless
ip route 223.255.254.0 255.255.255.0 70.0.100.0
no ip http server
!
!
!
line con 0
 transport input none
line vty 0 4
 login
 transport input lat pad mop telnet rlogin udptn nasi
!
end
<nondesignated MSFC>
Router-15# show running-config
Building configuration...
Current configuration:
!
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Router1 alt hostname Router2
!
boot bootldr bootflash:c6msfc-boot-mz.120-7.XE1
!
ip subnet-zero
!
ip cef
redundancy
 high-availability
 config-sync
cns event-service server
!
!
!
interface Vlan1
 ip address 70.0.70.4 255.255.0.0 alt ip address 70.0.70.5 255.255.0.0
!
interface Vlan10
ip address 192.10.10.1 255.255.255.0 alt ip address 192.10.10.2 255.255.255.0
 no ip redirects
 shutdown
 standby ip 192.20.20.1 alt standby ip 192.20.20.1
!
ip classless
ip route 223.255.254.0 255.255.255.0 70.0.100.0
no ip http server
!
!
!
line con 0
 transport input none
line vty 0 4
 login
 transport input lat pad mop telnet rlogin udptn nasi
!
end
Scenario 2: Disabling Configuration Synchronization on the Designated MSFC

In this scenario, the configuration synchronization is enabled. These examples show how to disable the configuration synchronization:
Router-16# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)# redundancy 
Router2(config-r)# high-availability 
Router2(config-r-ha)# no config-sync 
When the configuration synchronization is disabled, the following message is displayed on the nondesignated MSFC:
00:13:00: %RUNCFGSYNC-6-SYNCEVENT: 
The High-Availability Redundancy Feature is now disabled 
The config mode is now accessible
Configuration mode is available on the CLI of the designated and nondesignated MSFC.

Scenario 3: Designated MSFC Comes Up

In this scenario, Config Sync AdminStatus is enabled. The designated MSFC validates the alternate configuration, allowing the configuration synchronization to occur when the nondesignated MSFC comes up.

Because the nondesignated MSFC is not up yet, Config Sync RuntimeStatus is disabled, and there is no configuration synchronization. See the "Scenario 4: Nondesignated MSFC Comes Up" section for information on the nondesignated MSFC.

This example shows that Router-16 is the designated MSFC, Config Sync AdminStatus is enabled, and Config Sync RuntimeStatus is disabled:
Router-16# show redundancy
Designated Router: 1 Non-designated Router:0
Redundancy Status: designated
Config Sync AdminStatus  : enabled
Config Sync RuntimeStatus: disabled
Scenario 4: Nondesignated MSFC Comes Up

Config Sync AdminStatus is Enabled

In this scenario, the nondesignated MSFC notifies the designated MSFC that it is up and Config Sync AdminStatus is enabled. The designated MSFC requests the nondesignated MSFC to enable Config Sync RuntimeStatus. The nondesignated MSFC enables Config Sync RuntimeStatus.

This message is displayed on the nondesignated MSFC:
00:00:07: %RUNCFGSYNC-6-SYNCEVENT: 
The High-Availability Redundancy Feature is enabled 
The config mode is no longer accessible
00:00:51: %RUNCFGSYNC-6-SYNCEVENT: 
Non-Designated Router is now online 
Running Configuration Synchronization will begin in 1 minute
A 1-minute timer will start, allowing the nondesignated MSFC to stabilize. When the timer expires, a snapshot of the current running configuration is sent to the nondesignated MSFC. This message is displayed before synchronizing the running configuration:
00:01:51: %RUNCFGSYNC-6-SYNCEVENT: 
Syncing Running Configuration to the Non-Designated Router
Config Sync AdminStatus is Disabled

In this scenario, the nondesignated MSFC notifies the designated MSFC that it is up. Because the Config Sync AdminStatus is disabled on the nondesignated MSFC, the designated MSFC displays the following message indicating that high-availability redundancy needs to be enabled on the nondesignated MSFC:
Router-16# 
Non-Designated Router came up.
High-Availability Redundancy Feature is not enabled on the Non-Designated Router
This example shows how to enable the high-redundancy availability on the nondesignated MSFC:
Router-15# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router-15(config)# redundancy 
Router-15(config-r)# high-availability 
Router-15(config-r-ha)# config-sync 
Router-15(config-r-ha)# 
00:03:47: %SYS-5-CONFIG_I: Configured from console by console
00:03:47: %RUNCFGSYNC-6-SYNCEVENT: 
The High-Availability Redundancy Feature is enabled 
The config mode is no longer accessible
00:00:51: %RUNCFGSYNC-6-SYNCEVENT: 
Non-Designated Router is now online 
Running Configuration Synchronization will begin in 1 minute
A 1-minute timer will start, allowing the nondesignated MSFC to stabilize. When the timer expires, a snapshot of the current running configuration is sent to the nondesignated MSFC. This message is displayed before synchronizing the running configuration:
00:01:51: %RUNCFGSYNC-6-SYNCEVENT: 
Syncing Running Configuration to the Non-Designated Router
These examples show that Config Sync AdminStatus and RuntimeStatus are enabled on the designated and nondesignated MSFCs:
Router-15# show redundancy
Designated Router: 1 Non-designated Router:2
Redundancy Status: non-designated
Config Sync AdminStatus  : enabled
Config Sync RuntimeStatus: enabled
Router-16# show redundancy
Designated Router: 1 Non-designated Router:2
Redundancy Status: designated
Config Sync AdminStatus  : enabled
Config sync RuntimeStatus: enabled
Scenario 5: Designated MSFC Goes Down

In this scenario, the nondesignated MSFC becomes the designated MSFC, the configuration synchronization is disabled, and the configuration mode on the CLI is now available.

When the previously designated MSFC comes back up, it becomes the nondesignated MSFC; see the "Scenario 4: Nondesignated MSFC Comes Up" section.

Single Router Mode Redundancy

These sections describe how to configure single router mode (SRM) redundancy:

•Hardware and Software Requirements

•SRM Redundancy Configuration Guidelines

•Configuring Single Router Mode Redundancy on Supervisor Engine 720

•Configuring Single Router Mode Redundancy on Supervisor Engine 1 or Supervisor Engine 2

•Upgrading Images with Single Router Mode Enabled

•Getting Out of Single Router Mode

SRM redundancy is an alternative to the internally redundant (dual) MSFC2 configurations where both MSFC2s are active at the same time. In SRM redundancy, only the designated router is visible to the network at any given time. The nondesignated router is booted up completely and participates in the configuration synchronization which is automatically enabled when entering SRM. All configuration following the "alt" keyword is ignored in SRM; the nondesignated router's configuration is exactly the same as the designated router but its interfaces are kept in a line down state and are not visible to the network. The processes, such as the routing protocols, are created on the nondesignated router and the designated router, but all the nondesignated router interfaces are in a line down state; they do not send or receive updates from the network.

When the designated router fails, the nondesignated router changes its state from a nondesignated router to a designated router and its interface state changes to link up. The newly designated router builds up its routing table while the existing supervisor engine switch processor entries are used to forward the Layer 3 traffic. The switch processor continues to forward the Layer 3 packets using the old entries. After a predefined time, the newly designated router downloads the new Layer 3 switching information to the switch processor.

Note With Cisco IOS Release 12.1(11b)E and later releases, you can specify the transition time that the newly designated router waits before downloading the new Layer 3 switching information to the supervisor engine switch processor. For configuration details, see the "Specifying the Transition Time on the Newly Designated Active Router" section.

Hardware and Software Requirements

To configure SRM redundancy, you must have the following hardware and software:

•A single chassis with two identical supervisor engine daughter card configurations:

–Supervisor Engine 32 with Policy Feature Card 3B/3BXL (PFC3B/PFC3BXL) and MSFC2A

–Supervisor Engine 720 with PFC3A/PFC3B/PFC3BXL and MSFC3

–Supervisor Engine 2 with PFC2 and MSFC2

–Supervisor Engine 1 with PFC and MSFC or MSFC2

Note Cisco IOS Release 12.1(8a)E4 provides initial support for SRM redundancy with Supervisor Engine 1 and the MSFC.

Note Multicast support: In software releases prior to software release 7.1(1), when using Supervisor Engine 1 with the MSFC or MSFC2 for SRM redundancy, be aware that failover to the second MSFC is not stateful for multicast MLS. When the primary MSFC fails, all the multicast MLS entries are removed and are then recreated and reinstalled in the hardware by the newly active MSFC.

Note Multicast support: In software release 7.1(1) and later releases, there is improved SRM redundancy support for multicast traffic for Supervisor Engine 1 with PFC and MSFC2 and Supervisor Engine 2 with PFC2 and MSFC2. The multicast improvements are not supported on Supervisor Engine 1 with the MSFC.

When SRM redundancy is enabled, there are improved convergence times and less disruption of multicast traffic during the switchovers. The MSFC2 is protected from being overloaded with the multicast traffic during the switchover. The switch caches the flows from the MSFC2 that went down and uses the cached flows to forward traffic until the newly activated MSFC2 learns the routes. Only a few flows at a time are provided to the MSFC2 to prevent it from being overwhelmed.

•Supervisor engine software release 6.3(1) or later releases (Supervisor Engine 720 requires supervisor engine software release 8.1(1) or later releases and Supervisor Engine 32 requires supervisor engine software release 8.4(1) or later releases)

•Cisco IOS Release 12.1(8a)E2 or later releases (Supervisor Engine 720 MSFC3 requires Cisco IOS Release 12.2(14)SX2 or later releases)

SRM Redundancy Configuration Guidelines

This section describes the guidelines for configuring SRM redundancy:

•Both the designated router and nondesignated router must run the same Cisco IOS image.

•A Cisco IOS image must be present in the bootflash of both the designated router and nondesignated router.

•The nondesignated router cannot connect to the external networks.

•Do not boot from an external network with the designated router because booting from the network could severely degrade the SRM functionality.

•With SRM redundancy, the designated router can reach the external networks and copy commands, such as copy tftp:, can be used without any restrictions.

•You must enable high availability on the supervisor engine.

•When using the authentication methods to control access to the switch, such as RADIUS or TACACS+, you must configure a fallback option to log in with a local username and password if you want to access the nondesignated router through the switch console or session commands.

See Chapter 39, "Configuring the Switch Access Using AAA" for information on configuring the fallback option.

Configuring Single Router Mode Redundancy on Supervisor Engine 720

Note Single router mode redundancy is the only supported MSFC redundancy option for Supervisor Engine 720 and Supervisor Engine 32.

With Supervisor Engine 720 and Supervisor Engine 32, you do not have to explicitly enable SRM on the MSFC; SRM is enabled by default. To ensure that SRM works properly, you must verify that both MSFCs have the identical startup configuration with one of these two methods:

1. After the system is reset and has reloaded, enter the write erase command on the nondesignated MSFC and reload the nondesignated MSFC.

2. After the system is reset and has reloaded, enter the show redundancy command to verify that the SRM run-time status is enabled. After verifying that the SRM run-time status is enabled, enter the write memory command on the designated MSFC and reload the nondesignated MSFC (do not save the configuration on the nondesignated MSFC at the reload prompt).

Tip We recommend that you use the second method where the nondesignated MSFC starts with the same configuration as the designated MSFC. This method lessens the chance of encountering any unforeseen problems.

Note If the nondesignated MSFC startup configuration had configuration items that were not present in the designated MSFC configuration during the system boot, the MSFCs will be inconsistent with their run-time configuration state. Both procedures ensure that the nondesignated MSFC always has the same run-time configuration as the designated MSFC.

Configuring Single Router Mode Redundancy on Supervisor Engine 1 or Supervisor Engine 2

To configure SRM redundancy, perform these steps:

Caution Before going from dual router mode to SRM redundancy, we recommend that you use the copy running-config command on the MSFCs to save the non-SRM configuration to bootflash. When going to SRM redundancy, the alternative configuration (the configuration following the alt keyword) is lost. Before enabling SRM redundancy, save the dual router mode configuration to bootflash by entering the copy running-config bootflash:nosrm_dual_router_config command on both MSFCs.

See the "Getting Out of Single Router Mode" section for additional information.

Note This procedure assumes that the designated router is the MSFC2 in slot 1 and the nondesignated router is the MSFC2 in slot 2; the active supervisor engine is in slot 1 and the standby supervisor engine is in slot 2.

Step 1 Enter the show version command to ensure that both supervisor engines are running supervisor engine software release 6.3(1) or later releases.

Step 2 Enter the set system highavailability enable command to enable high availability on the active supervisor engine. Enter the show system highavailability command to verify that high availability is enabled.

Step 3 If you have a console connection, enter the switch console command to access the designated router. If connected through a Telnet session, enter the session mod command to access the designated router.

Step 4 Copy the Cisco IOS Release 12.1(8a)E2 or later image to the bootflash of the designated router and nondesignated router.

Step 5 Set the boot image and configuration register on the designated router and nondesignated router to boot the new image on a reload.

For the designated router, enter the boot system flash bootflash:image_name command and ensure that this image is the first image in the boot list. Clear any existing boot system commands that appear in the running configuration (show running-config) using the no form of the boot system command.

For the nondesignated router, set the configuration register to auto boot by entering the
config-register 0x102 command.

Note If you already have SRM-capable Cisco IOS images loaded, you do not need to perform
Step 6.

Step 6 Enter the reload command to reload the designated router and nondesignated router.

Step 7 Disable the configuration synchronization (config-sync) on the designated router by entering the no form of the command. Enter the write memory command. This step lets you access the configuration mode on both the designated and nondesignated routers.

Step 8 Enable SRM on the designated router first, and then enable SRM on the nondesignated router as follows:
Router(config)# redundancy 
Router(config-r)# high-availability 
Router(config-r-ha)# single-router-mode 
Note With Cisco IOS Release 12.1(11b)E and later releases, you can specify the transition time that the newly designated router waits before downloading the new Layer 3 switching information to the supervisor engine switch processor. For configuration details, see the "Specifying the Transition Time on the Newly Designated Active Router" section.

Step 9 Enter the write memory command on the designated router to ensure that the nondesignated router's startup configuration has SRM enabled.

Step 10 Enter the show startup-config command on the nondesignated router to ensure that the nondesignated router has the following configuration statements:
redundancy
 high-availability
 single-router-mode 
Step 11 Enter the show redundancy command on the designated router and nondesignated router to ensure that both routers have the following configuration statement:
Single Router Mode RuntimeStatus: enabled
If not, repeat Steps 9 and 10 and allow sufficient time between steps.

Step 12 Enter the reload command to reload the nondesignated router. When asked whether the configuration should be saved, enter no.

This display summarizes the configuration commands that were used on the designated router and the nondesignated router to enable SRM redundancy:
Time   Designated Router                      Nondesignated Router
  ----   ---                                  ----
  t0:    conf t->red->hi->no config-sync
  t1:                                         conf t->red->hi->no config-sync
  t2:    conf t->red->hi->single-router-mode
  t3:                                         conf t->red->hi->single-router-m
  t4:    write mem
  t5:                                         reload
Specifying the Transition Time on the Newly Designated Active Router

With Cisco IOS releases prior to Release 12.1(11b)E, the transition time was 120 seconds and was not configurable. Because of the differences in the routing convergence times, 120 seconds might not be long enough. The older Layer 3 switching entries might be erased, and the newly downloaded Layer 3 switching information might be incomplete.

With Cisco IOS Release 12.1(11b)E and later releases, you can specify the transition time that the newly designated router waits before downloading the new Layer 3 switching information to the switch processor. On a switchover, the old Layer 3 switching information is used for a configurable number of seconds before the new Layer 3 switching information is downloaded to the switch processor.

If nonstop forwarding is required, we do not recommend setting the transition time to a value that is lower than the default (120 seconds). At a minimum, it takes 30 to 60 seconds for routes to converge.

To specify the transition time, enter these commands (in this example, the transition time is set to 240 seconds):
Router(config)# redundancy 
Router(config-r)# high-availability 
Router(config-r-ha)# single-router-mode 
Router(config-r-ha)# single-router-mode failover ?
   table-update-delay  Adjust for routing convergence time
Router(config-r-ha)# single-router-mode failover table-update-delay ?
   <0-4294967295>  Delay in seconds between switch over detection and h/w FIB reload
Router(config-r-ha)# single-router-mode failover table-update-delay 240
Router(config-r-ha)#
To set the transition time to the 2-minute default, use the no form of the command as follows:
Router(config-r-ha)# no single-router-mode failover table-update-delay
Display the transition time as follows:
Router-16# show redundancy 
 Designated Router: 2 Non-designated Router: 1
 Redundancy Status: designated
 Config Sync AdminStatus  : enabled
 Config Sync RuntimeStatus: enabled
 Single Router Mode AdminStatus  : enabled
 Single Router Mode RuntimeStatus: enabled
 Single Router Mode transition timer : 240 seconds    <---- transition time
Router-16#
Upgrading Images with Single Router Mode Enabled

This section describes how to upgrade the Cisco IOS image on the active and standby MSFC when SRM is running. The new image name is c6msfc2-jsv-mz.9E. The standby MSFC cannot load an image using TFTP, but it can load an image from the supervisor engine Flash PC card (sup-slot0:).

Note This procedure impacts the data traffic. We recommend that you perform this procedure during a scheduled maintenance window.

To upgrade the images, perform these steps:

Step 1 On the active supervisor engine, enter the copy tftp sup-slot0: command and follow the prompts to load the new (c6msfc2-jsv-mz.9E) image onto the supervisor engine Flash PC card.

Step 2 If you have a console connection, enter the switch console command to access the active MSFC. If you are connected through a Telnet session, enter the session mod command to access the active MSFC.

Step 3 On the active MSFC, copy the new image from the supervisor engine Flash PC card to the MSFC bootflash as follows:
copy sup-slot0:c6msfc2-jsv-mz.9E bootflash:c6msfc2-jsv-mz.9E
Step 4 Access the standby MSFC by entering the switch supervisor command and then the switch console command on the active supervisor engine.

Note The standby MSFC does not appear in the show module command display that is issued from the active supervisor engine.

Step 5 On the standby MSFC, copy the new image from the supervisor engine Flash PC card to the MSFC bootflash as follows:
copy sup-slot0:c6msfc2-jsv-mz.9E bootflash:c6msfc2-jsv-mz.9E
Step 6 On the active MSFC, specify that the new image is booted when the MSFC is reloaded as follows:
boot system flash bootflash:c6msfc2-jsv-mz.9E
Step 7 On the active MSFC, enter the write memory command to ensure that the standby MSFC startup configuration gets the boot information.

Step 8 Enter the reload command to reload the standby MSFC.

Step 9 Enter the show redundancy command on the active and standby MSFCs to ensure that both have the following configuration statement:
Single Router Mode RuntimeStatus: enabled
Step 10 Enter the reload command to reload the active MSFC.

Both MSFCs are now running the c6msfc2-jsv-mz.9E image.

Getting Out of Single Router Mode

Note If you saved a copy of the running configuration that was used in dual router mode before configuring SRM redundancy, you do not need to use the procedure in this section. To get out of SRM redundancy and back to dual router mode, enter the copy bootflash:nosrm_dual_router_config startup-config command on both MSFCs. After the configurations are copied, reload the MSFCs using the reload command.

To get out of SRM, perform these steps:

Step 1 On the designated router, disable SRM by entering the no form of the command as follows:
Router(config)# redundancy 
Router(config-r)# high-availability 
Router(config-r-ha)# no single-router-mode 
Step 2 Enter the write memory command on the designated router and nondesignated router.

Step 3 Enter the show startup-config command on the designated and nondesignated routers to ensure that "single-router mode" is not in the startup configuration.

Step 4 Enter the reload command to reload the designated router and nondesignated router.

SRM is now disabled on the designated router and nondesignated router.

Manual-Mode MSFC Redundancy

Note Manual-mode MSFC redundancy will be supported until December 2002 due to the release of supervisor engine software release 6.3(1), which contains the feature SRM. We recommend that you use SRM rather than manual-mode MSFC redundancy to attain the automatic Layer-3 failover capabilities in addition to unlimited support of the feature.

These sections describe how to configure the redundant MSFCs with one MSFC active and the other MSFC in ROM-monitor mode:

•Hardware and Software Requirements

•Manual-Mode MSFC Redundancy Guidelines

•Accessing the Standby MSFC

•Manually Booting the MSFC

•Setting the MSFC Configuration Register

•MSFC Recovery Procedures

Hardware and Software Requirements

To configure Layer 3 redundancy, you must have at least one of the following configurations:

•A single chassis with two identical supervisor engine daughter card configurations:

–Supervisor Engine 1 with Policy Feature Card (PFC) and MSFC or MSFC2 (both supervisor engines must have the same type of MSFC)

–Supervisor Engine 2 with PFC2 and MSFC2

•Two chassis with a supervisor engine in each—You must have at least one supervisor engine in each chassis. Each supervisor engine must be equipped with a PFC and an MSFC.

•Manual-mode MSFC redundancy requires the following software:

–Supervisor engine software release 6.1(3) or later releases and Cisco IOS Release 12.1(7)E or later releases

–Supervisor engine software release 5.5.8 or later releases and Cisco IOS Release 12.1(7a)E1 or later releases

Note Each MSFC must run the same release of Cisco IOS software.

Manual-Mode MSFC Redundancy Guidelines

This section describes the guidelines for configuring the manual-mode MSFC redundancy:

•Because the MSFC switchover is manual, we recommend that you have this feature only in environments where the externally redundant routers are present and where either HSRP is used or some form of gateway discovery is implemented on the hosts.

•Ensure that the configuration register on the active MSFC (MSFC-15) is set to 0x2102 and that the configuration register on the MSFC in ROM-monitor mode (MSFC-16) is set to 0x0. This setting prevents both MSFCs from becoming active at the same time and allows the active MSFC to come online after a reset. See the "Setting the MSFC Configuration Register" section for details on setting the configuration register.

Note Setting both MSFCs to 0x0 is a supported option but requires user intervention if the switch is reset.

•To conserve the IP address space and reduce the overall Layer 3 complexity, ensure that configuration synchronization is disabled on both MSFCs and that all "alt" addresses are removed. If the alt addresses are used, the IP address space is not conserved and in cases where link-level peering is present (such as BGP), the Layer 3 complexity is increased.

•When the MSFC in ROM-monitor mode is brought up during a maintenance window, ensure that it has the exact configuration as the active MSFC. Follow the configuration guidelines in Table 23-2.

•During manual-mode MSFC redundancy, you should enable high availability on the supervisor engine to keep the Layer 2 downtime to a minimum when doing an MSFC switchover. Since high availability is not compatible with protocol filtering, port security, Dynamic VLAN (DVLAN), or Generic Attribute Registration Protocol (GARP) VLAN Registration Protocol (GVRP), we recommend that you disable these features when using manual-mode MSFC redundancy.

•Ensure that the console port on both supervisor engines is accessible to the operations personnel (out-of-band access through the terminal server or modem).

Note The procedures in this section use the switch console command to access the MSFC from the supervisor engine. The switch console command is not supported on Telnet sessions.

Accessing the Standby MSFC

To access the standby MSFC, enter the switch supervisor command and then the switch console command.

Note The standby MSFC does not appear in the show module command display that is issued from the active supervisor engine.

Manually Booting the MSFC

If the configuration register on both MSFCs is set to 0x0, then MSFC manual mode requires that you manually boot the MSFC each time that the switch is reset. To boot the MSFC manually, perform these steps:

Step 1 Enter the switch console command to gain access to the MSFC ROMMON prompt.

Step 2 Enter the boot bootflash:image command.

Step 3 Once the MSFC boots, press Ctrl-C three times at the Router> prompt to return to the supervisor engine prompt. Enter the session command to access the MSFC.

Setting the MSFC Configuration Register

For manual-mode MSFC redundancy, set the configuration registers as follows:

Step 1 From Cisco IOS configuration mode on the active MSFC (MSFC-15), enter the config-register 0x2102 command.

Step 2 On the MSFC in ROM-monitor mode (MSFC-16), enter the config-register 0x0 command.

Note We recommend that boot system commands in both MSFC configurations point to a valid image on bootflash and that you do not set the configuration registers to ignore these boot commands.

MSFC Recovery Procedures

This section describes how to recover from the temporary or permanent MSFC failures.

A temporary failure of the active MSFC results in an MSFC reboot because the configuration register is set to 0x2102.

You need to verify a suspected permanent failure of the active MSFC. Enter the reset 15 command from the active supervisor engine's console port and see if the active MSFC reboots without problems. If it does not, you have these two options to switch over to the standby MSFC:

Option 1: If You Have Physical Access to the Switch

If you have physical access to the switch, use this option. You can remove the active supervisor engine with the problematic MSFC, so that the redundant supervisor engine will take over. From the redundant supervisor engine's physical console port, perform these steps:

Step 1 Enter the switch console command.

Step 2 From the ROMMON prompt, enter the boot bootflash:image command.

Step 3 After the standby MSFC has booted, enter the config-register 0x2102 command from Cisco IOS configuration mode, to ensure that the MSFC will boot when the switch is reset.

Option 2: If You Have Only Remote Access to the Switch

If you have only remote access to the switch, use this option. From the active supervisor engine with the problematic MSFC, perform these steps:

Note If the problematic MSFC is on the standby supervisor engine, enter the switch supervisor command.

Step 1 Enter the switch console command.

Step 2 Send a Break signal to get into the problematic MSFC's ROMMON (the break will work if the MSFC is continually rebooting). You need to time the break so that it is issued after the system bootstrap message, but before the main Cisco IOS image is decompressed (see the two arrows in the following display output):
System Bootstrap, Version 12.0(3)XE, RELEASE SOFTWARE 
Copyright (c) 1998 by cisco Systems, Inc.
Cat6k-MSFC platform with 131072 Kbytes of main memory <======= ISSUE BREAK AFTER THIS 
POINT
Self decompressing the image : 
###################################################################################### 
[OK]  
<==========BUT BEFORE THIS POINT
Self decompressing the image : 
##########################################################################################
##########################################################################################
##########################################################################################
##########################################################################################
##########################################################################################
##########################################################################################
##########################################################################################
##########################################################################################
### [OK]
Step 3 At the ROMMON prompt, enter the confreg command:

a. Enter y at the "do you wish to change the configuration? y/n [n]:" prompt.

b. Press Enter to accept the default for all questions until you reach this prompt: "change the boot characteristics? y/n [n]:"

c. Enter y.

d. Enter 0 to select the "0 = ROM Monitor" option at the next prompt.

e. Review the Configuration Summary to ensure the following value: boot: the ROM Monitor.

f. You are again prompted with: "do you wish to change the configuration? y/n [n]:"

g. Enter n.

h. You are returned to the ROMMON prompt.

Step 4 Enter the reset command and verify that the MSFC boots into ROMMON. This step ensures that this MSFC and the active MSFC will not boot concurrently.

Step 5 Press Ctrl-C three times to return to the supervisor engine prompt.

Step 6 Ensure that high availability has synchronized the supervisor engine state by entering the show system highavailability command and verifying that high availability "Operational-status" is ON.

Step 7 Enter the switch supervisor command.

Step 8 Enter the switch console command.

Step 9 From the standby MSFC's ROMMON prompt, repeat Step 3 but in Step 3d, select option 2 "boot system" as follows:
change the boot characteristics? y/n  [n]:  y
enter to boot:
 0 = ROM Monitor
 1 = the boot helper image
 2-15 = boot system
    [2]:  2   <========================
    Configuration Summary
enabled are:
load rom after netboot fails
console baud: 9600
boot: the ROM Monitor
do you wish to change the configuration? y/n  [n]:  n
You must reset or power cycle for new config to take effect
rommon 2 >
Step 10 Enter the reset command at the ROMMON prompt to boot the system.

Step 11 Once the MSFC has booted, enter the config-register 0x2102 command from Cisco IOS configuration mode on the newly active MSFC's console port.

Step 12 Press Ctrl-C three times to return to the supervisor engine prompt.