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 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/univercd/cc/td/doc/product/lan/cat6000/122sx/swcg/nsfsso.htm.

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;

–