cc/td/doc/product/lan/cat6000/sw_5_3
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Configuring Redundant Supervisor Engines

Configuring Redundant Supervisor Engines

This chapter describes how to use and configure redundant supervisor engines. The second supervisor engine takes over if the active supervisor engine fails.

Note For complete information on redundant operation with the Multilayer Switch Feature Card (MSFC), refer to the Catalyst 6000 Family Multilayer Switch Feature Card and Policy Feature Card Configuration Guide.
Note For complete information on installing redundant Catalyst 6000 or 6500 series switch supervisor engines, refer to the Catalyst 6000 Family Module Installation Guide.
Note For complete syntax and usage information for the commands used in this chapter, refer to the Catalyst 6000 Family Command Reference publication.

This chapter consists of these sections:

Understanding How Supervisor Engine Redundancy Works

Note Redundant supervisor engines must be of the same type with the same model feature card.

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 Trunk Protocol (VTP) are processed on the active supervisor engine.

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

You must install redundant supervisor engines in slots 1 and 2 of the chassis. Redundant supervisor engines are hot swappable. The system continues to operate with the same configuration after switching over to the redundant supervisor engine. For more information, refer to the Catalyst 6000 Family Module Installation Guide.

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

At power-up, both supervisor engines run initial module-level diagnostics. Assuming both supervisor engines pass this level of diagnostics, the two supervisor engines communicate over the backplane, allowing them to cooperate during switching-bus diagnostics. The supervisor engine in slot 1 becomes active, and the supervisor engine in slot 2 enters standby mode. At this point, 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.

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 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 runtime image. The boot image filename is specified in the BOOT environment variable, which is stored in NVRAM. The runtime image is the boot image that the ROM monitor uses to boot the supervisor engine. After the system boots, the runtime image resides in dynamic RAM (DRAM).

When you power up or reset a switch with redundant supervisor engines, synchronization occurs to ensure that the runtime 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 runtime and boot images. If the boot image and the runtime 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 runtime 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 files 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 "Working With the Flash File System."

The supervisor engine has 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.

Note Throughout this publication, the term Flash PC card is used in place of the term PCMCIA card.

Since 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 in order to boot and synchronize properly. For information about how to specify the name and location of the boot image, see "Modifying the Switch Boot Configuration."

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

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

Synchronization Process Initiation

These conditions initiate the synchronization of the runtime and boot images on the active and standby supervisor engines:

Redundant Supervisor Engine Configuration Guidelines and Restrictions

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

When you download a new image to the active supervisor engine, it is copied to the file system (in boot Flash or on a Flash PC card in the Flash PC card slot). Since 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.
If the active supervisor engine is unable to find the current runtime image on any of the Flash devices, it signals an error condition. In this case, if the standby supervisor engine is inserted or reset, 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.
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 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 Standby Supervisor Engine Status

You can verify the status of the standby supervisor engine using a number of CLI commands.

Note The show module output provides information about installed daughter cards. The show test command provides information about 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_num]

  • Show the state of the standby supervisor engine uplink ports.

show port [mod_num[/port_num]]

  • Show diagnostic test results for the standby supervisor engine.

show test [mod_num]

These example shows how to check the status of the standby supervisor engine using 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 switch over 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_num is the number of the active supervisor engine).

reset mod_num

You can also switch 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:cat5000-sup3.4-3-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:cat5000-sup3.4-3-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>

Supervisor Engine Synchronization Examples

The following examples show what happens when the synchronization function encounters certain conditions. These examples are not intended to cover every possible condition.

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.

Synchronizing the Runtime Image with the Bootstring

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

Example 1: Runtime image not synchronized

The configuration for example 1 is as follows:

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

The configuration for example 2 is as follows:

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

The configuration for example 3 is as follows:

Example 4: Oldest bootflash file deleted, bootflash squeezed

The configuration for example 4 is as follows:

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:

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

The configuration for this example is as follows:

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

The configuration for this example is as follows:

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

The configuration for this example is as follows:


hometocprevnextglossaryfeedbacksearchhelp
Posted: Wed Nov 10 13:15:03 PST 1999
Copyright 1989-1999©Cisco Systems Inc.