Table of Contents
Catalyst 4500 series switches allow a standby supervisor engine to take over if the active supervisor engine fails. In software, supervisor engine redundancy is enabled by running the redundant supervisor engine in route processor redundancy (RPR) or stateful switchover (SSO) operating mode.
Note For information on Cisco nonstop forwarding (NSF) with SSO, see Chapter9, “Configuring Cisco NSF with SSO Supervisor Engine Redundancy”
- About Supervisor Engine Redundancy
- About Supervisor Engine Redundancy Synchronization
- Supervisor Engine Redundancy Guidelines and Restrictions
- Configuring Supervisor Engine Redundancy
- Performing a Manual Switchover
- Performing a Software Upgrade
- Manipulating Bootflash on the Standby Supervisor Engine
Note For complete syntax and usage information for the switch commands used in this chapter, first look at the Cisco Catalyst 4500 Series Switch Command Reference and related publications at this location:
If the command is not found in the Catalyst 4500 Series Switch Command Reference, it will be found in the larger Cisco IOS library. Refer to the Catalyst 4500 Series Switch Cisco IOS Command Reference and related publications at this location:
With supervisor engine redundancy enabled, if the active supervisor engine fails or if a manual switchover is performed, the standby supervisor engine becomes the “new” active supervisor engine. The standby supervisor engine has been automatically initialized with the startup configuration of the active supervisor engine, shortening the switchover time (30 seconds or longer in RPR mode, depending on the configuration; subsecond in SSO mode).
Supervisor engine redundancy allows OIR of the redundant supervisor engine for maintenance. When the redundant supervisor engine is inserted, the active supervisor engine detects its presence, and the redundant supervisor engine boots into a partially-initialized state in RPR mode and a fully-initialized state in SSO mode.
- Software upgrade. (See the “Performing a Software Upgrade” section.)
- The active supervisor engine fails (due to either hardware or software function) or is removed.
- A user forces a switchover.
- A user reloads the active supervisor engine.
RPR is supported in Cisco IOS-XE Release 3.1.0SG and later releases. When a standby supervisor engine runs in RPR mode, it starts up in a partially-initialized state and is synchronized with the persistent configuration of the active supervisor engine.
The standby supervisor engine pauses the startup sequence after basic system initialization, and in the event that the active supervisor engine fails, the standby supervisor engine becomes the new active supervisor engine.
In a supervisor engine switchover, traffic is disrupted because in the RPR mode all of the physical ports restart since there is no state maintained between supervisor engines relating to module types and statuses. Upon switchover, when the standby supervisor engine completes its initialization, it will read hardware information directly from the module and become the active supervisor engine.
When a standby supervisor engine runs in SSO mode, the standby supervisor engine starts up in a fully-initialized state and synchronizes with the persistent configuration and the running configuration of the active supervisor engine. It subsequently maintains the state on the protocols listed below, and all changes in hardware and software states for features that support stateful switchover are kept in synchronization. Consequently, it offers zero interruption to Layer 2 sessions in a redundant supervisor engine configuration.
Because the standby supervisor engine recognizes the hardware link status of every link, ports that were active before the switchover will remain active, including the uplink ports. However, because uplink ports are physically on the supervisor engine, they will be disconnected if the supervisor engine is removed.
If the active supervisor engine fails, the standby supervisor engine become active. This newly active supervisor engine uses existing Layer 2 switching information to continue forwarding traffic. Layer 3 forwarding will be delayed until the routing tables have been repopulated in the newly active supervisor engine.
- 802.3x (Flow Control)
- 802.3ab (GE)
- 802.3z (Gigabit Ethernet including CWDM)
- 802.3ad (LACP)
- 802.1p (Layer 2 QoS)
- 802.1X (Authentication)
- 802.1D (Spanning Tree Protocol)
- 802.3af (Inline power)
- Dynamic ARP Inspection
- DHCP snooping
- IP source guard
- IGMP snooping (versions 1 and 2)
- DTP (802.1q and ISL)
- BPDU guard and filtering
- Voice VLAN
- Port security
- Unicast MAC filtering
- ACL (VACLS, PACLS, RACLS)
- QOS (DBL)
- Multicast storm control/broadcast storm control
- 802.1Q tunneling with Layer 2 Protocol Tunneling (L2PT)
- Baby giants
- Jumbo frame support
- Flood blocking
During normal operation, the persistent configuration (RPR and SSO) and the running configuration (SSO only) are synchronized by default between the two supervisor engines. In a switchover, the new active supervisor engine uses the current configuration.
- RPR Supervisor Engine Configuration Synchronization
- SSO Supervisor Engine Configuration Synchronization
Because the standby supervisor engine is only partially initialized in RPR mode, it interacts with the active supervisor engine only to receive configuration changes at startup and upon saving the configuration changes.
- When the standby supervisor engine boots, the auto-sync command synchronizes the persistent configuration. This command is enabled by default. For details, refer to “Synchronizing the Supervisor Engine Configurations” section.
- When the active supervisor engine detects the standby supervisor engine, the configuration information is synchronized from the active supervisor engine to the standby supervisor engine. This synchronization overwrites any existing startup configuration file on the standby supervisor engine.
- When you make changes to the configuration, you must use the write command to save and synchronize the startup configuration to the standby supervisor engine.
- When the active supervisor detects the standby supervisor engine, synchronization of the persistent and running configuration takes place, allowing the standby supervisor engine to arrive at a fully-initiated state.
- When real-time changes occur, the active supervisor engine synchronizes the running-config and (or) the persistent configuration (if necessary) with the standby supervisor engine.
- When you change the configuration, you must use the write command to allow the active supervisor engine to save and synchronize the startup configuration to the standby supervisor engine.
- If SSO mode cannot be established between the active and standby supervisor engines because of an incompatibility in the configuration file, a mismatched command list (MCL) is generated at the active supervisor engine and a reload into RPR mode is forced for the standby supervisor engine. Subsequent attempts to establish SSO, after removing the offending configuration and rebooting the standby supervisor engine with the exact same image, might cause the C4K_REDUNDANCY-2-IOS_VERSION_CHECK_FAIL and ISSU-3-PEER_IMAGE_INCOMPATIBLE messages to appear because the peer image is listed as incompatible. If the configuration problem can be corrected, you can clear the peer image from the incompatible list with the redundancy config-sync ignore mismatched-commands EXEC command while the peer is in a standby cold (RPR) state. This action allows the standby supervisor engine to boot in standby hot (SSO) state when it reloads.
- SSO is not supported if the IOS-XE software is running in the LAN Base mode.
- In RPR or SSO mode, with Supervisor Engine 8-E, only the first four uplinks on each supervisor engine are available provided a 47xx line card is inserted on slot 10. The second set of four uplinks are unavailable. Only the first two uplinks on each supervisor are available unless the requirement is met (i.e., 47xx linecard in 4510 chassis).
- SSO requires both supervisor engines in the chassis to have the same components (model and memory), and to use the same Cisco IOS XE software image.
- The active and standby supervisor engines in the chassis must be in slots 3 and 4 for 7-slot chassis and slot 5 and 6 for 10-slot chassis.
- Each supervisor engine in the chassis must have its own flash device and console port connections to operate the switch on its own.
- Each supervisor engine must have a unique console connection. Do not connect a Y cable to the console ports.
- Supervisor engine redundancy does not provide supervisor engine load balancing.
- The Cisco Express Forwarding (CEF) table is cleared on a switchover. As a result, routed traffic is interrupted until route tables reconverge. This reconvergence time is minimal because the SSO feature reduces the supervisor engine redundancy switchover time from 30+ seconds to subsecond, so Layer 3 also has a faster failover time if the switch is configured for SSO.
- Static IP routes are maintained across a switchover because they are configured from entries in the configuration file.
- Information about Layer 3 dynamic states that is maintained on the active supervisor engine is not synchronized to the standby supervisor engine and is lost on switchover.
- If configuration changes on a redundant switch are made through SNMP set operations, the changes are not synchronized to the standby supervisor engine even in SSO mode. You might experience unexpected behavior.
- After you configure the switch through SNMP in SSO mode, copy the running-config file to the startup-config file on the active supervisor engine to trigger synchronization of the startup-config file to the standby supervisor engine. Then, reload the standby supervisor engine so that the new configuration is applied on the standby supervisor engine.
- You cannot perform configuration changes during the startup (bulk) synchronization. If you attempt to make configuration changes during this process, the following message is generated:
- If configuration changes occur at the same time as a supervisor engine switchover, these configuration changes are lost.
- If you remove a line card from a redundant switch and initiate an SSO switchover, then reinsert the line card, and all interfaces are shutdown. The rest of the original line card configuration is preserved.
- Configuring Redundancy
- Virtual Console for Standby Supervisor Engine
- Synchronizing the Supervisor Engine Configurations
Note IOS XE software can be booted at three different levels (Enterprise Services, IP Base, and LAN Base), based on the licenses available on the supervisor engine. If you are booting the image in LAN Base mode, only RPR redundancy mode is available.
Image Version = Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 15.0(100)XO(1.42), INTERIM SOFTWARE Copyright (c) 1986-2010 by Cisco Systems, Inc.Image Version = Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSALK9-M), Version 15.0(100)XO(1.42), INTERIM SOFTWARE Copyright (c) 1986-2010 by Cisco Systems, Inc.*Aug 1 13:11:16: %C4K_REDUNDANCY-3-COMMUNICATION: Communication with the peer Supervisor has been lost*Aug 1 13:11:16: %C4K_REDUNDANCY-3-COMMUNICATION: Communication with the peer Supervisor has been lost
Catalyst 4500 series switches can be configured with 2 supervisor engines to provide redundancy. When the switch is powered, one of the supervisor engines becomes active and remains active until a switchover occurs. The other supervisor engine remains in standby mode.
Each supervisor engine has its own console port. Access to the standby supervisor engine is possible only through the console port of the standby supervisor engine. Therefore, you must connect to the standby console to access, monitor or debug the standby supervisor.
Virtual Console for Standby Supervisor Engine enables you to access the standby console from the active supervisor engine without requiring a physical connection to the standby console. It uses IPC over EOBC to communicate with the standby supervisor engine and thus emulate the standby console on the active supervisor engine. Only one standby console session is active at any time.
The Virtual Console for Standby Supervisor Engine allows users who are logged onto the active supervisor engine to remotely execute show commands on the standby supervisor engine and view the results on the active supervisor engine. Virtual Console is available only from the active supervisor engine.
You can access the standby virtual console from the active supervisor engine with the attach module, session module, or remote login commands on the active supervisor engine. You must be in privilege EXEC mode (level 15) to run these commands to access the standby console.
Once you enter the standby virtual console, the terminal prompt automatically changes to
hostname-standby-console where hostname is the configured name of the switch. The prompt is restored to the original setting when you exit the virtual console.
You exit the virtual console with the exit or quit commands. When the inactivity period of the terminal on the active supervisor engine where you logged in exceeds the configured idle time, you are automatically logged out of the terminal on the active supervisor engine. In this instance, the virtual console session is also terminated. Virtual console session is also automatically terminated when the standby is rebooted. After the standby boots up, you need to create another virtual console session.
- All commands on the virtual console run to completion. It does not provide the auto-more feature; it behaves as if the terminal length 0 command has been executed. It is also non-interactive. Therefore, a running command cannot be interrupted or aborted by any key sequence on the active supervisor engine. If a command produces considerable output, the virtual console displays it on the supervisor engine screen.
- The virtual console is non-interactive. Because the virtual console does not detect the interactive nature of a command, any command that requires user interaction causes the virtual console to wait until the RPC timer aborts the command.
The virtual console timer is set to 60 seconds. The virtual console returns to its prompt after 60 seconds. During this time, you cannot abort the command from the key board. You must wait for the timer to expire before you continue.
- You cannot use virtual console to view debug and syslog messages that are being displayed on the standby supervisor engine. The virtual console only displays the output of commands that are executed from the virtual console. Other information that is displayed on the real standby console does not appear on the virtual console.
Note Configuration changes made to the active supervisor engine through SNMP are not synchronized to the redundant supervisor engine. For information on how to handle this situation, see the “Supervisor Engine Redundancy Guidelines and Restrictions” section.
Note The auto-sync command controls the synchronization of the config-reg, bootvar, and startup/private configuration files only. The calendar and VLAN database files are always synchronized when they change. In SSO mode, the running-config is always synchronized.
This example shows how to reenable the default automatic synchronization feature using the auto-sync standard command to synchronize the startup-config and config-register configuration of the active supervisor engine with the standby supervisor engine. Updates for the boot variables are automatic and cannot be disabled.
This example shows how to disable default automatic synchronization and allow only automatic synchronization of the config-registers of the active supervisor engine to the standby supervisor engine, while disallowing synchronization of the startup configuration:
This section describes how to perform a manual switchover (from the active supervisor engine to the standby supervisor engine) for test purposes. We recommend that you perform a manual switchover prior to deploying SSO in your production environment.
- force a switchover, the redundant supervisor engine must be in a standby hot (SSO) or standby cold (RPR) state. You can verify the state with the show redundancy command. If the state is not standby hot or standby cold, the redundancy force-switchover command will not execute.
- Use the redundancy force-switchover command, rather than the reload command, to initiate a switchover. The redundancy force-switchover command will first check that the redundant supervisor engine is in the correct state. If you issue the reload command and the status is not standby hot or standby cold, the reload command will reset the current supervisor engine and the peer supervisor may not be able to take over because it was not in a terminal state (standby hot or cold).
After a normal switchover, you might want to make the supervisor engine in a lower slot number of the chassis the active supervisor engine. Use the show module command to see which slot contains the active supervisor engine, and force another switchover if necessary.
The software upgrade procedure supported by supervisor engine redundancy allows you to reload the Cisco IOS software image on the redundant supervisor engine, and once complete, reload the active supervisor engine once.
Configures the supervisor engines to boot the new image.
If your system was configured to autoboot an earlier image, issue the following command string to boot the new image instead:
no boot system flash device : old_file_name
4d01h: %C4K_REDUNDANCY-5-CONFIGSYNC: The bootvar has been successfully synchronized to the standby supervisor4d01h: %C4K_REDUNDANCY-5-CONFIGSYNC: The config-reg has been successfully synchronized to the standby supervisor4d01h: %C4K_REDUNDANCY-5-CONFIGSYNC: The startup-config has been successfully synchronized to the standby supervisor4d01h: %C4K_REDUNDANCY-5-CONFIGSYNC: The private-config has been successfully synchronized to the standby supervisor