Release 15.5SY Supervisor Engine 2T Software Configuration Guide

eFSU Operation

eFSU is an enhanced software upgrade procedure. 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 WS-X67 xx modules modules support eFSU preload. 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.

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

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.

Secure Field Programmable Gate Array

Secure Field Programmable Gate Array (FPGA) is a feature to protect Gold region of FPGA Serial Peripheral Interface (SPI) flash. FPGA prevents any modifications to Gold region of FPGA flash. Cisco IOS achieves this by bundling the latest secure FPGA image and auto-upgrading the Gold and Upgrade regions of FPGA flash to this image.

Note Secure FPGA is available only on C6816-X-LE, C6832-X-LE, C6824-X-LE-40G, C6840-X-LE-40G, Sup6T, C6800-32P10G, C6800-16P10G, C6800-8P10G, and C6800-8P40G-XL switching modules.

Prior to Release 15.5(1)SY4, in the auto-upgrade procedure, Cisco IOS checks the running version of Gold region or Upgrade region, whichever applicable, of FPGA flash on the device and compares it with Bundled version of FPGA image in Cisco IOS. If the Bundled version is a later image than the running version, only Upgrade region of FPGA flash gets upgraded.

Starting with Release 15.5(1)SY4, Cisco IOS upgrades both the Gold and Upgrade versions of FPGA flash to ensure that the Secure FPGA support will be available in both regions.

• Once the auto-upgrade procedure starts, Cisco IOS checks if the Secure FPGA supported FPGA flash is running. If not, IOS upgrades both the Gold and Upgrade flash regions. Gold region upgrade is done only once and is not overwritten any time later.
• If the Secure FPGA supported FPGA flash is already running, the running version is then compared with the Bundled version maintained in Cisco IOS. If the running version is not an image later than the Bundled version, then the Upgrade region of FPGA flash is upgraded to the Bundled version and Cisco IOS proceeds with the power cycle.
• In case of an ISSU image upgrade, Cisco IOS skips FPGA upgrade during the ISSU cycle in order to ensure smooth ISSU transition. This eliminates additional downtime that results from upgrades in both Gold and Upgrade regions. Manual reload of Supervisor Engines needs to be done after an ISSU cycle to ensure that the latest FPGA flash starts running.

See Performing FPGA Upgrade section for information about how to perform FPGA upgrade after an ISSU cycle.

eFSU Summarized Procedure

This task is a summarized procedure for an eFSU:

Preparing for the Upgrade

• Verifying the Boot Image Version and Boot Variable
• Verifying Redundancy Mode
• Verifying eFSU State

Note Before attempting to perform a software upgrade, be sure to review the “Restrictions for eFSU” section.

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:

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:

Verifying eFSU State

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

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

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:

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:

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

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

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.

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

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:

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.

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:

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 FPGA Upgrade

When an FPGA upgrade is available, you see a console warning message during an ISSU cycle about a pending FPGA upgrade. The following is a sample warning message about a pending FPGA upgrade:

You must complete the ISSU cycle before proceeding to upgrade FPGA. After the ISSU cycle is completed, follow the below procedure as per the switching module.

For C6816-X-LE, C6832-X-LE, C6824-X-LE-40G, C6840-X-LE-40G, Sup6T Switching Modules

Reset the stand-by supervisor engine by running the redundancy reload peer command on the active supervisor engine. During bootup, secure FPGA supported image is auto-upgraded by Cisco IOS on standby supervisor engines. Once the supervisor engine is in SSO mode, run the redundancy force-switchover command to reboot the active supervisor engine. This auto-upgrades FPGA on all modules to the latest FPGA image.

For C6800-32P10G, C6800-16P10G, C6800-8P10G and C6800-8P40G-XL Switching Modules

Once the module is online, run the following command on the switch processor of the supervisor engine to upgrade the Gold region of FPGA flash:

Note The gold keyword is a hidden keyword in the upgrade winters-flash command for both VSS and non-VSS cases and does not show up on the CLI. You must explicitly run the upgrade winters-flash command with the gold keyword to upgrade the Gold region of FPGA flash.

Once the Gold region upgrade is successful, run the following command to upgrade the Upgrade region of FPGA flash:

Note When you run the upgrade winters-flash command, the console is not available until the FPGA upgrade process is completed. The upgrade process takes around five minutes to complete.

Once the upgrade is completed, run the following command to reload the specific module for the latest FPGA images to take effect:

Note The upgrade winters-flash commands must be run only when Cisco IOS shows the ‘UPDATE REQUIRED’ console warning.

Note Do not perform any other operation on the module until the FPGA upgrade is completed and the module is operational again.