3-6. Redundant Supervisors When identical Supervisor hardware is placed in slots 1 and 2 of Catalyst 5500 and 6000 series switches, one Supervisor is active and the other is in standby mode. In the event of a failure, the redundant Supervisor takes over switch functionality. Configuration files and operating system files are synchronized between switches. Layer 2 tables are synchronized between the supervisors for quick transitions between modules. Parameters such as the Layer 2 synchronization and operating system synchronization can be managed for the modules. Layer 3 MSFC cards operate independently of the COS and must be managed manually or configured for redundancy in the MSFC IOS. See section "8-4: MSFC Redundancy with Single Router Mode" and "8-5: MSFC Redundancy with Configuration Synchronization" for more information. Catalyst 6000 series switches provide both Layer 2 and Layer 3 synchronization within the same operating system and configuration.
By placing identical Supervisor hardware and software in slots 1 and 2 of a Catalyst 5500 or Catalyst 6000 series switch, you have activated system redundancy. No parameters enable you to activate this feature. The first Supervisor to come online is active, and the second one is in standby mode. The standby Supervisor has an orange system light, and the console port is not active. However, the interfaces on the module are active. You can remove or insert Supervisor cards while the switch is powered on. If a second Supervisor is added or a standby Supervisor is replaced, the card being inserted into the switch goes through the power-on diagnostics, but does not test the backplane (because this would interrupt traffic flow) and then goes into standby mode. The standby Supervisor becomes active if there is a failure in the primary Supervisor or if you force a change by resetting the primary Supervisor. Forcing a Change to the Standby Supervisor 1. | Reset the active Supervisor engine:
COS | reset mod#
-OR- switch supervisor
| IOS | (privileged)reload
|
For the COS device, you can reset the module that is active and thereby force the standby to take over. In the reset mod# command, the mod# would be that of the active module. Use the command show module to determine which Supervisor is active. The command switch supervisor automatically chooses to reset the active Supervisor and forces a switch to the secondary.
As configuration changes are made to the Supervisor in the active Supervisor module, these changes are also propagated to NVRAM of the standby Supervisor. If there is a change or a difference in the Supervisor images, the active Supervisor also forces a synchronization of images to ensure compatibility of features. Several items influence the synchronization of COS images between the switches, including the following:
Changing the boot parameters for the switch Overwriting the runtime COS image Deleting the runtime COS image Different time stamps on the runtime COS images stored in bootflash: or slot0:
Catalyst 6000 native IOS switches do not automatically synchronize images. Therefore, to have redundancy operational, you must have the same images on both the active and redundant Supervisor modules. To manually synchronize the images, make sure you have IOS on both Supervisor modules and then copy the image from the active Supervisor to the "slave" Supervisor.
|
Synchronizing IOS Images 1. | (Required) Manually synchronize the images for IOS Supervisor modules:
COS | Automatic; not required | IOS | [View full width] (privileged) # copy source_device:source_filename  destination_device:target_filename
|
The destination device can be one of the following:
- slaveslot0: The PCMCIA card on the redundant Supervisor
- slave-supbootflash: The Supervisor boot flash on the redundant Supervisor
- slave-bootflash: The MSFC boot flash on the redundant Supervisor.
|
As each Supervisor boots, it checks the configuration register to determine how the device is to boot and where to look for the image. Typically the image is specified in a Flash location using boot variable parameters. In the Catalyst operating systems, the configuration registers are not synchronized automatically to enable you to control booting each individually, but the boot variables are synchronized. For Cisco IOS devices, the configuration registers are synchronized by default, but the boot variables are not automatically synchronized. The boot variables specify the operating system location, the bootloader file, and configuration files to be used on boot. It is important that both modules have configuration parameters that allow them to automatically boot the same image before redundancy actually takes place. By default the configuration registers of both operating systems use boot system commands to load the OS. Therefore, they are correctly configured. When you specify a boot location of a COS image, this initiates an OS synchronization. If the configuration register is altered, you must manually configure the register on each module (1 and 2) of a COS device so that it automatically loads the image. The IOS devices synchronize the configuration register by default. If you change the boot parameters, however, saving the configuration on the active Supervisor will not change to boot variables on the standby Supervisor. Synchronizing Boot Parameters 1. | (Required) Synchronize the configuration register:
COS | [View full width] (privileged) set boot config-register boot {rommon | bootflash | system} [module]
| IOS | Automatic; not required |
When setting the configuration register on the COS device, specify which Supervisor you're setting with the module option. During startup, the Supervisor boots from one of: rommon (ROM-monitor; no system image is run), bootflash (the first image file stored in the onboard Flash memory), or system (the system image given by the BOOT environment variable). Try to avoid using the bootflash keyword, as the first image stored in flash will not always be the desired image.
| 2. | (Required) Synchronize the location of the boot image:
COS | Automatic; not required | IOS | (global) redundancy (redundancy) main-cpu (redundancy-maincpu) auto-sync bootvar (redundancy-maincpu) end (privileged) copy running-config startup-config
|
After you have redundant Supervisors operational, you can check the status with the command show module for COS switches or show module all for IOS switches to verify that one Supervisor is active and the other in standby mode.
When you have two Supervisors installed in the switch, your switch is in redundancy mode for COS switches and enhanced systems high availability mode for IOS switches. This means that the configurations are synchronized between the switches and that if one module fails, the standby will take over. When the redundant module takes over for a COS switch, however, it must initialize the ports and run the Spanning Tree Protocol (STP) to determine the port states. This failover takes about 30 to 40 seconds. To provide a quicker failover for the Supervisors, you need to enable high availability on your COS switch. In this mode, the switches are also synchronizing forwarding information between the modules. Including STP, some features are incompatible with high parameters so that the failover will be more efficient. In the case of the IOS switch, the Layer 2 and Layer 3 processors are running the same software, and the forwarding tables and configurations are automatically synchronized.
With the COS devices, however, you must consider a few things before enabling high availability. Remember that some features are incompatible with high availability, including the following:
If you want to run any of these features, you cannot enable high availability. If you do enable high availability, you will not be able to configure these features. Keeping high availability disabled does not stop the secondary Supervisor from becoming active; it only prevents the synchronization of forwarding tables and therefore causes the secondary Supervisor to have to learn all the forwarding information in order after it becomes active.
|
Enabling High Availability 1. | (Optional) Enable high availability:
COS | [View full width] (privileged) set system highavailability {enable | disable}
| IOS | N/A |
The default configuration is that high availability is disabled. To enable high availability, use the keyword enable. If you want to disable the feature, use the keyword disable.
|
Enabling High-Availability Versioning It is sometimes desirable to upgrade the active Supervisor image, but not that of the standby image in the event that you need to back out of an upgrade. Another feature of high availability on COS machines is something called versioning. Versioning enables you to have separate runtime images between Supervisor images within supported tolerances. For example, versions 6.1(3) and 6.1(4) are fully compatible images. See the Release Notes on your image to find out more about versioning. The active Supervisor engine exchanges image version information with the standby Supervisor engine and determines whether the images are compatible for enabling high availability. To enable high-availability versioning, perform the configuration that follows. 1. | (Required) Enable high availability:
COS | (privileged) set system highavailability enable
| IOS | N/A |
|
This is a default and has to be enabled only if high availability was previously disabled. 2. | (Required) Enable high-availability versioning:
COS | [View full width] (privileged) set system highavailability versioning enable
| IOS | N/A |
|
|
