Home > Articles > Cisco Certification > CCIE > Configuring the Catalyst

Configuring the Catalyst

Chapter Description

This sample chapter from Cisco Press compares differences between the router CLI and the Catalyst 4000/5000/6000 family. It also describes the command line interface including aspects like command line recall, command editing, uploading and downloading code images and configuration files, and finally provides an overview of the menu driven configuration for the other Catalysts.

Redundant Supervisor Modules

One of the motivations for the introduction of the Catalyst 5500 series products was the customer need for system redundancy. The legacy Catalyst 5000 series contains one Supervisor module, which, if it fails, disables the entire unit. The Catalyst 5500/6000 family, on the other hand, enables you to put two Supervisor modules into the chassis at the same time. On power up, one of the modules becomes the active Supervisor engine, and the other becomes the standby Supervisor engine. The active Supervisor engine module takes care of all Catalyst operational details and provides the CLI for the administrator. The active module, therefore, takes care of the Spanning-Tree Protocol, SNMP, CLI, Telnet, VLAN assignments, VTP, CDP, and other aspects. If at any time the active engine fails, the Catalyst resets and the standby engine assumes the responsibility of the active Supervisor engine.

When a Supervisor module is in standby mode, its console interface is not active. All configuration changes must be made through the active Supervisor engine. And depending upon what version of Supervisor engine code is running, you might not be able to use the uplink ports on the standby unit either. If you are running an engine software version earlier than 4.1, you cannot use the uplinks on the standby unit. However, when the standby unit becomes the active module, the uplink ports are activated. If you have 4.1 or 4.2, the standby ports are active at all times, even if the module is in standby mode. If you have version 4.3 or later, the standby ports are inactive by default when in standby mode, but can be administratively enabled.


When using redundant uplink ports on a standby Supervisor, be sure that you do not configure more than 20 VLANs in current versions of the software. Doing so can potentially create Spanning Tree loops, increase convergence time, and decrease network stability.

There are a few things that must be true for the failover to function correctly:

  1. The Catalyst 5000 Supervisor module must be a Supervisor Engine II or later. The legacy Supervisor module that is associated with the Catalyst 5000 series does not support the redundant features. In fact, the Supervisor I module does not even work in a 5500 chassis. All Catalyst 6000 Supervisors support redundancy.

  2. The active and the standby Supervisor engines must be the same model. For Catalyst 5500s, they must both be Supervisor II or both be Supervisor III. You cannot mix a Supervisor II and a Supervisor III in the same unit. The reason for this will become clear shortly.

  3. If you use two Catalyst 5000 Supervisor III modules, the feature cards on the two cards must be the same. If you have the NetFlow Feature Card (NFFC) card on one, they must both have NFFC capability.

  4. Configuration files must match between the two modules.

  5. The software images must be the same for both.

The first three items you must administratively ensure. You must select the appropriate hardware to support the redundancy feature. The Catalyst cannot do this for you.

However, the Catalyst can greatly help you regarding the last two items. The system code automatically synchronizes software between the two Supervisor modules to ensure that they are running the same files. This helps to ensure that, in the event of a failover, the failover condition can support all configured features that were running when the first unit was the active unit. Most network engineers can deal with a failover situation and replace a failed module. But when the network operational mode changes as a result of the failover ("oh no, everything now is in VLAN 1!"), they become very unhappy. So do users.

Synchronizing Configuration Between Redundant Supervisor Modules

Whenever you make a configuration change, you must make it in the active Supervisor module, because the console on the standby unit is disabled. If you make a change on the active Supervisor, how do you ensure that the configuration on the standby unit gets updated too? You don't need to, the Catalyst does it for you.

Configuration changes on the active unit are automatically updated to the standby unit. This happens internally to the Catalyst. If you swap standby modules, the active Supervisor automatically ensures that the standby gets a copy of the current configuration. It updates the configuration file in the standby unit.


Remember that any redundant Supervisor module you insert into the Catalyst acquires the configuration of the operating active Supervisor module. Do not insert a module with an "updated" configuration file and expect it to modify the active unit. You lose your updated file.

Synchronizing Image Files Between Redundant Supervisor Modules

Not only must the Supervisor modules be the same and running the same configuration file, but they must also have the same software image. As with the configuration file, the active Supervisor module ensures that the standby unit has the same software image. If they differ, the active Supervisor module loads the running image to the standby Supervisor and resets the standby module. The active unit checks the following to determine if the software images need to be synchronized:

  1. The active unit checks to see if the boot images have the same time stamp. If they differ, the active Supervisor module updates the standby Supervisor module.

  2. If you change the BOOT environment variable, the active Supervisor module copies the new target boot image to the standby, if necessary, and modifies the environment variable on the standby so that they start with the same image.

  3. If you upgrade the boot image on the active unit, the active Supervisor module updates the standby.

Notice that images and configurations flow from the active to the standby units, never the other direction. You cannot update the image on the standby module first and then synchronize the active module with the standby. The standby always synchronizes to the active.

When using Catalyst 5000 Supervisor Engine III modules and all Catalyst 6000 modules, additional elements are compared between the active and standby engines. Specifically, the active module compares not just the boot image, but also the run-time image. The run-time image is the image used by the ROM monitor to boot the Supervisor module. If the run-time image successfully loads, and there is a boot image, and a BOOT environment variable pointing to the boot image, the Catalyst also loads the boot image, which is your desired operational image.

The Supervisor ensures that the run-time images are the same on the two modules. As with the boot image, if they differ, the active unit synchronizes the two by downloading a new run-time image. Therefore, the active Supervisor module performs the following to determine if there is a need to synchronize:

  1. The active unit checks the timestamp on the run-time image. If they differ, it initiates the synchronization process.

  2. If you overwrite the run-time image on the active unit, the active module synchronizes the standby unit.

8. Configuring Other Catalysts | Next Section Previous Section