|
|
This chapter describes how to use and configure redundant supervisor engines on the Catalyst 6000 family switches.
 |
Note For more information about 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 more information about installing redundant Catalyst 6000 family supervisor engines, refer to the Catalyst 6000 Family Module Installation Guide. |
|
Note For 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:
|
Note Redundant supervisor engines must be of the same type with the same model feature card. |
|
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.
These conditions initiate the synchronization of the runtime and boot images on the active and standby supervisor engines:
The following conditions and events can cause the synchronization of images between redundant supervisor engines to fail or to produce unexpected results:
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 module [mod_num] |
| show port [mod_num[/port_num]] |
| show test [mod_num] |
This 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)
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: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>
This section describes the high availability feature that is used to minimize the switchover time from the active supervisor engine to the standby supervisor engine if the active supervisor engine fails. The high availability feature ensures that there will be minimal disturbance to the steady-state operation of the network when the standby supervisor engine takes control of the system.
Prior to the high availability feature, the fast switchover feature was available to ensure that a switchover to the standby supervisor engine happened quickly. However, with fast switchover, all the switch features needed to be reinitialized and restarted when the standby supervisor engine assumed the active role because their state before the switchover was unknown.
The high availability feature removes this limitation; the active supervisor engine communicates with the standby, keeping feature protocol states synchronized. With the standby supervisor engine synchronized with the active supervisor engine, the standby can take over in the event of a failure and continue exactly where the failed supervisor engine left off.
The high availability feature also provides a versioning option that allows you to run different software images on the active and standby supervisor engines.
These features are discussed in detail in the following sections:
For high availability, a system database is maintained on the active supervisor engine and 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 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.
|
Note See Table 16-1 for a list of high availability-supported features. |
The active supervisor engine controls the system bus (backplane), sends and receives packets to and from the network, and controls all modules. 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 packets from the switching bus to learn and populate its Layer 2 forwarding table for
Layer 2-switched flows. The standby supervisor engine also receives packets from the switching bus to learn and populate the Multilayer Switching (MLS) table for Layer 3-switched flows. The standby supervisor engine does not participate in forwarding any packets and does not communicate with any modules.
|
Note Routing table entries in the active MSFC are not preserved because the high availability feature is not run on the MSFC IOS. However, you can configure both MSFCs on the active and standby supervisor engines with the same configuration and use Hot Standby Router Protocol (HSRP) to preserve routing table entries across the active and standby MSFCs. For detailed information on configuring the MSFC, refer to the Catalyst 6000 Family Multilayer Switch Feature Card and Policy Feature Card Configuration Guide publication. |
When you enable high availability, and the standby supervisor engine is running, 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 current synchronization data.
If you change high availability from disabled to enabled, synchronization from the active to standby supervisor engine is started (provided the standby supervisor engine is present and its image version is compatible).
NVRAM synchronization occurs irrespective of high availability being enabled or disabled (provided there are compatible NVRAM versions on the two supervisor engines).
|
Note See the "Versioning Overview" section for version compatibility details. |
If the standby supervisor engine is not installed during system bootup, the active supervisor engine detects this and the database updates are not queued for synching. 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, does the active supervisor engine queue and synchronize 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. |
|
Note MLS flows are preserved from the active supervisor engine to the standby supervisor engine. |
The Catalyst 6000 family switch features are classified into three categories with respect to high availability support (see Table 16-1):
|
Note Timers and statistics are not synchronized from the active to the standby supervisor engine. |
| Supported Features | Compatible Features | Incompatible Features |
|---|---|---|
COPS-DS | ASLB | Dynamic VLAN |
COPS-PR | CDP | GVRP |
DTP | GMRP | Port security |
EtherChannel | IGMP snooping | Protocol filtering |
IOS ACLs | RMON |
|
MLS | RSVP |
|
PAgP | SNMP |
|
QoS | Telnet sessions |
|
SPAN | VTP pruning |
|
STP |
|
|
Trunking |
|
|
UDLD |
|
|
VACLs |
|
|
VTP |
|
|
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, the high availability feature cannot be enabled.
Image versioning is supported in supervisor engine software releases 5.4(1)CSX and later. Image versioning is not supported with images prior to release 5.4(1)CSX. Therefore, with versioning enabled, the high availability feature is fully supported with the active and standby supervisor engines running different images as long as both images are release 5.4(1)CSX or later.
|
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. In a system with two supervisor engines installed, at power up 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, and versioning is not enabled, the active supervisor engine automatically downloads its software image and configuration to the standby supervisor engine. |
This section describes the CLI commands associated with high availability and versioning.
High availability is disabled by default. To enable or disable high availability, perform these tasks 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 enableSystem high availability enabled.Console> (enable)
This example shows how to disable high availability:
Console> (enable)set system highavailability disableSystem high availability disabled.Console> (enable)
High availability versioning is disabled by default. To enable or disable high availability versioning, perform these tasks 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 enableImage versioning enabled.Console> (enable)
This example shows how to disable high availability versioning:
Console> (enable)set system highavailability versioning disableImage versioning disabled.Console> (enable)
The show system highavailability command displays the following:
To show the high availability configuration and operational states, perform this task:
| Task | Command |
|---|---|
Show high availability configuration and operational states. | show system highavailability |
In this example, high availability and versioning are disabled:
Console> (enable) show system highavailability Highavailability: disabled Highavailability versioning: disabled Highavailability Operational-status: OFF (high-availability-not-enabled) Console> (enable)
In this example, high availability is enabled:
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)
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):
Console> (enable)set system highavailability enableSystem 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 ... display text truncated 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 ... display text truncated Console> (enable)
Step 4 Modify the BOOT environment variable so 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 ... display text truncated Console> (enable)
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. |
This section contains four examples in which the active supervisor engine runtime image is synchronized with the standby supervisor engine.
The configuration for example 1 is as follows:
bootflash:f1
bootflash:f1,1
f1
The configuration for example 2 is as follows:
bootflash:f1
bootflash:f1,1
f1
bootflash:f2
bootflash:f2,1
f2
The configuration for example 3 is as follows:
bootflash:f1
bootflash:f1,1
f1
bootflash:f2
bootflash:f2,1
f1,f2
The configuration for example 4 is as follows:
bootflash:f1
bootflash:f1,1
f1
bootflash:f2
bootflash:f2,1;
f2, f3, f4 (less than 1 MB left on device)
This section contains four examples in which the bootstrings on the active and standby supervisor engines are synchronized.
The configuration for this example is as follows:
bootflash:f1
bootflash:f1,1;
f1
bootflash:f1
bootflash:f1,1;
f1
The configuration for this example is as follows:
bootflash:f1
bootflash:f1,1;
f1,f2
bootflash:f1
bootflash:f1,1;
The configuration for this example is as follows:
bootflash:f1
bootflash:f1,1;
f1,f2
bootflash:f1
bootflash:f1,1;
f1,f2
The configuration for this example is as follows:
bootflash:f1
bootflash:f1,1;
f1,f2
bootflash:f1
bootflash:f1,1;
f0,f1,f3 (less than 1 MB left on device)
Posted: Sun Jun 11 02:21:13 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.