Software Maintenance Upgrade

Software maintenance upgrade

A software maintenance upgrade (SMU) is a software package that

  • is installed on a system to provide a patch or a security fix resolution to a released image, and

  • is on a per component basis and is specific to the corresponding platform.

Feature history

This table provides release and related information about the feature explained in this section.

This feature is also available in all the releases subsequent to the one in which they are introduced in, unless noted otherwise.

Table 1. Feature history for Software maintenance upgrade

Feature Name

Release Information

Feature Description

Software maintenance upgrade

Cisco IOS XE Gibraltar 16.11.1b

This feature provides network administrators with targeted, platform-specific patches and security fixes for released images, applicable either on a per-component basis or for the entire corresponding platform.

A SMU offers significant benefits over classic Cisco IOS software. It lets you address network issues promptly and reduces required testing time and scope. The Cisco IOS XE platform validates SMU compatibility internally and prevents installation of non-compatible SMUs.

All SMUs are also integrated into subsequent Cisco IOS XE software maintenance releases. A SMU is an independent and self-sufficient package without prerequisites or dependencies. You can choose which SMUs to install or uninstall in any order.


Note
SMUs are supported only on Extended Maintenance releases and throughout the full lifecycle of the underlying software release.

Note

Activate the file using the install add file command only from the filesystems of the active device. If you use a file from the standby or member filesystems, the install add file command fails.


Note

When the SMU file is deleted and the device is rebooted, the device may display an error message such as:

--- Starting SMU Add operation ---
Performing SMU_ADD on all members
    FAILED: Improper State./bootflash/<previously-installed-smu-filename>.smu.bin not present. Please restore file for stability.
Checking status of SMU_ADD on [1/R0]
SMU_ADD: Passed on []. Failed on [1/R0]
Finished SMU Add operation
FAILED: add_activate_commit /bootflash/<tobeinstalled-wlc-smu-filename>.smu.bin Wed Aug 02 08:30:18 UTC 2023.

This error occurs because the previous SMU file was not properly removed from the controller. As a result, you may not be able to install new SMU or APSP files.

Use the install remove file command to remove previous instances of APSP or SMU files from the bootflash.

You can use SMU infrastructure to meet these requirements in wireless contexts:

  • Controller SMU: Controller bug fixes or Cisco Product Security Incident Response information (PSIRT).

  • APSP: APSP is used for AP bug fixes, PSIRTs, or minor features that do not require controller changes.

  • APDP: APDP supports new AP models without introducing new hardware or software capabilities.


Note

The show ap image command displays cumulative statistics for AP images in the controller. Clear the statistics using the clear ap predownload statistics command, before using the show ap image command, to ensure correct data is displayed.

SMU Workflow

Begin the SMU process by requesting approval from the SMU committee. Contact customer support to raise an SMU request. During the release, the SMU package is posted on the Cisco Software Download page. You can then download and install it.

Warning: Commit changes within six hours of activation or deactivation to avoid rollback

Always run the install commit command within 6 hours after executing either install activate or install deactivate .

If you do not commit changes within this window

  • the system automatically reverts to the previous commit state

  • this reversion can lead to service interruption, especially over low-bandwidth links where image transfers may not complete in time, and

  • remote deployments with slow transfer rates are particularly vulnerable.

To reduce these risks

  • run install commit after activation or deactivation

  • monitor image transfer progress proactively, and

  • plan for available bandwidth and duration at remote sites.

SMU Package

An SMU package contains the metadata and the fix for the reported issue that prompted the request.

SMU Reload

The SMU type describes the effect on a system after you install a SMU. SMUs can be non-traffic-affecting, or they can require a device restart, reload, or switchover.

A controller cold patch requires a cold reload of the system during activation. A cold reload means completely restarting the operating system.

This process affects traffic during two phases:

  • the reload of the wireless controller, and

  • the time needed for all APs to rejoin the controller, receive the new image, and upgrade to the new SMU patch. This reload ensures that all processes use the correct libraries and files installed as part of the SMU.

The reload ensures all processes use the correct libraries and files installed as part of the SMU.

With controller hot patching, a SMU is effective immediately after activation, without rebooting the system. After you commit the SMU, activation changes persist across reloads. Hot patching SMU packages contain metadata listing processes to restart for activation. During activation, each process is restarted one by one until activation completes.

Install a SMU (GUI)

Add and activate a SMU image on your device using the GUI.

Procedure

Step 1

Choose Administration > Software Management and click the Software Maintenance Upgrade tab.

Step 2

Click Add to add a SMU image.

Step 3

From the Transport Type drop-down list, select the transfer type, TFTP, SFTP, FTP, Device, or Desktop (HTTP) to transfer the software image to your device.

  1. If you choose TFTP as the Transport Type, enter the Server IP Address (IPv4/IPv6), File path and select a File System from the drop-down list. For example, if the SMU file is at the root of the TFTP server you can enter /C9800-universalk9_wlc.17.03.02a.CSCvw55275.SPA.smu.bin in the File path field.

  2. If you choose SFTP as the Transport Type, enter the Server IP Address (IPv4/IPv6), SFTP Username, SFTP Password, File path and select a File System from the drop-down list.

  3. If you choose FTP as the Transport Type, enter the Server IP Address (IPv4/IPv6), FTP Username, FTP Password, File path, and select a File System from the drop-down list.

  4. If you choose Device as the Transport Type, enter the File path and select a File System from the drop-down list. This is possible when the software is already present on the device due to an earlier download and activation, followed by a subsequent deactivation.

    Note

     
    Depending on your device, available file systems may vary. On physical controllers, store files on bootflash or hard disk. On virtual controllers, use bootflash.

  5. If you choose Desktop (HTTPS) as the Transport Type, select a File System from the drop-down list and click Select File to navigate to the Source File Path.

Step 4

Enter the File Name and click Add File.

When you complete this step, the maintenance update package is copied to the device, platform and image versions are checked for compatibility, and the SMU package is added for all members. After adding a SMU, you see a message indicating success and letting you know the SMU can be activated. The message displays the name of the package (SMU) that is available for activation. It lists the SMU details: Name, Version, State (active or inactive), Type (reload, restart, or non-reload), and other compatibility details. If the SMU type is 'reload,' any operation (activate, deactivate, or rollback) causes the device to reload. The 'restart' type involves only a process restart. If it is 'non-reload,' no process changes occur.

Step 5

Select the SMU and click Activate to activate it on the system, install the package, and update the package status details.

Step 6

Select the SMU and click Commit to make these activation changes persistent across reloads.

The Commit operation creates commit points, which are similar to snapshots. Use commit points to decide which changes to activate or roll back if you have a problem with the SMU. You can commit after activation when the system is up, or after the first reload. If a package is activated but not committed, it remains active after the first reload, but not after the second reload.

Install SMU (CLI)

Update device software with a SMU using CLI.

Procedure

Step 1

Copy the maintenance update package from a remote location to the device, and perform a compatibility check for the platform and image versions.

Example:

Device# install add file bootflash filename

This command runs base compatibility checks on a file to verify that the SMU package is supported on the platform. The command also adds an entry to the package or SMU.sta file. This entry allows you to monitor and maintain the package's status.

Step 2

Run compatibility checks, install the package and update the package status details.

Example:

Device# install activate file bootflash filename

For a restartable package, the command triggers the appropriate post-install scripts to restart the necessary processes. For non-restartable packages it triggers a reload.

Step 3

Commit the activation changes to be persistent across reloads.

Example:

Device# install commit

You can perform the commit after activation while the system is up, or after the first reload. If a package is activated but not committed, it remains active after the first reload; however, it is no longer active after the second reload.

Step 4

Display the image version on the device.

Example:

Device# show version

Step 5

Display information about the active package.

Example:

Device# show install summary

The output of this command varies according to the install commands that are configured.

Roll back an image (GUI)

Return the software image on the system to a previous stable state using the GUI.

Procedure

Step 1

Choose Administration > Software Management.

Step 2

Go to SMU, APSP or APDP.

Step 3

Click Rollback.

Step 4

In the Rollback to drop-down list, select Base, Committed or Rollback Point.

Step 5

Click Add File.

Roll back SMU (CLI)

Return the device to a previous software state by rolling back a SMU using CLI.

Procedure

Step 1

Return the device to the previous installation state.

Example:

Device(config)# install rollback to {base | committed | id | committed} committed ID id 1234

After the rollback, a reload is required.

Step 2

Commit the activation changes to be persistent across reloads.

Example:

Device# install commit

Deactivate SMU (CLI)

Deactivate an active SMU package on a network device using CLI.

Procedure

Step 1

Deactivate an active package, update the package status, and trigger a process to restart or reload.

Example:

Device# install deactivate file bootflash filename

Step 2

Commit the activation changes to be persistent across reloads.

Example:

Device# install commit

Configuration examples for SMU

This example shows the SMU configuration after the system completes the install add for the SMU.

Device# show install summary

[ Chassis 1 2 ] Installed Package(s) Information:        
State (St): I - Inactive, U - Activated & Uncommitted, C - Activated & Committed, D - Deactivated & Uncommitted --------------------------------------------------------------------------------
Type  St   Filename/Version                                                     
--------------------------------------------------------------------------------
                                                
IMG   C    16.8.1.0.39751                                                       
                                                
-------------------------------------------------------------------
Auto abort timer: inactive                                                      
-------------------------------------------------------------------