Catalyst 6500 Release 12.2SX Software Configuration Guide

Performing an Enhanced Fast Software Upgrade

This chapter provides information about how to perform a software upgrade using the Enhanced Fast Software Upgrade (eFSU) feature.

Note For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS Master Command List, at this URL:

http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum

This chapter contains the following sections:

•eFSU Overview

•eFSU Restrictions

•Performing an Enhanced Fast Software Upgrade

•Performing an eFSU Upgrade on an Installed Modular Image

•Upgrading a Non-eFSU Image to an eFSU Image

eFSU Overview

The following sections provide an overview of how eFSU works:

•eFSU Operation

•Outage Time and Support Considerations

•Reserving Module Memory

•Error Handling for eFSU Preload

Note eFSU is supported in VSS mode. See the "VSS Configuration Guidelines and Restrictions" section for more information.

eFSU Operation

eFSU is an enhanced software upgrade procedure. Cisco IOS Release 12.2(33)SXI and later releases support eFSU.

Non-eFSU (FSU) software upgrades require system downtime, because a software version mismatch between the active and the standby supervisor engines forces the system to boot in RPR redundancy mode, which is stateless and causes a hard reset of the all modules.

eFSU enables an increase in network availability by reducing the downtime caused by software upgrades. eFSU does this by:

•Bringing up the standby supervisor engine in SSO mode even when the active and the standby supervisor engines have different software versions, or with VSS configured, when the supervisor engines in the two chassis have different software versions.

During an eFSU, new software is loaded onto the standby supervisor engine while the active supervisor engine continues to operate using the previous software. As part of the upgrade, the standby processor reaches the SSO Standby Hot stage, a switchover occurs, and the standby becomes active, running the new software. In previous releases Supervisor Engines running different software versions ran in the Route Processor Redundancy Mode.

You can continue with the upgrade to load the new software onto the other processor, or you can abort the upgrade and resume operation with the old software.

•Preloading new module software into memory on supported modules to avoid a hard reset.

If the new software release contains new module software, eFSU preloads the new module software onto any modules in the switch that support eFSU preload. When the switchover occurs between the active and standby supervisor engines, the modules are restarted with the new software image.

The following modules support eFSU preload:

–WS-X67xx modules

–SIP-400 and SIP-600

All other modules undergo a hard reset at switchover, and the software image loads after the module restarts.

During a software upgrade, the switch performs the following steps automatically on modules that support eFSU preload:

–Reserves the necessary memory for the new Cisco IOS software image on each module.

–Preloads a new software image onto the modules as part of the issu loadversion command.

–Restarts the modules with the new software image when a switchover occurs (issu runversion).

–During the restart, the software features and routing protocols are not available.

–If a rollback or abort occurs, to minimize disruption, the switch preloads the original software version onto the module. Once the rollback or abort is completed, the module is restarted with the original software version.

Note All modules that support eFSU preload must have at least 512 MB of memory, with enough memory free to hold the new software image. If there is insufficient free memory, eFSU does not attempt the preload, but instead resets the modules during the switchover.

Outage Time and Support Considerations

During an eFSU upgrade, modules are restarted or reset after the switchover that occurs between the supervisor engines. Because the modules are restarted or reset, any links attached to the modules go up and down and traffic processing is disrupted until protocols and software features are brought back online. The length of time that module processing is disrupted (outage time) depends on whether the eFSU process was able to preload a new software image onto the module.

•For modules that support eFSU preload, the outage time for an eFSU module warm reload is faster than an RPR mode module reload.

•For modules that do not support eFSU preload, the outage time for module reload is similar to an RPR mode module reload.

Once the new software is loaded (issu loadversion), you can use the show issu outage slot all command to display the maximum outage time for installed modules. See the "Displaying the Maximum Outage Time for Installed Modules (Optional)" section for a command example.

Reserving Module Memory

On modules that support eFSU, the supervisor engine automatically reserves memory on the module to store the new software image (decompressed format). The amount of memory needed varies according to the module type.

Although we do not recommend it, you can enter the following command to keep the switch from reserving memory for the software preload (where slot-num specifies which slot the module is installed in):

no mdr download reserve memory image slot slot-num 

Note All modules that support eFSU preload must have at least 512 MB of memory, with enough memory free to hold the new software image. If there is insufficient free memory, eFSU does not attempt the preload, but instead resets the modules during the switchover.

To display whether or not the memory reservation was successful on a module, use the show issu outage slot all command See the "Displaying the Maximum Outage Time for Installed Modules (Optional)" section for a command example.

Error Handling for eFSU Preload

If problems occur during eFSU preload, the switch takes the following actions:

•Module crash during loadversion—The module is reset when a switchover occurs.

•Module not active when eFSU started—No power is provided to the module during the software upgrade, and the module is reset when the process ends. The same action is applied to a module that is inserted into the switch after the software upgrade process has begun.

•Module crash during run version or during rollback—The module boots with the software image version that corresponds to the software image that is present on the active supervisor engine.

eFSU Restrictions

•SX SY EFSU Compatibility Matrix

•eFSU requires two supervisor engines, one active and one standby.

•Both the active and standby supervisor engines must have enough flash memory to store both the old and new software images prior to the upgrade process.

•Images from different features sets, regardless of release, fail the eFSU compatibility check.

•When downgrading with eFSU to an earlier version of Cisco IOS Software, the configuration files fail to synchronize and the standby supervisor engine reloads unless you disable any features or functions that are not supported in the earlier version before you start the process. Remove any configuration commands that are not available in the earlier version.

•During an eFSU upgrade, the modules are restarted.

•The switch examines the old and new software images and automatically performs the appropriate process (eFSU) to upgrade the software image:

–For a patch upgrade, if the module software is the same in both the old and the new software images, because no module software upgfrade is required, the eFSU upgrades only the supervisor engine software. The system downtime is from 0 to 3 seconds.

–If the module software in the images is different, the modules are restarted or reset during the upgrade process. System downtime depends on whether the modules support eFSU (see the "Outage Time and Support Considerations" section for more information).

•The eFSU upgrade feature works with NSF/SSO. Software features that do not support NSF/SSO stop operating until they come back online after the switchover that occurs during the software upgrade.

•Release 12.2(33)SXJ and later releases support NTPv4. Earlier releases support NTPv3. With NTPv3, be aware of CSCec87418, which can cause eFSU to fail.

•All modules that support eFSU preload must have at least 512 MB of memory, with enough memory free to hold the new software image. If there is insufficient free memory, eFSU does not attempt the preload, but instead resets the modules during the switchover.

•Online insertion and replacement (OIR) is not supported during an eFSU. If you attempt to insert a new module in the switch while the upgrade is active, the switch does not provide power for the module. When the upgrade ends, the switch resets the newly inserted module.

•Do not perform a manual switchover between supervisor engines during the upgrade.

•Make sure that the configuration register is set to allow autoboot (the lowest byte of the register should be set to 2).

•Before you enter the issu abortversion command (to abort a software upgrade), make sure that the standby supervisor engine is Up (STANDBY HOT [in SSO] or COLD [in RPR]).

•The Fast Software Upgrade (FSU) process supports upgrade from earlier releases to Release 12.2(33)SXI or later releases. During this process, the module software image is also upgraded on those modules that support eFSU.

•The enhanced Fast Software Upgrade (eFSU) process supports upgrades from Release 12.2(33)SXI and rebuilds to Release 12.2(33)SXJ. During this process, the module software image is also upgraded on those modules that support eFSU.

Performing an Enhanced Fast Software Upgrade

The following sections describe the process for performing an enhanced fast software upgrade (eFSU) on the Catalyst 6500 series switch:

•Software Upgrade Process Summary For a Switch

•Preparing for the Upgrade

•Copying the New Software Image

•Loading the New Software onto the Standby Supervisor Engine

•Displaying the Maximum Outage Time for Installed Modules (Optional)

•Forcing a Switchover from Active to Standby

•Accepting the New Software Version and Stopping the Rollback Process (Optional)

•Committing the New Software to the Standby

•Verifying the Software Installation

•Aborting the Upgrade Process

Each section briefly describes a particular step in the upgrade process and provides command examples. In the command examples, important fields in the command output are shown in bold. Check these fields to verify the status of the command.

Software Upgrade Process Summary For a Switch

The following sections provide examples of the software upgrade process. To upgrade the software, perform the following tasks:

Preparing for the Upgrade

Before attempting to perform a software upgrade, be sure to review the "eFSU Restrictions" section.

To prepare for eFSU, perform the tasks in the following sections:

•Verifying the Boot Image Version and Boot Variable

•Verifying Redundancy Mode

•Verifying eFSU State

Verifying the Boot Image Version and Boot Variable

Before starting, enter the show version and show bootvar commands to verify the boot image version and BOOT environment variable, as shown in the following examples:

Router# show version | in image 

BOOT variable = disk0:image_name;

CONFIG_FILE variable =

BOOTLDR variable =

Configuration register is 0x2002

Standby is up

Standby has 1048576K/65536K bytes of memory.

Standby BOOT variable = disk0:image_name;

Standby CONFIG_FILE variable =

Standby BOOTLDR variable =

Verifying Redundancy Mode

Verify that redundancy mode is enabled and that NSF and SSO are configured. The following command example shows how to verify redundancy:

Router# show redundancy 

Redundant System Information :

------------------------------

       Available system uptime = 45 minutes

Switchovers system experienced = 0

              Standby failures = 0

        Last switchover reason = none

                 Hardware Mode = Duplex

    Configured Redundancy Mode = sso

     Operating Redundancy Mode = sso

              Maintenance Mode = Disabled

                Communications = Up

Current Processor Information :

-------------------------------

               Active Location = slot 6

        Current Software state = ACTIVE

       Uptime in current state = 44 minutes

                 Image Version = Cisco IOS Software, image_details 

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2009 by Cisco Systems, Inc.

Compiled Wed 18-Feb-09 12:48 by kchristi

                          BOOT = disk0:image_name;

                   CONFIG_FILE =

                       BOOTLDR =

        Configuration register = 0x2002

Peer Processor Information :

----------------------------

              Standby Location = slot 5

        Current Software state = STANDBY HOT

       Uptime in current state = 28 minutes

                 Image Version = Cisco IOS Software, image_details 

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2009 by Cisco Systems, Inc.

Compiled image_details 

                          BOOT = disk0:image_name ;

                   CONFIG_FILE =

                       BOOTLDR =

        Configuration register = 0x2002

Verifying eFSU State

Verify that the the ISSU state is Init, rather than an intermediate eFSU upgrade state. Enter this command:

Router# show issu state detail 

                          Slot = 6

                      RP State = Active

                    ISSU State = Load Version

                 Boot Variable = disk0:image_name

                Operating Mode = sso

               Primary Version = disk0:sierra.0217

             Secondary Version = disk0:sierra.0217

               Current Version = disk0:sierra.0217

                Variable Store = PrstVbl

                     ROMMON CV = [disk0:image_name]

                          Slot = 5

                      RP State = Standby

                    ISSU State = Load Version

                 Boot Variable = disk0:image_name

                Operating Mode = sso

               Primary Version = disk0:image_name

             Secondary Version = disk0:image_name

               Current Version = disk0:image_name

Copying the New Software Image

Before starting the eFSU process, copy the new software image to flash memory (disk0: and slavedisk0:) on the active and standby supervisor engines.

Loading the New Software onto the Standby Supervisor Engine

Enter the issu loadversion command to start the upgrade process. This command reboots the standby supervisor engine and loads the new software image onto the standby supervisor engine. When the download is complete, you are prompted to enter the runversion command.

Note Do not automatically disable the features that are not common to both images. During the standby initialization, after you enter the issu loadversion command, if there are any enabled features that are not supported on the standby supervisor engine, a message is displayed that states that the standby supervisor engine cannot initialize while this feature is enabled, and the standby supervisor engine is forced to RPR (in the load-version state).

Router# issu loadversion device:filename 

%issu loadversion executed successfully, Standby is being reloaded

When execution of the issu loadversion command completes, the standby supervisor engine is loaded with the new software image and the supervisor engine is in SSO mode. The issu loadversion command might take several seconds to complete. If you enter the show commands too soon, you might not see the information that you need.

These examples show how to check the status of the upgrade using the show redundancy and show issu state detail commands:

Router# show redundancy 

Redundant System Information :

------------------------------

       Available system uptime = 1 hour, 0 minutes

Switchovers system experienced = 0

              Standby failures = 1

        Last switchover reason = none

                 Hardware Mode = Duplex

    Configured Redundancy Mode = sso

     Operating Redundancy Mode = sso

              Maintenance Mode = Disabled

                Communications = Up

Current Processor Information :

-------------------------------

               Active Location = slot 6

        Current Software state = ACTIVE

       Uptime in current state = 59 minutes

                 Image Version = Cisco IOS Software, image_details 

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2009 by Cisco Systems, Inc.

Compiled ...

                          BOOT = disk0:image_name 

                   CONFIG_FILE =

                       BOOTLDR =

        Configuration register = 0x2002

Peer Processor Information :

----------------------------

              Standby Location = slot 5

        Current Software state = STANDBY HOT

       Uptime in current state = 3 minutes

                 Image Version = Cisco IOS Software, image_name 

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2009 by Cisco Systems, Inc.

Compiled ... 

                          BOOT = disk0:image_name 

                   CONFIG_FILE =

                       BOOTLDR =

        Configuration register = 0x2002

Router# show issu state detail 

                          Slot = 6

                      RP State = Active

                    ISSU State = Load Version

                 Boot Variable = disk0:image_name 

                Operating Mode = sso

               Primary Version = disk0:image_name 

             Secondary Version = disk0:image_name 

               Current Version = disk0:image_name 

                Variable Store = PrstVbl

                     ROMMON CV = [disk0:image_name]

                          Slot = 5

                      RP State = Standby

                    ISSU State = Load Version

                 Boot Variable = disk0:image_name 

                Operating Mode = sso

               Primary Version = disk0:image_name 

             Secondary Version = disk0:image_name 

               Current Version = disk0:image_name 

Displaying the Maximum Outage Time for Installed Modules (Optional)

Once the new software is downloaded, you can enter the show issu outage slot all command on the switch processor to display the maximum outage time for the installed modules:

Router# show issu outage slot all 

Slot # Card Type                                   MDR Mode    Max Outage Time

------ ------------------------------------------- ----------- ---------------

     1 CEF720 8 port 10GE with DFC                 WARM_RELOAD        300 secs

     2 96-port 10/100 Mbps RJ45                    RELOAD             360 secs

     4 CEF720 48 port 1000mb SFP                   RELOAD             360 secs

Slot # Reason                                      Error Number

------ ------------------------------------------- ------------

     1 PLATFORM_INIT                                          3

     2 PLATFORM_INIT                                          3

     4 PREDOWNLOAD_LC_MIMIMUM_MEMORY_FAILURE                  5

Router#

Forcing a Switchover from Active to Standby

Enter the issu runversion command to force a switchover between the active and standby supervisor engines. The standby supervisor engine, which has the new software image loaded, becomes active. The previously active supervisor engine becomes the standby and boots with the old software image (in case the software upgrade needs to be aborted and the old image restored).

Router# issu runversion 

This command will reload the Active unit.  Proceed ? [confirm] y 

A switchover between the supervisor engines occurs now. The previous standby supervisor engine becomes active and is running the new software version. The previous active supervisor engine, now the standby supervisor engine, boots with the old software.

Note At this point, the new active supervisor engine is running the new software image and the standby is running the old software image. You should verify the state of the active and standby supervisor engines as shown in the following examples (show redundancy and show issu state detail).

Router# show redundancy 

------------------------------

       Available system uptime = 1 hour, 9 minutes

Switchovers system experienced = 1

              Standby failures = 0

        Last switchover reason = user forced

                 Hardware Mode = Duplex

    Configured Redundancy Mode = sso

     Operating Redundancy Mode = sso

              Maintenance Mode = Disabled

                Communications = Up

Current Processor Information :

-------------------------------

               Active Location = slot 5

        Current Software state = ACTIVE

       Uptime in current state = 7 minutes

                 Image Version = Cisco IOS Software, image_details 

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2009 by Cisco Systems, Inc.

Compiled ... 

                          BOOT = disk0:image_name 

                   CONFIG_FILE =

                       BOOTLDR =

        Configuration register = 0x2002

Peer Processor Information :

----------------------------

              Standby Location = slot 6

        Current Software state = STANDBY HOT

       Uptime in current state = 0 minutes

                 Image Version = Cisco IOS Software, image_details 

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2009 by Cisco Systems, Inc.

Compiled Wed 18-Feb-09 12:48 by kchristi

                          BOOT = disk0:image_name 

                   CONFIG_FILE =

                       BOOTLDR =

        Configuration register = 0x2002

Router# show issu state detail 

                          Slot = 5

                      RP State = Active

                    ISSU State = Run Version

                 Boot Variable = disk0:image_name 

                Operating Mode = sso

               Primary Version = disk0:image_name 

             Secondary Version = disk0:image_name 

               Current Version = disk0:image_name 

                Variable Store = PrstVbl

                     ROMMON CV = [disk0:image_name]

                          Slot = 6

                      RP State = Standby

                    ISSU State = Run Version

                 Boot Variable = disk0:image_name 

                Operating Mode = sso

               Primary Version = disk0:image_name 

             Secondary Version = disk0:image_name 

               Current Version = disk0:image_name 

Note To complete the upgrade process, enter the issu acceptversion (optional) and issu commitversion commands (as described in the following sections).

Accepting the New Software Version and Stopping the Rollback Process (Optional)

You must either accept or commit the new software image, or the rollback timer will expire and stop the upgrade process. If that occurs, the software image reverts to the previous software version. The rollback timer is a safeguard to ensure that the upgrade process does not leave the switch nonoperational.

Note New features that are not supported by the previous image are allowed to be enabled only after you enter the issu commitversion command.

The following command sequence shows how the issu acceptversion command stops the rollback timer to enable you to examine the functionality of the new software image. When you are satisfied that the new image is acceptable, enter the issu commitversion command to end the upgrade process.

Router# show issu rollback-timer 

        Rollback Process State = In progress

      Configured Rollback Time = 00:45:00

       Automatic Rollback Time = 00:37:28

Router# issu acceptversion 

% Rollback timer stopped. Please issue the commitversion command.

View the rollback timer to see that the rollback process has been stopped:

Router# show issu rollback-timer 

        Rollback Process State = Not in progress

      Configured Rollback Time = 00:45:00

Committing the New Software to the Standby

Enter the issu commitversion command to load the new software image onto the standby supervisor engine and complete the software upgrade process. In the following example, the new image is loaded onto the standby supervisor engine in slot 5:

Router# issu commitversion 

Building configuration...

[OK]

%issu commitversion executed successfully

Note The software upgrade process is now complete. Both the active and standby supervisor engines are running the new software version.

Verifying the Software Installation

You should verify the status of the software upgrade. If the upgrade was successful, both the active and standby supervisor engines are running the new software version.

Router# show redundancy 

Redundant System Information :

------------------------------

       Available system uptime = 1 hour, 17 minutes

Switchovers system experienced = 1

              Standby failures = 1

        Last switchover reason = user forced

                 Hardware Mode = Duplex

    Configured Redundancy Mode = sso

     Operating Redundancy Mode = sso

              Maintenance Mode = Disabled

                Communications = Up

Current Processor Information :

-------------------------------

               Active Location = slot 5

        Current Software state = ACTIVE

       Uptime in current state = 15 minutes

                 Image Version = Cisco IOS Software, image_name 

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2009 by Cisco Systems, Inc.

Compiled ... 

                          BOOT = disk0:image_name 

                   CONFIG_FILE =

                       BOOTLDR =

        Configuration register = 0x2002

Peer Processor Information :

----------------------------

              Standby Location = slot 6

        Current Software state = STANDBY HOT

       Uptime in current state = 0 minutes

                 Image Version = Cisco IOS Software, image_details 

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2009 by Cisco Systems, Inc.

Compiled ... 

                          BOOT = disk0:image_name 

                   CONFIG_FILE =

                       BOOTLDR =

        Configuration register = 0x2002

Router# show issu state detail 

                          Slot = 5

                      RP State = Active

                    ISSU State = Init

                 Boot Variable = disk0:image_name 

                Operating Mode = sso

               Primary Version = N/A

             Secondary Version = N/A

               Current Version = disk0:image_name 

                Variable Store = PrstVbl

                     ROMMON CV = [disk0:simage_name ]

                          Slot = 6

                      RP State = Standby

                    ISSU State = Init

                 Boot Variable = disk0:image_name 

                Operating Mode = sso

               Primary Version = N/A

             Secondary Version = N/A

               Current Version = disk0:image_name 

Aborting the Upgrade Process

You can manually abort the software upgrade at any stage by entering the issu abortversion command. The upgrade process also aborts on its own if the software detects a failure.

If you abort the process after you enter the issu loadversion command, the standby supervisor engine is reset and reloaded with the original software.

The following is an example of the issu abortversion slot image command that shows how to abort the software upgrade process:

Router# issu abortversion 6 c7600s72033 

Note Before you enter the issu abortversion command, make sure that the standby supervisor engine is Up (STANDBY HOT [in SSO] or COLD [in RPR]).

Performing an eFSU Upgrade on an Installed Modular Image

The following sections describe the process for performing an enhanced fast software upgrade (eFSU) on an Installed Modular Image (ION):

•Upgrading an Installed Modular Image

•Example an eFSU Upgrade on an Installed Modular Image

Upgrading an Installed Modular Image

To perform an eFSU upgrade (or downgrade) of an ION VSS, perform this task:

	Command	Purpose
Step 1	Router# copy tftp disk_name	Uses TFTP to copy the new software image to flash memory on the active and standby chassis (disk0: and slavedisk0:). Answer the prompts to identify the name and location of the new software image. Note It is best to have a console on both the active and standby supervisor engines as you will go back and forth between them.
Step 2	Router# install file bootdisk:filename bootdisk:/location	Installs the modular image onto both the active and standby supervisor engines.
Step 3	Router# show issu state [switch/slot][detail]	Verifies the status of the upgrade process; status should display `Init'.
Step 4	Router# issu loadversion new-image	Starts the upgrade process by loading the installed software image onto the active and standby chassis. The image name includes the path of the target image to be loaded, in the format devicename:filename. It may take several seconds for the new image to load and for the standby chassis to transition to SSO mode. Note This command will cause the standby chassis to reload.
Step 5	Router# show issu state [switch/slot][detail]	Verifies the status of the upgrade process; status should display `Load Version'.
Step 6	Router# issu runversion	Forces a switchover, causing the standby chassis to become active, and begins running the new software. The previously active chassis becomes standby and boots with the old image.
Step 7	Router# show issu state [switch/slot][detail]	Verifies the status of the upgrade process; status should display `Run Version'.
Step 8	Router# issu commitversion	Loads the new software image onto the standby chassis. Note This command will cause the standby chassis to reload.
Step 9	Router# show issu state [switch/slot][detail]	Verifies the status of the upgrade process; status should display `Init'.
Step 10	Router# redundancy force-switchover	(Optional) Forces the standby Route Processor (RP) to assume the role of the active RP.

For an example of the eFSU upgrade on an Installed Modular Image sequence, see the "Example an eFSU Upgrade on an Installed Modular Image" section.

Example an eFSU Upgrade on an Installed Modular Image

This example shows how to perform an an eFSU upgrade on an Installed Modular Image.

Router# copy ftp://172.18.108.26/image_name sup-bootdisk:simage_name 

Router# copy ftp://172.18.108.26/image_name slavesup-bootdisk:image_name 

Router# install file sup-bootdisk:image_name sup-bootdisk:/newsys 

Router# install file slavesup-bootdisk:image_name slavesup-bootdisk:/newsys

Router# show issu state 

                      Slot = 1/6 

                  RP State = Active 

                ISSU State = Init 

             Boot Variable = bootdisk:/sys/s72033/base/image_name ,12; 

                      Slot = 2/6 

                  RP State = Standby 

                ISSU State = Init 

             Boot Variable = bootdisk:/sys/s72033/base/image_name ,12; 

Router# issu loadversion sup-bootdisk:/newsys/s72033/base/image_name 

%issu loadversion executed successfully, Standby is being reloaded 

Router# show issu state 

                      Slot = 1/6 

                  RP State = Active 

                ISSU State = Load Version 

             Boot Variable = bootdisk:/sys/s72033/base/image_name ,12; 

                      Slot = 2/6 

                  RP State = Standby 

                ISSU State = Load Version 

             Boot Variable = bootdisk:/sys/s72033/base/image_name ,12; 

Router# issu runversion 

This command will reload the Active unit. Proceed ? [confirm] 

Router# show issu state 

                      Slot = 2/6 

                  RP State = Active 

                ISSU State = Run Version

             Boot Variable = bootdisk:/sys/s72033/base/image_name,12; 

                      Slot = 1/6 

                  RP State = Standby 

                ISSU State = Run Version

             Boot Variable = bootdisk:/sys/s72033/base/image_name,12; 

Router# issu commitversion 

%issu commitversion executed successfully 

Router# show issu state 

                      Slot = 2/6 

                  RP State = Active 

                ISSU State = Init

             Boot Variable = bootdisk:/sys/s72033/base/image_name,12; 

                      Slot = 1/6 

                  RP State = Standby 

                ISSU State = Init

             Boot Variable = bootdisk:/sys/s72033/base/image_name,12; 

Router# redundancy force-switchover 

Upgrading a Non-eFSU Image to an eFSU Image

If the new Cisco IOS software image does not support eFSU, you must manually upgrade the software image. To do so, you must upgrade the software image on the standby supervisor engine and then perform a manual switchover so that the standby takes over processing with the new image. You can then upgrade the software image on the previously active, and now standby, supervisor engine. For more information, see the "Software Upgrade Process Summary For a Switch" section.

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:

http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Participate in the Technical Documentation Ideas forum