Catalyst 4500 Series Switch Cisco IOS Software Configuration Guide, 12.2(25)EWA
Configuring Supervisor Engine Redundancy Using RPR and SSO
Downloads: This chapterpdf (PDF - 308.0KB) | Feedback

Configuring Supervisor Engine Redundancy Using RPR and SSO

Table Of Contents

Configuring Supervisor Engine Redundancy Using RPR and SSO

Understanding Cisco IOS NSF-Awareness Support

Understanding Supervisor Engine Redundancy

Overview

RPR Operation

SSO Operation

Understanding Supervisor Engine Redundancy Synchronization

RPR Supervisor Engine Configuration Synchronization

SSO Supervisor Engine Configuration Synchronization

Supervisor Engine Redundancy Guidelines and Restrictions

Configuring Supervisor Engine Redundancy

Configuring Redundancy

Synchronizing the Supervisor Engine Configurations

Performing a Manual Switchover

Performing a Software Upgrade

Manipulating Bootflash on the Redundant Supervisor Engine


Configuring Supervisor Engine Redundancy Using RPR and SSO


Catalyst 4500 series switches allow a redundant 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 The minimum ROMMON requirement for running SSO is Release 12.1(20r)EW1 or Release 12.2(20r)EW1.


This chapter describes how to configure supervisor engine redundancy on the Catalyst 4507R and Catalyst 4510R switches. It also describes the relationship between SSO and Cisco IOS NSF-awareness.

This chapter contains these major sections:

Understanding Cisco IOS NSF-Awareness Support

Understanding Supervisor Engine Redundancy

Understanding 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 Redundant Supervisor Engine


Note For complete syntax and usage information for the switch commands used in this chapter, look at the Cisco Catalyst 4500 Series Switch Command Reference and related publications at this location:

http://www.cisco.com/en/US/products/hw/switches/ps4324/index.html

If the command is not found in the Catalyst 4500 Command Reference, it is located in the larger Cisco IOS library. Refer to the Catalyst 4500 Series Switch Cisco IOS Command Reference and related publications at this location:

http://www.cisco.com/en/US/products/ps6350/index.html


Understanding Cisco IOS NSF-Awareness Support

Cisco IOS Nonstop Forwarding (NSF) has two primary components:

NSF-capability—NSF works with SSO to minimize the amount of time that a Layer 3 network is unavailable following a supervisor engine switchover by continuing to forward IP packets. Reconvergence of Layer 3 routing protocols (BGP, EIGRP, OSPF v2, and IS-IS) is transparent to the user and happens automatically in the background. The routing protocols recover routing information from neighbor devices and rebuild the Cisco Express Forwarding (CEF) table.

NSF-awareness—If neighboring router devices detect that an NSF router can still forward packets when RP (Route Processor) switchover happens, this capability is referred to as NSF-awareness. Cisco IOS enhancements to the Layer 3 protocols OSPF, BGP, EIGRP and IS-IS are designed to prevent route-flapping so that the CEF routing table does not timeout or the NSF router does not drop routes. An NSF-aware router helps to send routing protocol information to the neighboring NSF router.


Note NSF capable devices are Catalyst 6500 series switches, Cisco 7500 series routers, Cisco 10000 series routers, and Cisco 12000 series routers. The Catalyst 4500 series switch is an NSF-aware device for Release 12.2(20)EWA.


For more information on BGP, EIGRP, OSPF, and IS-IS NSF-awareness, refer to the URL:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guides_list.html

A typical topology for NSF and NSF-aware routers is given below.

Figure 6-1 Topology for NSF and NSF-Aware Router

Table 6-1 lists the supervisor engines and Catalyst 4500 series switches that support NSF-awareness:

Table 6-1 NSF-Aware Capable Supervisor Engine and Catalyst 4500 Series Switch Matrix

NSF-Aware Capable Supervisor Engine
Switch Support

Supervisor Engine III (WS-X4014)

Catalyst 4506 series switch and Catalyst 4503 series switch

Supervisor Engine IV (WS-X4515)

Catalyst 4507R series switch, Catalyst 4506 series switch, and Catalyst 4503 series switch

Supervisor Engine V (WS-X4516)

Catalyst 4507R series switch and Catalyst 4510R series switch

Fixed Switch (WS-C4948)

Catalyst 4948 switch


In Release 12.2(20)EWA, NSF-awareness is supported on Catalyst 4500 series switches for EIGRP, IS-IS, OSPF and BGP protocols. NSF-awareness is turned on by default for EIGRP, IS-IS and OSPF protocols. For BGP, it needs to be turned on manually.

If the supervisor engine is configured for BGP (with the graceful-restart command), EIGRP, OSPF or IS-IS routing protocols, routing updates are automatically sent during the supervisor engine switchover of a neighboring NSF capable switch (typically a Catalyst 6500 series switch).

Understanding Supervisor Engine Redundancy

These sections describe supervisor engine redundancy:

Overview

RPR Operation

SSO Operation

"Understanding Supervisor Engine Redundancy Synchronization" section

Overview

With supervisor engine redundancy enabled, if the active supervisor engine fails or if a manual switchover is performed, the redundant supervisor engine becomes the active supervisor engine. The redundant 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; subseconds in SSO mode).

In addition to the reduced switchover time, supervisor engine redundancy supports the following:

Online insertion and removal (OIR) of the redundant supervisor engine.

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.)

To minimize down time during software changes on the supervisor engine, load the new image on the redundant supervisor engine, and conduct a switchover.

When power is first applied to a switch, the supervisor engine that boots first becomes the active supervisor engine and remains active until a switchover occurs.

A switchover will occur when one or more of the following events take place:

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.

Table 6-2 provides information about chassis and supervisor engine support for redundancy.

Table 6-2 Chassis and Supervisor Support 

Chassis
(Product Number)
Supported Supervisor Engines
 

Catalyst 4507R (WS-C4507R)

Supports redundant Supervisor Engine II-Plus (WS-X4013+), Supervisor Engine IV (WS-X4515), redundant Supervisor Engine V (WS-X4516)

Catalyst 4510R (WS-C4510R)

Supports redundant Supervisor Engine V (WS-X4516)


RPR Operation

RPR is supported in Release 12.2(12c)EW and later releases. When a redundant 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.


Note Persistent configuration includes the following components: startup-config, boot variables, config-register, and VLAN database.


The redundant supervisor engine pauses the startup sequence after basic system initialization, and in the event that the active supervisor engine fails, the redundant supervisor engine will become 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. When the redundant supervisor engine completes its initialization, it will read hardware information directly from the module.

SSO Operation

SSO is supported in Release 12.2(20)EWA and later releases. When a redundant supervisor engine runs in SSO mode, the redundant 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 sync. Consequently, it offers no zero interruption to Layer 2 sessions in a redundant supervisor engine configuration.

Because the redundant 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 redundant 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.

SSO supports stateful switchover of the following Layer 2 features. The state of these features is preserved between both the active and redundant supervisor engines:

802.3

802.3u

802.3x (Flow Control)

802.3ab (GE)

802.3z (Gigabit Ethernet including CWDM)

802.3ad (LACP)

802.1p (Layer 2 QoS)

802.1q

802.1X (Authentication)

802.1D (Spanning Tree Protocol)

802.3af (Inline power)

PAgP

VTP

Dynamic ARP Inspection

DHCP snooping

IP source guard

IGMP snooping (versions 1 and 2)

DTP (802.1q and ISL)

MST

PVST+

Rapid-PVST

PortFast/UplinkFast/BackboneFast

BPDU guard and filtering

Voice VLAN

Port security

Unicast MAC filtering

ACL (VACLS, PACLS, RACLS)

QOS (DBL)

Multicast storm control/broadcast storm control

SSO is compatible with the following list of features. However, the protocol database for these features is not synchronized between the redundant and active supervisor engines:

802.1Q tunneling with Layer 2 Protocol Tunneling (L2PT)

Baby giants

Jumbo frame support

CDP

Flood blocking

UDLD

SPAN/RSPAN

NetFlow

The following features are learned on the redundant supervisor engine if the SSO feature is enabled:

All Layer 3 protocols on Catalyst 4500 series switches (Switch Virtual Interfaces)

Understanding Supervisor Engine Redundancy Synchronization

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.


Note You cannot enter CLI commands on the redundant supervisor engine console.


These sections describe supervisor engine redundancy synchronization:

RPR Supervisor Engine Configuration Synchronization

SSO Supervisor Engine Configuration Synchronization

RPR Supervisor Engine Configuration Synchronization

Because the redundant 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 a redundant supervisor engine is running in RPR mode, the following events trigger synchronization of the configuration information:

When the redundant 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 redundant supervisor engine, the configuration information is synchronized from the active supervisor engine to the redundant supervisor engine. This synchronization overwrites any existing startup configuration file on the redundant supervisor engine.

When you make changes to the configuration, you must use the write command to save and synchronize the startup configuration of the redundant supervisor engine.

SSO Supervisor Engine Configuration Synchronization

When a redundant supervisor engine runs in SSO mode, the following events trigger synchronization of the configuration information:

When the active supervisor detects the redundant supervisor engine, synchronization of the persistent and running configuration takes place, allowing the redundant 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 redundant 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 of the redundant supervisor engine.

Supervisor Engine Redundancy Guidelines and Restrictions

The following guidelines and restrictions apply to supervisor engine redundancy:

RPR requires Release 12.1(12c)EW, Release 12.1(19)E or later releases. SSO requires Release 12.2(20)EWA.

The Catalyst 4507R switch and the 4510R switch are the only Catalyst 4500 series switches that support supervisor engine redundancy.

The Catalyst 4510R switch supports the WS-X4516 supervisor engine only. The Catalyst 4507R switch supports supervisor engines WS-X4013+, WS-X4515, and WS-X4516.

Redundancy requires both supervisor engines in the chassis to be of the same supervisor engine model and to use the same Cisco IOS software image.

When you use the WS-X4013+ and WS-X4515 supervisor engines in RPR or SSO mode, only the Gig1/1 and Gig2/1 Gigabit Ethernet interfaces are available, but the Gig1/2 and Gig2/2 uplink ports are unavailable.

When the WS-X4516 active and redundant supervisor engines are installed in the same chassis, the four uplink ports (Gig1/1, Gig2/1, Gig 1/2, and Gig2/2) are available.

The active and redundant supervisor engines in the chassis must be in slots 1 and 2.

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 subseconds, 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 redundant supervisor engine and is lost on switchover.

Starting with Cisco IOS Release 12.2, if an unsupported condition is detected (such as when the active supervisor engine is running Release 12.2(20)EW and the redundant supervisor engine is running Release 12.1(20)EW), the redundant supervisor engine will be reset multiple times and then be placed in ROMMON mode. Therefore, it is important to follow the exact procedures outlined in the "Performing a Software Upgrade" section.

If you are running (or upgrading to) Release 12.2(20)EWA or Release 12.2(25)EW and are using a single supervisor engine in a redundant chassis (Catalyst 4507R or Catalyst 4510R series switch), and you intend to use routed ports, do one of the following:

Use SVI's instead of routed ports.

Change the redundancy mode from SSO to RPR.

Configuration changes made to the redundant supervisor engine through SNMP synchronization and SNMP set operations in SSO mode are not synchronized to the redundant supervisor engine. Even though you can still perform SNMP set operations in SSO mode, you might experience unexpected behaviour.

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 on the redundant supervisor engine. Then, reload the redundant supervisor engine so that new configuration is applied on the redundant supervisor engine.

Configuring Supervisor Engine Redundancy

These sections describe how to configure supervisor engine redundancy:

Configuring Redundancy

Synchronizing the Supervisor Engine Configurations

Configuring Redundancy

To configure redundancy, perform this task:

 
Command
Purpose

Step 1 

Switch(config)# redundancy 

Enters redundancy configuration mode.

Step 2 

Switch(config-red)# mode {sso | rpr}

Configures SSO or RPR. When this command is entered, the redundant supervisor engine is reloaded and begins to work in SSO or RPR mode.

Step 3 

Switch# show running-config

Verifies that SSO or RPR is enabled.

Step 4 

Switch# show redundancy  
[clients | counters | history | states]

Displays the redundancy information (counter, state, and so on) for the active and redundant supervisor engines.

When configuring redundancy, note the following:

The sso keyword is supported in Release 12.2(20)EWA and later releases.

The rpr keyword is supported in Release 12.1(12c)EW and later releases.

This example shows how to configure the system for SSO and display the redundancy facility information:

Switch> enable 
Switch# configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# redundancy 
Switch(config-red)# mode sso 
Switch(config-red)# end 
Switch# show redundancy
Redundant System Information :
------------------------------
       Available system uptime = 2 days, 2 hours, 39 minutes
Switchovers system experienced = 0
              Standby failures = 0
        Last switchover reason = none

                 Hardware Mode = Duplex
    Configured Redundancy Mode = Stateful Switchover
     Operating Redundancy Mode = Stateful Switchover
              Maintenance Mode = Disabled
                Communications = Up

Current Processor Information :
-------------------------------
               Active Location = slot 1
        Current Software state = ACTIVE
       Uptime in current state = 2 days, 2 hours, 39 minutes
                 Image Version = Cisco Internetwork Operating System Software
IOS (tm) Catalyst 4000 L3 Switch Software (cat4000-I5S-M), Version 12.2(20)EWA(3
.92), CISCO INTERNAL USE ONLY ENHANCED PRODUCTION VERSION
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Wed 14-Jul-04 04:42 by esi
                          BOOT = bootflash:cat4000-i5s-mz.122_20_EWA_392,1
        Configuration register = 0x2002

Peer Processor Information :
----------------------------
              Standby Location = slot 2
        Current Software state = STANDBY HOT
       Uptime in current state = 2 days, 2 hours, 39 minutes
                 Image Version = Cisco Internetwork Operating System Software
IOS (tm) Catalyst 4000 L3 Switch Software (cat4000-I5S-M), Version 12.2(20)EWA(3
.92), CISCO INTERNAL USE ONLY ENHANCED PRODUCTION VERSION
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Wed 14-Jul-04 0
                          BOOT = bootflash:cat4000-i5s-mz.122_20_EWA_392,1
        Configuration register = 0x2002

Switch#

This example shows how to display redundancy facility state information:

Switch# show redundancy states
my state = 13 -ACTIVE
     peer state = 8  -STANDBY HOT
           Mode = Duplex
           Unit = Primary
        Unit ID = 2

Redundancy Mode (Operational) = Stateful Switchover
Redundancy Mode (Configured)  = Stateful Switchover
     Split Mode = Disabled
   Manual Swact = Enabled
 Communications = Up

   client count = 21
 client_notification_TMR = 240000 milliseconds
          keep_alive TMR = 9000 milliseconds
        keep_alive count = 0
    keep_alive threshold = 18
           RF debug mask = 0x0
Switch#

This example shows how to change the system configuration from RPR to SSO mode:

Switch(config)# redundancy 
Switch(config-red)# mode
Switch(config-red)# mode sso
Changing to sso mode will reset the standby. Do you want to continue?[confirm]
Switch(config-red)# end
Switch#
*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-SIMPLEX_MODE: The peer Supervisor has been lost

This example shows how to change the system configuration from SSO to RPR mode:

Switch(config)# redundancy 
Switch(config-red)# mode rpr
Changing to rpr mode will reset the standby. Do you want to continue?[confirm]
Switch(config-red)# end
*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-SIMPLEX_MODE: The peer Supervisor has been lost

Synchronizing the Supervisor Engine Configurations

To manually synchronize the configurations used by the two supervisor engines, perform this task on the active supervisor engine:

 
Command
Purpose

Step 1 

Switch(config)# redundancy

Enters redundancy configuration mode.

Step 2 

Switch(config-red)# main-cpu

Enters main-cpu configuration submode.

Step 3 

Switch(config-r-mc)# auto-sync {startup-config | 
config-register | bootvar | standard}

Synchronizes the configuration elements.

Step 4 

Switch(config-r-mc)# end

Returns to privileged EXEC mode.

Step 5 

Switch# copy running-config startup-config

Synchronizes the running configuration in dynamic random-access memory (DRAM) to the startup configuration file in NVRAM.

Note This step is not required to synchronize the running configuration file in (DRAM).


Note Configuration changes made to the redundant 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 redundant supervisor engine. Updates for the boot variables are automatic and cannot be disabled.

Switch(config)# redundancy
Switch(config-red)# main-cpu
Switch(config-r-mc)# auto-sync standard
Switch(config-r-mc)# end
Switch# copy running-config startup-config

Note To manually synchronize individual elements of the standard auto-sync configuration, disable the default automatic synchronization feature.



Note When you configure the auto-sync standard, the individual sync options such as no auto-sync startup-config are ignored.


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 redundant supervisor engine, while disallowing synchronization of the startup configuration:

Switch(config)# redundancy
Switch(config-red)# main-cpu
Switch(config-r-mc)# no auto-sync standard
Switch(config-r-mc)# auto-sync config-register
Switch(config-r-mc)# end

Performing a Manual Switchover

This section describes how to perform a manual switchover (from the active supervisor engine to the redundant supervisor engine) for test purposes. We recommend that you perform a manual switchover prior to deploying SSO in your production environment.


Note This discussion assumes that SSO has been configured as the redundant mode.


To perform a manual switchover, perform this task on the active supervisor engine:

 
Command
Purpose

Step 1 

Switch# show redundancy

Verifies that the peer state is in the STANDBY HOT state.

See the example of the show redundancy states command on page 6-10.

Step 2 

Switch# redundancy force-switchover

Launches switchover from the active supervisor engine to the redundant supervisor engine.

If the state of the redundant supervisor engine is not standby hot, this command will not execute.

Be aware of these usage guidelines:

To force a switchover, the redundant supervisor engine must be in a standby hot state. You can verify the state with the show redundancy command. If the state is not standby hot, 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, the reload command will reset the current supervisor engine only.

After an initial switchover, there might be occasions when you want to make the supervisor engine in slot 1 of the chassis the active supervisor engine. If the image on supervisor engine 1 is the one you intend to run on both supervisor engines, it is not necessary to re-boot the image on the supervisor engine in slot 1 to make it redundant. Instead, you can force another switchover. However, if you want a newer version of the image to run on both supervisor engines, follow the steps under "Performing a Software Upgrade" on page 12. Use the show module command to see which slot contains the active supervisor engine, and force another switchover if necessary.

Performing a Software Upgrade

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.


Note If the active supervisor engine is running IOS Release 12.2(x)S, the standby supervisor engine cannot run IOS Release 12.1(x)E. This would reset the switch immediately after the system boot of the standby supervisor engine. The reverse configuration, where the standby engine is running IOS Release 12.2(x)S and the active supervisor engine is running 12.1(x)E, is fully supported.


To perform a software upgrade, perform this task:

 
Command
Purpose

Step 1 

Switch# copy source_device:source_filename 
slot0:target_filename

Or:

Switch# copy source_device:source_filename 
bootflash:target_filename 

Copies the new Cisco IOS software image to bootflash on the supervisor engine.

Step 2 

Switch# copy source_device:source_filename 
slaveslot0:target_filename

Or:

Switch# copy source_device:source_filename 
slavebootflash:target_filename 

Copies the new image to a slave device (such as slavebootflash and slaveslot0).

Step 3 

Switch# config terminal
Switch(config)# config-register 0x2
Switch(config)# boot system flash 
device:file_name 

Configures the supervisor engines to boot the new image.

Step 4 

Switch(config)# redundancy

Enters redundancy configuration mode.

Step 5 

Switch(config-red)# main-cpu

Enters main-cpu configuration submode.

Step 6 

Switch(config-r-mc)# auto-syn standard

Synchronizes the configuration elements.

Step 7 

Switch(config-r-mc)# end

Returns to privileged EXEC mode.

Step 8 

Switch# copy running-config start-config

Saves the configuration.

Step 9 

Switch# redundancy reload peer

Reloads the redundant supervisor engine and brings it back online (using the new release of the Cisco IOS software).

Note Before proceeding to Step 10, ensure that the switch is operating in RPR mode.

Step 10 

Switch# redundancy force-switchover

Conducts a manual switchover to the redundant supervisor engine. The redundant supervisor engine becomes the new active supervisor engine using the new Cisco IOS software image.

The old active supervisor engine reboots with the new image and becomes the redundant supervisor engine.

This example shows how to perform a software upgrade:

Switch# config terminal
Switch(config)# config-register 0x2
Switch(config)# boot system flash slot0:cat4000-i5s-mz.122-20.EWA
Switch(config)# redundancy
Switch(config-red)# main-cpu
Switch(config-r-mc)# auto-syn standard
Switch(config-r-mc)# end
Switch# copy running-config start-config
Switch# redundancy reload peer
Switch# redundancy force-switchover 
Switch#

This example illustrates how to verify that the running configuration on the active supervisor engine has successfully synchronized with the redundant supervisor engine:

Switch# config terminal
Switch(config)# redundancy
Switch(config-red)# main-cpu
Switch(config-r-mc)# auto-sync standard
4d01h: %C4K_REDUNDANCY-5-CONFIGSYNC: The bootvar has been successfully synchronized to the 
standby supervisor
4d01h: %C4K_REDUNDANCY-5-CONFIGSYNC: The config-reg has been successfully synchronized to 
the standby supervisor
4d01h: %C4K_REDUNDANCY-5-CONFIGSYNC: The startup-config has been successfully synchronized 
to the standby supervisor
4d01h: %C4K_REDUNDANCY-5-CONFIGSYNC: The private-config has been successfully synchronized 
to the standby supervisor

The example above shows that the boot variable, the config-register, and the startup configuration from the active supervisor engine have successfully synchronized to the redundant supervisor engine.

Manipulating Bootflash on the Redundant Supervisor Engine


Note The console port on the redundant supervisor engine is not available.


To manipulate the redundant supervisor engine bootflash, perform one or more of the following tasks:

Command
Purpose
Switch# dir slaveslot0:target_filename 

or: 
Switch# dir slavebootflash:target_filename 

Lists the contents of the slot0: device on the redundant supervisor engine.

Lists the contents of the bootflash: device on the redundant supervisor engine.

Switch# delete slaveslot0:target_filename

or: 
Switch# delete slave bootflash:target_filename 

Deletes specific files from the slot0: device on the redundant supervisor engine.

Deletes specific files from the bootflash: device on the redundant supervisor engine.

Switch# squeeze slaveslot0:target_filename

or: 
Switch# squeeze slavebootflash:target_filename 

Squeezes the slot0: device on the redundant supervisor engine.

Squeezes the bootflash: device on the redundant supervisor engine.

Switch# format slaveslot0:target_filename

or: 
Switch# format slavebootflash:target_filename 

Formats the slot0: device on the redundant supervisor engine.

Formats the bootflash: device on the redundant supervisor engine.

Switch# copy source_device:source_filename 
slaveslot0:target_filename

or: 
Switch# copy source_device:source_filename 
slavebootflash:target_filename 

Copies a file from the active supervisor engine to the slot0: device on the redundant supervisor engine.

Copies a file to the bootflash: device on a redundant supervisor engine.

Note   Source could be the active supervisor engine or a TFTP server.