Upgrade the Catalyst 9800 WLC | Quick Start Guide

Introduction

This document describes the different methods that you can use to upgrade your wireless controller(s) and how to pick the right one for you.

Requirements

Cisco recommends that you have knowledge of these topics :

• Catalyst 9800 Wireless LAN Controller (WLC)
  
  

Components used

This document is not restricted to specific software and hardware versions. The information in this document was created from the devices in a specific lab environment. All devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Requirements and verifications

This document does not describe every requirement and verification to make, because it depends on the type of upgrade that you would like to perform. However, there are a few checks to make before every upgrade to avoid any issues :

1. Verify the upgrade path: make sure that you can upgrade to a specific version by going to the Release Note (RN) document of the version you would like to upgrade to. Every RN contains a “Upgrade Path” section where you can verify if you upgrade path is supported. Example of upgrade path for version 17.12.X here : https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-12/release-notes/rn-17-12-9800.html#Cisco_Concept.dita_59a2987f-2633-4630-8c7b-a8e8aecdeaf7
2. Verify the AP compatibility: make sure that APs joined to your controller are compatible with the version that you plan to upgrade to. You can refer to the compatibility matrix (https://www.cisco.com/c/en/us/td/docs/wireless/compatibility/matrix/compatibility-matrix.html#c9800-ctr-ap_support) to ensure that your AP models are compatible.

Note: You can always find the current recommended version on this frequently updated document : Recommended Cisco IOS XE Releases (https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/214749-tac-recommended-ios-xe-builds-for-wirele.html)

Upgrade procedure

The procedure to upgrade the wireless controller(s) can depend if it is a standlone controller or an HA pair (SSO or N+1 redundancy). In this document, you find a brief overview of the different upgrade procedures.

Standalone controllers

Upgrading a standalone controller requires downtime, since the controller reloads during the upgrade. However, you can reduce this downtime by pre-downloading the image to the access points. This avoids the APs to start downloading the image after the controller is upgraded. This removes the downtime needed for image download, which can take several minutes or hours depending if the APs are on a WAN link and depending on the CAPWAP window size configured. It is generally recommended to pre-download the images to the access points before the upgrade of the controller. 

CLI Workflow

This section shows a brief summary of the commands executed to upgrade the controllers. A complete explanation of each commands and all steps is provided:

Procedure

Here is the procedure to upgrade a standalone controller with AP pre-download. The procedure shows the CLI commands to do the upgrade, and you can also find instructions for the GUI.

Step 0 (Optional) : Delete unused files

You can start by removing inactive files from the controller to free up some space, if needed:

install remove inactive

Note: this operation can take several minutes to complete. Do not proceed further until this operation is finished.

Step 1: Upload the image to the controller

Download the ".bin" image on this link : https://software.cisco.com/download/find/9800. You can upload the downloaded .bin image to the controller using ftp/sftp/tftp/http method this command:

copy tftp|ftp|sftp://<SERVER_IP>/<IMAGE_PATH> bootflash:

Note : verify the md5/sha512 hash of the image using this command on the controller :

verify /md5|/sha512 <IMAGE_PATH>

Step 2: Install the image on the controller

The first step is to “install” the image on the controller. This does not require a reload.

install add file bootflash:<IMAGE_NAME>

Once this is completed, you see the image listed as “Inactive” using this command:

show install summary

At this point, you can start pre-downloading the images to the APs. If you don’t pre-download the APs, then APs have to download the image after the controller upgraded.

Step 3: Pre-download the image to the APs

To trigger the AP pre-download, use this command:

ap image pre-download

To verify the pre-download status, you can use the “show ap image” command. You need to wait for all APs to have downloaded the new image before proceeding to next step. This can take several minutes/hours depending on the number of APs you have and depending on the latency between the APs and the WLC.

Step 4: Activate the image

Once the pre-download is finished, you can “activate” the image. This reloads the controller and the controller boots on the new installed image.

install activate

Once the WLC is reachable, the APs detects the new image and swaps to the backup partition and reloads on the new version.

On the 9800 controller, you can verify the new image is in U state (Activated & Uncommitted). If you want to make the new image persistent, you need to commit the image, otherwise the controller reloads once the auto-abort timer is over (default is 6 hours).

Step 5: Commit the image

To commit the image, perform this command:

install commit

GUI instructions

If you want to upgrade the wireless controller using the GUI, you can go to Administration > Software Upgrade and configure the upgrade parameters. You can choose to upload the .bin file directly from your desktop or load it from a TFTP/SFTP/FTP server. You can also choose to pre-download the APs or not. Once everything is configured, you can click on “Download and Install”, which corresponds to step 1-3 stated previously. Optionally, you can also click on the “Remove Inactive Files” button to remove unused file before uploading the new image. This corresponds to the optional step 0.

You can monitor the progress of the AP pre-download by clicking on the “Show logs” button under the status section on right hand side.

Once the image upload and install of the image is done, you can click on “Save configuration & Activate” button. This saves the configuration and start the upgrade of the controller. This corresponds to step 4.

Once the session has timed out, you can login again to the controller, navigate to Administration > Software Upgrade and click on the “Commit” button that is now available. This corresponds to step 5.

Once the APs detect the controller is reachable again, they start to reload on the backup partition and join the controller running on the new version.

Controllers in High Availability (HA)

Wireless controllers have multiple ways to be redundant. You can have an HA SSO (Stateful Switch Over) pair, a N+1 redundancy, or both.

• HA SSO: there is an active and standby controller with continuous synchronization between the WLCs.
• N+1: there is a primary and secondary controller, but they are not interconnected. Both controllers must be running the same version and must be configured identically for this to work seamlessly. APs are joined to the primary controller and falls back to the secondary controller in case of failure of the primary controller. 

Stateful Switch Over (SSO) redundancy

When controllers are in HA SSO mode, you have 2 mains ways to upgrade them. You can either do a “classic” upgrade or an ISSU (In-Service Software Upgrade).

• “Classic” upgrade: this is the same upgrade process explained previously for standalone controllers. Both controllers reload at the same time, and APs reload on the new version. You can decide to pre-download the AP image or not. Total downtime for this upgrade: controller reload + AP reload time. It does not take any more time than upgrading a single standalone controller
• ISSU upgrade: this is a zero-downtime upgrade. The standby controller upgrades, there is a switchover, then the (old) active controller upgrades, and finally APs upgrade in staggered manner. Ideal for 24/7 environment where downtime must be as minimal as possible.

Classic upgrade

Please refer to the previous section under the “Standalone Controllers” section. The steps are the exact same ones. Image is copied from the active to the standby controller automatically and both controllers upgrade at the same time. Once the controllers are upgraded, the APs either swap their partition if you pre-downloaded the images to the APs, or download the new image if the pre-download was not done. 

Note: make sure that both controllers are in ACTIVE/STANDBY-HOT state before proceeding to the upgrade (using the “show redundancy” command).

ISSU upgrade

The ISSU feature allows you to reduce the downtime during an upgrade. Controllers upgrade one by one, and APs reload in staggered manner. The wireless client is able to roam between APs if there is sufficient coverage. If an AP is isolated, then there is a downtime for clients connected to such AP (the AP reload time).

This upgrade takes a much longer time in total since both controllers upgrade one at a time and APs reboot and upgrade in a staggered and controlled manner which leads to a longer total maintenance window however with no perceived downtime by the clients.

There are a few things to consider when doing an ISSU upgrade (limitations, precautions to take and so on). For a complete explanation of the ISSU procedure (with instructions and commands), please refer to this document.

N + 1 redundancy

N+1 redundancy is when you have a set of 2 controllers that are not direclty connected to each other, but are configured exaclty the same and are running the same version. In this case, we have one "primary" controller (where all the APs are joined) and a "secondary" controller, which can be used as a backup in case of primary controller failure. When you want to proceed to an upgrade, it is as if you had 2 "standalone" controllers. However, having this kind of redundancy has a big advantage, because there is a way to reduce the downtime compared to a classic upgrade using the "N+1 Hitless Rolling AP Upgrade" feature. This allows you to perform a staggered upgrade of the APs while moving them to a secondary, upgraded controller. This limits the downtime since only a small subset of APs are reloaded at the same time. 

Here is the flow for this type of upgrade :

1. Upgrade the secondary controller to the target release. This can be done with a classic upgrade, without AP pre-download since there are no APs connected to it. At that stage, primary is running V1, while secondary is running V2. 
2. Install the target image (V2) on the primary controller, but do not activate. This allows you to pre-download the V2 image to the APs.
3. Once the pre-download is finished, initiate the AP staggered upgrade using the "ap image upgrade destination" command. This triggers the staggered AP upgrade and APs reload on the V2 image and join the secondary WLC.
4. Once all APs are joined to the secondary WLC, upgrade the primary controller to V2. 
5. Once done, if needed, you can easily move the APs back to the primary controller, at your own pace. Note that this does not require a reload of the APs since both WLCs are on the same V2 version. Only a CAPWAP restart is required and this takes less than a minute.  

For a complete explanation of the "N+1 Hitless Rolling AP Upgrade" procedure (with instructions and commands), please refer to this document.

What if you have SMUs or APSPs current installed ?

You do not need to remove any SMU or APSP patch currently installed before upgrading to the next release.

References

• 17.12.X configuration guide
• ISSU upgrade
• N+1 Hitless Rolling AP Upgrade