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 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: Embedded Wireless Controller bug fixes or Cisco Product Security Incident Response information (PSIRT).

  • These fixes or features do not require any changes to the embedded wireless controller.

  • 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 to a system after installing the SMU. SMUs can be non-traffic affecting or can result in device restart, reload, or switchover.

Controller hot patching support allows SMU to be effective immediately after activation without reloading the system. Other controller SMUs require a cold reload of the system during activation. A cold reload is the complete reload of the operating system.

This action affects the traffic for the duration of the following two phases:

  • The reload of the wireless controller.

  • The time it takes for all the access points to rejoin the controller, receive the new image from the controller, and upgrade to the new SMU patch. This reload ensures that all processes are started with the correct libraries and files that are installed as part of the SMU.

After the SMU is committed, the activation changes are persistent across reloads.

Overview of Controller SMUs

The following table describes the SMU types supported in the Cisco Embedded Wireless Controller:

Table 2. Supported SMU Types in the Embedded Wireless Controller

Package Type

Use Case

SMU Type

Supported on EWC

Controller SMU - Cold Patch

Replace impacted binaries, libraries, or subpackages.

Reload

Limited support (Patch size < 20 MB). No support for IOSD.

Controller SMU - Hot Patch

Replace impacted functions.

Nonreload

Yes

APSP

AP fix by replacing the AP image (does not impact the AP running the active controller).

Nonreload

Yes

APSP

AP fix by replacing the AP image (impacts the AP that is running the active controller).

Reload

Yes (EWC specific variation)

APDP

New AP model support without upgrading the controller.

Nonreload

Yes

Managing Controller Hot or Cold SMU Package

Procedure

  Command or Action Purpose

Step 1

install add file tftp: //<server-ip>/<path>/<smu-filename>

Example:

Device# install add file tftp://<server-ip>/<path>/<smu-filename>

The install add command copies the file from the external server to the backup_image directory on the embedded wireless controller.

Step 2

install activate file backup_image: smu-filename

Example:

Device# install activate file backup_image:<smu-filename>

This command is used to activate the patch. The install activate causes the controller reload only for a cold patch. There is no reload for a hot patch.

Step 3

install auto-abort-timer stop

Example:

Device# install auto-abort-timer stop

(Optional) Stops the auto cancel timer in case of activated or deactivated SMUs.

Step 4

install commit

Example:

Device# install commit

Commits the activation changes to be persistent across reloads.

The commit can be done after activation while the system is up, or after the first reload. If a patch is activated and not committed, the auto cancel timer automatically cancels the activation of the patch in six hours .

Step 5

show install rollback

Example:

Device# show install rollback

Displays the list of rollback IDs that are available.

Step 6

install rollback to { base | committed | id | label } specific-rollback-point

Example:

Device# install rollback to base

Rolls back a committed patch. The committed patch can be deactivated and the commit for deactivation can be done using the single install rollback command.

Step 7

install deactivate file backup_image: smu-filename

Example:

Device# install deactivate file backup_image:<Smu-Filename>
Deactivates a comitted patch. The install deactivate command causes the reload of the controller in case of a cold patch. There is no reload of the controller in case of a hot patch.

Step 8

install auto-abort-timer stop

Example:

Device# install auto-abort-timer stop

(Optional) Stops the auto cancel timer in case of activated or deactivated SMUs.

Step 9

install commit

Example:

Device# install commit

Commits the deactivation changes to be persistent across reloads.

Step 10

install remove file backup_image: smu-filename

Example:

Device# install remove file backup_image:<smu-filename>
Removes a patch that is in the inactive state. This command also removes the file physically from backup-image:

Step 11

install abort

Example:

Device# install abort

Cancels the upgrade by resetting the APs in rolling fashion.

Step 12

show install summary

Example:

Device# show install summary

Displays information about the active package.

The output of this command varies based on the packages, and the package states that are installed.

Step 13

show install package backup_image: smu-filename

Example:

Device# show install package backup-image: <smu_filename>

Displays information about the SMU package.

Configuration Examples for SMU

The following is sample of the SMU configuration:

Device# install add file tftp://10.1.1.2/auto/tftpboot/user1/ewc/ewc-apsp1.bin
install_add: START Tue Jun 4 15:08:26 UTC 2019
Downloading file tftp://10.1.1.2/auto/tftpboot/user1/ewc/ewc-smu.bin
Finished downloading file tftp://10.1.1.2/auto/tftpboot/user1/ewc/ewc-smu.bin to backup_image:ewc-smu.bin
install_add: Adding SMU
install_add: Checking whether new add is allowed ....
install_add: ap image predownload is allowed.

--- Starting initial file syncing ---
Info: Finished copying backup_image: ewc-smu.bin to the selected chassis
Finished initial file syncing

--- Starting SMU Add operation ---
Performing SMU_ADD on all members
[1] SMU_ADD package(s) on chassis 1
MEWLC response success sync_successCumulative SMU Size: 24 KB
Cumulative size of all SMU's will not exceed 20000 KB
Available Memory in /backup_image is 251480 KB
Available memory 251480 KB is greater than available memory required 2000 KB
[1] Finished SMU_ADD on chassis 1
Checking status of SMU_ADD on [1]
SMU_ADD: Passed on [1]
Finished SMU Add operation

SUCCESS: install_add
Device# install activate file backup_image:ewc-apsp1.bin
install_activate: START Tue Jun 4 15:18:58 UTC 2019
install_activate: Activating SMU
Cumulative SMU Size: 24 KB
Cumulative size of all SMU's will not exceed 20000 KB
Available Memory in /backup_image is 250984 KB
Available memory 250984 KB is greater than available memory required 2000 KB
MEWLC response success sync_successExecuting pre scripts....
Executing pre sripts done.

--- Starting SMU Activate operation ---
Performing SMU_ACTIVATE on all members
ls: cannot access '/tmp/sw/fp/*/*/*/mount/.pkginfo': No such file or directory
ls: cannot access '/tmp/sw/fp/*/*/*/mount/.pkginfo': No such file or directory
[1] SMU_ACTIVATE package(s) on chassis 1
valid
install_activate: FP fp error skipping. Platform to fix this in Fru List
[1] Finished SMU_ACTIVATE on chassis 1
Checking status of SMU_ACTIVATE on [1]
SMU_ACTIVATE: Passed on [1]
Finished SMU Activate operation

Executing post scripts....
Executing post scripts done.
Executing post scripts....
Executing post scripts done.
SUCCESS: install_activate /backup_image/ewc-apsp1.bin
Device#install commit
install_commit: START Tue Jun 4 16:15:25 UTC 2019
install_commit: Committing SMU
Executing pre scripts....
install_commit:
Executing pre sripts done.
--- Starting SMU Commit operation ---
Performing SMU_COMMIT on all members
ls: cannot access '/tmp/sw/fp/*/*/*/mount/.pkginfo': No such file or directory
ls: cannot access '/tmp/sw/fp/*/*/*/mount/.pkginfo': No such file or directory
[1] SMU_COMMIT package(s) on chassis 1
valid
[1] Finished SMU_COMMIT on chassis 1
Checking status of SMU_COMMIT on [1]
SMU_COMMIT: Passed on [1]
Finished SMU Commit operation

Waiting for the platform to set the SMU sync timerSMU sync status is sync_successSMU sync to AP's success 
/tmp/rp/chasfs/wireless/wlc_notify
SUCCESS: install_commit /backup_image/ewc-apsp1.bin
Device#install rollback to base
install_rollback: START Tue Jun 4 16:42:24 UTC 2019
install_rollback: Rolling back SMU
Executing pre scripts....
install_rollback:
Executing pre sripts done.

--- Starting SMU Rollback operation ---
Performing SMU_ROLLBACK on all members
ls: cannot access '/tmp/sw/fp/*/*/*/mount/.pkginfo': No such file or directory
ls: cannot access '/tmp/sw/fp/*/*/*/mount/.pkginfo': No such file or directory
[1] SMU_ROLLBACK package(s) on chassis 1
[1] Finished SMU_ROLLBACK on chassis 1
Checking status of SMU_ROLLBACK on [1]
SMU_ROLLBACK: Passed on [1]
Finished SMU Rollback operation

Executing post scripts....
Executing post scripts done.
Waiting for the platform to set the SMU sync timerSMU sync status is sync_successSMU sync to AP's success 
/tmp/rp/chasfs/wireless/wlc_notifyExecuting post scripts....
Executing post scripts done.
SUCCESS: install_rollback /backup_image/ewc-apsp1.bin Tue Jun 4 16:43:01 UTC 2019
Device# install deactivate file backup_image: ewc-apsp1.bin
install remove file backup_image:ewc-apsp1.bin
Device#show install sum
[ Chassis 1 ] Installed Package(s) Information:
State (St): I - Inactive, U - Activated & Uncommitted,
C - Activated & Committed, D - Deactivated & Uncommitted
--------------------------------------------------------------------------------
Type St Filename/Version
--------------------------------------------------------------------------------
APSP C backup_image:ewc-apsp1.bin
IMG C 17.1.1.0.69043

--------------------------------------------------------------------------------
Auto abort timer: inactive
--------------------------------------------------------------------------------

Rolling AP upgrade

A rolling AP upgrade is an upgrade method that

  • updates APs in staggered batches such that some APs are always up in the network and provide seamless coverage to clients while the other APs are selected to be upgraded, and

  • requires preloading the image in advance to ensure that all APs scheduled for upgrade have the new version.

Rolling AP upgrade process

Summary

Rolling AP upgrade is done on a per controller basis. The number of APs to be upgraded at a given time is a percentage of the total number of APs connected to the controller. The percentage is capped at a user configured value. The default percentage is 15. Upgrade all non-client APs before upgrading any client APs.

The key components involved in the process are:

  • Controller

  • APs

  • Clients

Workflow

The process involves the following stages:

  1. Candidate AP set selection:

    In this stage, a set of AP candidates is selected based on neighboring AP information. For example, if you identify an AP for upgrade, a certain number (N) of its neighbors are excluded from candidate selection. The N values are generated in the following manner:

    If the user configurable capped percentage is 25%, then N=6 (Expected number of iterations =5)

    If the user configurable capped percentage is 15%, then N=12 (Expected number of iterations=12)

    If the user configurable capped percentage is 5%, then N=24 (Expected number of iterations =22)

    If you cannot select candidates using neighboring AP information, select candidates from indirect neighbors. If this still fails, the AP is upgraded without failure.


    Note

    If you have more candidate APs than the configured percentage allows, remove the extra candidates to maintain the percentage cap.

  2. Client steering:

    Move clients connected to candidate APs to other APs before rebooting the candidate APs. Each AP sends a request to its associated clients, providing a list of the best available APs (excluding candidate APs). The system marks candidate APs as unavailable for neighbor lists and resets these markings during the AP rejoin and reload process.

  3. AP rejoin and reload process:

    After steering clients, if any clients remain connected to the candidate AP, de-authorize those clients and reload the AP so it restarts with a new image. Set a three-minute timer for the APs to rejoin. When the timer expires, check if all candidate APs have joined the controller or mobility peer. If 90% have joined, end the iteration. If not, extend the timer by three minutes and check again. After three attempts, start the next iteration. Each iteration usually lasts about 10 minutes.

    You only need to configure the number of APs to upgrade at a time as a percentage of the total APs in the network. The default is 15 percent. 

    Device(config)# ap upgrade staggered {25 | 15 | 5}

Verifying AP Upgrade on the Controller

Use the following show command to verify the AP upgrade on the controller: 

Device# show ap upgrade
AP upgrade is in progress

From version: 17.1.0.6
To version: 17.1.0.99

Started at: 06/04/2019 15:19:32 UTC
Configured percentage: 15
Percentage complete: 0
Expected time of completion: 06/04/2019 16:39:32 UTC

Progress Report
---------------
Iterations
----------
Iteration Start time End time AP count
------------------------------------------------------------------------------------------------
0 06/04/2019 15:19:33 UTC 06/04/2019 15:19:33 UTC 1
1 06/04/2019 15:19:33 UTC ONGOING 1

Upgraded
--------
Number of APs: 1
AP Name Ethernet MAC Iteration Status Site
----------------------------------------------------------------------------------------------------
AP7069.5A74.7604 7069.5a78.5580 0 Not Impacted default-site-tag

In Progress
-----------
Number of APs: 1
AP Name Ethernet MAC
-------------------------------------------------
APB4DE.3169.7842 4c77.6dc4.a220

Remaining
---------
Number of APs: 0

AP Name Ethernet MAC
-------------------------------------------------

APs not handled by Rolling AP Upgrade
-------------------------------------
AP Name Ethernet MAC Status Reason for not handling by Rolling AP Upgrade

AP Device Pack (APDP) and AP Service Pack (APSP)

APSP and APDP

AP Service Pack (APSP) - APSP rolls out fixes to AP images for one or more AP models. Pre-download the AP images and activate (through rolling upgrade) these images to a subset of AP models.

  • Patched APs run a different CAPWAP version than the rest of the APs. For e.g. 17.1.0.100 and 17.1.0.0.

  • Per site APSP rollout is not supported. In embedded wireless controller APSP all APs must be in a single default site.

AP Device Pack (APDP) -

Currently, when a new AP hardware model is introduced, those get shipped along with the corresponding embedded wireless controller related major software version. Then you need to wait for the release of a corresponding embedded wireless controller version relative to the new AP model and upgrade the entire network.

APDP allows you introduce the new AP model into your wireless network using the SMU infrastructure without the need to upgrade to the new embedded wireless controller version.

AP Image Changes -

When new AP models are introduced, there may or may not be corresponding new AP images. This means that AP images are mapped to the AP model families. If a new AP model belongs to an existing AP model family then you will have existing AP image entries (Example: ap3g3, ap1g5, and so on). For instance, if an AP model belongs to either ap3g3 or ap1g5, the respective image file is bundled with APDP SMU zip file. The corresponding metadata file is updated with the new AP model capability information including the AP image that it requires.

If a new AP model belongs to a new AP model family, a new image file would be bundled in the APDP SMU zip file. The corresponding metadata file is updated with the new AP model capability information including the AP image that it requires.

Information about APSP and APDP

SMU AP images are not part of the SMU binary, and the AP images are hosted outside the contoller.

  • Only SFTP and TFTP methods are supported for SMU AP image download.

  • HTTP, HTTP, and CCO methods are not supported for APSP or APDP.

A SMU package contains the metadata that carry AP model and its capability related details.


Note
All the zipped files are required in order to successfully proceed with the upgrade. All the contained files in the zip folder are made accessible through the download method.
Following are the pre-requisites for TFTP/SFTP software upgrade:

  • A TFTP/SFTP server is reachable from the management IP address of the embedded wireless controller.

  • The upgrade bundle with the AP images (ap1g6, ap1g6a, ap1g7, ap3g3, and so on) and the controller image (C9800-AP-iosxe-wlc.bin) that is downloaded from the website is unzipped and copied onto the TFTP/SFTP server.

Managing APSP and APDP

AP images are hosted outside the wireless controller. In the embedded wireless controller, only TFTP or SFTP is supported for SMU AP image download.

Configuring the APSP and APDP Files (GUI)

Follow the steps given below to add APSP or APDP files:

Procedure

Step 1

Choose Administration > Software Management > AP Service Package (APSP) or AP Device Package (APDP).

The Add an AP Device Package or Add an AP Service Package window is displayed.

Step 2

From the Transport Type drop-down list,

  • TFTP: Specify the Server IP Address (IPv4/IPv6), File Path, File Name, and File System.
  • SFTP: Specify the Server IP Address (IPv4/IPv6), Port Number (Default port number is 22), SFTP username and password, File Path, File Name, and File System.

Step 3

Click Add File.

Configuring the TFTP Server Directory

To set up the TFTP server directory, complete the following steps:

Procedure

  Command or Action Purpose

Step 1

configure terminal

Example:

Device#configure terminal

Enter the configuration mode.

Step 2

wireless profile image-download default

Example:

Device(config)#wireless profile image-download default

Configures EWC-AP image download parameters. Use only default as the image download profile name.

Step 3

image-download-mode { tftp | sftp}

Example:

Device(config-wireless-image-download-profile)#image-download-mode tftp

Configures image download using TFTP.

Step 4

tftp-image-path tftp-image-path

Example:

Device(config-wireless-image-download-profile-tftp)#tftp-image-path /tftpboot/cisco/ewc/

Configures the TFTP server root directory for the AP images.

Step 5

tftp-image-server { A.B.C.D | X:X:X:X::X}

Example:

Device(config-wireless-image-download-profile-tftp)#tftp-image-server 5.5.5.5

Configures the TFTP server address.

What to do next

  • Set up the remote server directory: When you receive the complete bundle in a zip file, copy the zip file to a root directory, for example, /tftpboot/user/ewc. Example of the complete bundle - /tftpboot/user/ewc/17.1.zip.

  • Unzip the file. The following are the examples of the files that will be present in the root directory: ap3g3, ap1g4, C9800-AP-iosxe-wlc.bin, and so on.


Note

When there is an issue and you want to patch an APSP SMU based on the 17.1 patch file C9800_AP.17_1.22.CSCvr11111.apsp.zip is pasted in the same root folder, that is, /tftproot/user/ewc/C9800_AP.17_1.22.CSCvr11111.apsp.zip. When you unzip the file, a sub-directory, for example, /tftpboot/user/ewc/17_1.22.CSCvr11111/ is created automatically. The AP images (for example, ap3g3) and SMU binary (apsp_CSCvr11111.bin) are present in that sub-directory.

Configuring the SFTP Server Directory

To set up the SFTP server directory, complete the following steps:

Procedure

  Command or Action Purpose

Step 1

configure terminal

Example:

Device#configure terminal

Enter the configuration mode.

Step 2

wireless profile image-download default

Example:

Device(config)#wireless profile image-download default

Configures EWC-AP image download parameters. Use only default as the image download profile name.

Step 3

image-download-mode { tftp | sftp}

Example:

Device(config-wireless-image-download-profile)#image-download-mode sftp

Configures image download using SFTP.

Step 4

sftp-image-path sftp-image-path

Example:

Device(config-wireless-image-download-profile-sftp)#sftp-image-path/sftpboot/cisco/ewc/

Configures the SFTP server root directory for the AP images.

Step 5

sftp-image-server { A.B.C.D | X:X:X:X::X}

Example:

Device(config-wireless-image-download-profile-sftp)#sftp-image-server 5.5.5.5

Configures the SFTP server address.

Step 6

sftp-password { 0 | 8} password re-enter password

Example:

Device(config-wireless-image-download-profile-sftp)#sftp-password 0 admin

Configures the SFTP password.

Step 7

sftp-username username

Example:

Device(config-wireless-image-download-profile-sftp)#sftp-username admin

Configures the SFTP username.

What to do next

  • Set up the remote server directory: When you receive the complete bundle in a zip file, copy the zip file to a root directory, for example, /sftpboot/user/ewc. Example of the complete bundle - /sftpboot/user/ewc/17.1.zip.

  • Unzip the file. The following are the examples of the files that will be present in the root directory: ap3g3, ap1g4, C9800-AP-iosxe-wlc.bin, and so on.


Note

When there is an issue and you want to patch an APSP SMU based on the 17.1 patch file C9800_AP.17_1.22.CSCvr11111.apsp.zip is pasted in the same root folder, that is, /sftproot/user/ewc/C9800_AP.17_1.22.CSCvr11111.apsp.zip. When you unzip the file, a sub-directory, for example, /sftpboot/user/ewc/17_1.22.CSCvr11111/ is created automatically, and the AP images (for example, ap3g3) and SMU binary (apsp_CSCvr11111.bin) are present in that sub-directory.

Positive Workflow - APSP and APDP

Procedure

  Command or Action Purpose

Step 1

install add file {tftp: | sftp: | backup_image:} apsp.bin

Example:

TFTP and Backup Image -
Device# install add file tftp://server_path/auto/tftpboot/user/ewc/17_1.22.CSCvr11111/apsp_CSCvr11111.bin
Device#install add file backup-image:apsp_CSCvr11111.bin

The install add command copies the file from the external server to the backup_image directory on the embedded wireless controller.

Step 2

ap image predownload

Example:

Device# ap image predownload

This command is optional. The command predownloads the AP image. If the predownload has started, ensure that it completes before step 3 is initiated.

Step 3

install activate file backup-image: apsp.bin

Example:

Device# install activate file backup-image:apsp.bin

This command starts the rolling AP upgrade.

Note

 

For APDP, after activate, the EWC Controller allows APs of the new AP model to join, and get the newly installed SMU AP image.

Step 4

install commit

Example:

Device# install commit

Commits the activation changes to be persistent across reloads.

The commit can be done after activation while the system is up, or after one reload. If a patch is activated and not committed, the auto abort timer automatically cancels the activation of the patch in six hours .

Rollback and Cancel

One-Shot Rollback

Procedure

  Command or Action Purpose

Step 1

show install rollback

Example:

Device# show install rollback

Displays the possible rollback points.

Step 2

install rollback to { base | committed | id | label } specific-rollback-point

Example:

Device# install rollback to base

This command triggers the Rolling AP upgrade. Rolling upgrade works for all APs that have the required image. Rest of the APs are rebooted together.

Rolls back a committed patch. The committed patch can be deactivated and the commit for deactivation can be done using the single install rollback command.

Multi-Step Rollback

Procedure

  Command or Action Purpose

Step 1

show install profile

Example:

Device# show install profile

The show install profile command displays the profiles corresponding to the rollback points.

Step 2

install add profile profile-rollback-point

Example:

Device# install add profile profile-rollback-point

This command prepares the wireless module for the predownload step corresponding to the rollback point.

Step 3

install rollback to { base | committed | id | label } specific-rollback-point

Example:

Device# install rollback to base

This command triggers the Rolling AP upgrade. Rolling upgrade works for all APs that have the required image. Rest of the APs are rebooted together.

Rolls back a committed patch. The committed patch can be deactivated and the commit for deactivation can be done using the single install rollback command.

One-Shot Cancel

The following command is used for the One-Shot manual cancel:

Procedure

  • install abort

    Example:

    Device# install abort

    This command triggers rolling AP upgrade. Cancel is allowed only if commit is not yet completed. With One-Shot Cancel there is no predownload step. Rolling AP upgrade works for all APs which have the required image. Rest are rebooted together.

Automatic Timer-Based One-Shot Cancel

After activation, a default 6-hour cancel timer is started. The cancel timer can be set to a different value when the activate command is issued, through the auto-abort-timer parameter. When the cancel timer expires, cancellation is performed the same way as the manual cancellation.

Configuring Rollback (GUI)

Follow the steps given below to configure rollback for APSP and APDP:

Procedure

Step 1

Choose Administration > Software Management .

Step 2

Select either AP Service Pack (APSP) or AP Device Pack (APDP).

Step 3

From the Rollback to drop-down list, choose the Rollback type as Base or Committed.

Step 4

Click Submit.

Verify APDP on the Embedded Wireless Controller

To verify the status of APDP packages on the embedded wireless controller, use the command: 

Device# show install summary

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

Note

The output of this command varies based on the packages, and the package states that are installed.