Cisco Catalyst 9800 WLC Hitless Upgrade Guide (N+1 + APSP)
The goal of this post is to share how we planned, executed, and monitored the upgrade while trying to avoid a total wireless outage for the organization. This upgrade included new WLC code and new AP code via the APSP. We usually monitor APSP releases for bugs that may affect our environment. By the time we are ready for a WLC upgrade, there is inevitably an APSP we need to consider as well. This procedure should only be attempted by someone highly familiar with Catalyst 9800 controllers.
This upgrade was performed in a 24/7 multi-hospital environment with over 100 locations and more than ~3000 access points. The code was tested for about a month on a test WLC with a collection of 8×5 clinics containing important wireless clients such as laptops, workstations on wheels, thin clients, Vocera badges, Cisco 8821 phones, Zebra handhelds, nurse call iPhones, GE patient monitoring, and radiology medical imaging devices. Testing new code is very important as there can be very serious bugs that only affect your specific deployment. Also rolling back a production WLC upgrade takes an extreme amount of time and will likely lead to downtime.
If you have comments or suggestions on how you execute this process, please leave a comment at the bottom.
Initial Environment Overview
| System | Model | Role | Base Code | APSP | Notes |
|---|---|---|---|---|---|
| WLC-prod-HA | Catalyst 9800-80 HA Pair | Primary Production WLC | 17.9.6 | 17.9.6.201 | Starting controller for the upgrade and intended final production controller after completion. |
| WLC-test | Catalyst 9800-80 Standalone | N+1 Hitless Upgrade WLC | 17.15.5 | None | Temporary AP destination during the N+1 hitless upgrade. APSP intentionally not installed yet because APSP is applied later on the primary. |
| Final Target State | Catalyst 9800-80 HA Pair | Post-upgrade production WLC | 17.15.5 | 17.15.5.201 | Final software state after base code upgrade and APSP deployment. |
High-Level Timeline
- Entire WLC base code hitless upgrade took approximately 4 hours.
- AP image predownload via CAPWAP took approximately 2 hours.
- Rolling AP move to N+1 took approximately 1 hour 40 minutes.
- Fallback to primary took approximately 20 minutes.
- APSP add took approximately 3 minutes.
- APSP predownload over HTTPS took approximately 1 hour 15 minutes.
- APSP rolling upgrade took approximately 1 hour.
- Total end-to-end maintenance window was approximately 8 hours.
Preparation Steps
- Complete change process and organization-level communication.
- Obtain the correct WLC and APSP images from Cisco.
- Validate primary HA redundancy status.
- Ensure primary and N+1 have mobility messaging set up and working.
- Ensure N+1 has the same AP upgrade configuration as the primary.
- Take WLC configuration backups.
- Export a pre-upgrade AP report to validate AP count after the upgrade.
- Obtain console access to all WLCs.
- Use AP authorization restrictions to prevent APs from joining unrelated WLCs.
Operational note: We use one person to drive the upgrade while screen sharing. Other wireless engineers monitor and support. We have run into issues in the past with multiple people using the software upgrade GUI and exhausting controller VTY ports. Treat it like flying an airplane: one pilot is flying, the others are monitoring and communicating.
Hitless N+1 WLC Upgrade
Step 1 – Validate WLC State
Validate the primary HA pair, mobility between controllers, and AP upgrade settings. The N+1 controller must have the same AP upgrade configuration. For example, if your primary WLC is set to 25% staggered iterations but your N+1 WLC is set to one-shot, APs may move to the N+1 in staggered groups but move back to the primary all at once, causing an avoidable outage.
Validate HA redundancy
Command:
show redundancyWhat to validate:
- Communications should show
Up. - The active controller should show
ACTIVE. - The standby controller should show
STANDBY HOT. - If the wrong WLC is active, use a redundancy force switchover prior to upgrade
CLI Output: show redundancy
WLC-prod-HA#show redundancy
Redundant System Information :
------------------------------
Available system uptime = 14 weeks, 6 days
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 1
Current Software state = ACTIVE
Image Version = Cisco IOS XE 17.9.6
BOOT = bootflash:packages.conf
Peer Processor Information :
----------------------------
Standby Location = slot 2
Current Software state = STANDBY HOT
Image Version = Cisco IOS XE 17.9.6
BOOT = bootflash:packages.confValidate mobility between production and N+1 WLCs
Command:
show wireless mobility summaryWhat to validate:
- The production WLC and N+1 WLC should be in a mobility group.
- The N+1 WLC should show Status
Up. - Mobility must be healthy because the WLCs coordinate AP movement and fallback using mobility messaging.
CLI Output: show wireless mobility summary
WLC-prod-HA#show wireless mobility summary
Mobility Summary
Wireless Management VLAN: 101
Wireless Management IP Address: 192.0.2.10
Mobility Control Message DSCP Value: 48
Mobility Keepalive Interval/Count: 10/3
Mobility Group Name: example-9k
Mobility Multicast Ipv4 address: 0.0.0.0
Mobility Multicast Ipv6 address: ::
Controllers configured in the Mobility Domain:
IP Public IP MAC Address Group Name Status PMTU
-------------------------------------------------------------------------
192.0.2.10 N/A xxxx.xxxx.xxxx example-9k N/A N/A
192.0.2.20 192.0.2.20 xxxx.xxxx.xxxx example-9k Up 1385
192.0.2.30 192.0.2.30 xxxx.xxxx.xxxx example-9k Up 1385
192.0.2.40 192.0.2.40 xxxx.xxxx.xxxx example-9k Up 1385Validate AP upgrade settings
Command:
show run all | i ap upgradeWhat to validate:
- The primary WLC and N+1 WLC should have matching AP upgrade behavior.
ap upgrade staggered 25means APs will be moved in rolling groups instead of all at once.- I recommend
client-steeringand/orclient-deauthbut it is up to you and how your clients will react to 802.11v or being deauthenticated right before it’s AP reloads. - Be careful with
one-shotbehavior on the N+1 WLC. A mismatch here can create the outage you were trying to avoid.
CLI Output: show run all | i ap upgrade
WLC-prod-HA#show run all | i ap upgrade
no ap upgrade method https
ap upgrade staggered 25
ap upgrade staggered client-steering
ap upgrade staggered iteration completion 90
ap upgrade staggered iteration timeout 10WLC-test#show run all | i ap upgrade
no ap upgrade method https
ap upgrade staggered 25
ap upgrade staggered client-steering
ap upgrade staggered iteration completion 90
ap upgrade staggered iteration timeout 10Step 2 – Add New WLC Image
Upload the target WLC image. From the GUI, choose the install file, set the N+1 parameters, and click Download and Install. Once this starts, there is no longer much to control until the APs have predownloaded and moved in iterations to the N+1. Your next major decision point is when to activate and reboot the now-empty primary WLC.
Once started, do not stop or abort the upgrade. If you hit an unexpected error, contact TAC rather than trying to manually fix it and potentially putting the WLC into an inconsistent state.
GUI install log excerpt
install_add: START Wed Jun 10 20:05:47 CST 2026
install_add: Adding PACKAGE
install_add: Checking whether new add is allowed ....
--- Starting initial file syncing ---
[1]: Copying bootflash:C9800-80-universalk9_wlc.17.15.05.SPA.bin from chassis 1/R0 to chassis 2/R0
[2]: Finished copying to chassis 2/R0
Info: Finished copying bootflash:C9800-80-universalk9_wlc.17.15.05.SPA.bin to the selected chassis
Finished initial file syncing
--- Starting Add ---
Performing Add on all members
[1] Add package(s) on chassis 1/R0
[1] Finished Add on chassis 1/R0
[2] Add package(s) on chassis 2/R0
[2] Finished Add on chassis 2/R0
Checking status of Add on [1/R0 2/R0]
Add: Passed on [1/R0 2/R0]
Finished Add
Image added. Version: 17.15.05.0.8370
SUCCESS: install_add Wed Jun 10 20:13:18 CST 2026Step 3 – AP Predownload
After code is installed to the WLC, the controller begins predownloading the AP image. How long this takes depends on the WLC platform, number of APs, WAN connectivity, and AP distribution across site tags and WNCD processes.
For ~3000 APs using CAPWAP image distribution, this step took about two hours. A maximum of about 800 APs were predownloading at any given time. You can see in the picture of the WLC management interface that WLC uplink utilization barely changes during this step and also makes clear why it takes so long. The AP images around around 50-100 megabytes each. Times 3000 APs, that is 150 to 300 gigabytes of data that must be transfered. HTTPS image distribution was not available for us at this stage because the starting code was 17.9.6. We used HTTPS later for the APSP after upgrading to 17.15.5.
show ap image
show ap image | i Predownloading
CLI Output: show ap image (Predownload In-Progress)
WLC-prod-HA#show ap image
Total number of APs : ~3000
Number of APs
Initiated : 0
Downloading : 0
Predownloading : 800
Completed downloading : 2301
Completed predownloading : 0
Not Supported : 0
Failed to Predownload : 0
Predownload in progress : Yes
AP Name Primary Image Backup Image Predownload Status Predownload Version Method
----------------------------------------------------------------------------------------------------------------------------------
AP-EXAMPLE-001 17.9.6.201 17.9.6.40 Predownloading 17.15.5.36 CAPWAP
AP-EXAMPLE-002 17.9.6.201 17.9.6.40 None 0.0.0.0 N/A
AP-EXAMPLE-003 17.9.6.201 17.9.6.40 Predownloading 17.15.5.36 CAPWAP
Near the end of predownload there were only a small number of APs remaining. One AP appeared stuck, so I manually rebooted it. It was marked failed and the install continued within about one minute after the AP reboot.
CLI Output: show ap image (Predownload Near Completion)
WLC-prod-HA#show ap image summary
Total number of APs : ~3000
Number of APs
Initiated : 0
Downloading : 0
Predownloading : 81
Completed downloading : 2301
Completed predownloading : 3281
Not Supported : 0
Failed to Predownload : 0
Predownload in progress : Yes
WLC-prod-HA#show ap image | i Predownloading
Predownloading : 1
Slow-AP 17.9.6.201 17.12.5.206 Predownloading 17.15.5.36 0 0 CAPWAP
Predownloading : 1
Not sure if it’s a bug or intended but this command does not respect ‘term len 0’ instead every paged output, outputs the header rows. My guess is this is due to how the GUI displays the progress popup.
Step 4 – Rolling AP Move to N+1
Once AP predownload is complete, the AP upgrade process starts moving APs in iterations to the N+1 WLC. We use 25% per iteration, which usually results in 6-8 iterations. I have graphically mapped out the iterations in the past to validate it does do a good job of rebooting APs in a way that maintains wireless connectivity. We also have had no complaints caused by the N+1 upgrades.
Useful GUI filters:
Status: In-Progress
Status is not equal to Upgraded and Joined Member
On the primary WLC, show ap upgrade shows completed, in-progress, and pending iterations. On the N+1 WLC, show ap summary gives a real-time count of APs now joined to that controller. The counters on the active WLC lagged behind what was actually connected to the N+1, and the GUI statistics dialog did not always update unless it was closed and reopened.
Command:
show ap upgradeNote: This output was captured during AP upgrade and move on the primary WLC. This is useful to monitor rolling AP movement to the N+1 WLC and validate iteration progress.
CLI Output: show ap upgrade
WLC-prod-HA#show ap upgrade
Status: In progress
Fallback type: Fallback only
From version: 17.9.6.40
To version: 17.15.5.36
Started at: 06/10/2026 22:21:13 CST
Configured percentage: 25
Percentage complete: 77
Expected time of completion: 06/10/2026 22:27:13 CST
Client steering: Enabled
Accounting percentage: 70%
Iteration expiry time: 9 minutes
Accounting action: None
Source controller: WLC-prod-HA
Destination controller: WLC-test
Progress Report
---------------
Iterations
----------
Iteration Start time End time AP count
------------------------------------------------------------------------------------------------
0 06/10/2026 22:21:13 CST 06/10/2026 22:21:13 CST 0
1 06/10/2026 22:21:13 CST 06/10/2026 22:33:19 CST 728
2 06/10/2026 22:33:19 CST 06/10/2026 22:45:28 CST 682
3 06/10/2026 22:45:28 CST 06/10/2026 22:57:33 CST 632
4 06/10/2026 22:57:33 CST 06/10/2026 23:09:39 CST 560
5 06/10/2026 23:09:39 CST ONGOING 0
Upgraded
--------
Number of APs: 3038
AP Name Radio MAC Iteration Status Site
----------------------------------------------------------------------------------------------------
AP-1-X 005d.xxxx.xxxx 1 Joined Member SiteTag1
AP-2-X 0845.xxxx.xxxx 1 Joined Member SiteTag2
AP-3-X 0845.xxxx.xxxx 1 Joined Member SiteTag3
Command:
show ap upgradeNote: This output was captured from the N+1 WLC after the final AP move iteration completed. The primary WLC was still rebooting, and this state confirms all APs are waiting for fallback.
CLI Output: show ap upgrade
WLC-test#show ap upgrade
Status: Complete, fallback awaited
Fallback type: Fallback only
From version: 17.9.6.40
To version: 17.15.5.36
Started at: 06/10/2026 22:21:13 CST
Configured percentage: N/A
Percentage complete: 100
End time: 06/10/2026 23:48:59 CST
Source controller: WLC-prod-HA
Destination controller: WLC-test
Progress Report
---------------
Iterations
----------
Iteration Start time End time AP count
------------------------------------------------------------------------------------------------
0 06/10/2026 22:21:13 CST 06/10/2026 22:21:13 CST 0
1 06/10/2026 22:21:13 CST 06/10/2026 22:33:19 CST 728
2 06/10/2026 22:33:19 CST 06/10/2026 22:45:28 CST 682
3 06/10/2026 22:45:28 CST 06/10/2026 22:57:33 CST 632
4 06/10/2026 22:57:33 CST 06/10/2026 23:09:39 CST 560
5 06/10/2026 23:09:39 CST 06/10/2026 23:21:44 CST 443
6 06/10/2026 23:21:44 CST 06/10/2026 23:33:49 CST 254
7 06/10/2026 23:33:49 CST 06/10/2026 23:42:54 CST 61
8 06/10/2026 23:42:54 CST 06/10/2026 23:48:59 CST 3
Upgraded
--------
Number of APs: 3363
AP Name Radio MAC Iteration Status Site
----------------------------------------------------------------------------------------------------
AP-1-X 005d.xxxx.xxxx 1 Joined SiteTag1
Step 5 – Activate and Commit Base Code
When all APs have moved off the primary WLC to the N+1, the GUI allows you to click Save Configuration and Activate. This reboots the now-empty primary WLC and brings it up on the WLC image 17.15.5.
In this step, the WLC appeared idle for about five minutes before it stopped responding to ping and rebooted. It was completely ping down for around 5 minutes. After it reloaded, the base image was committed from the GUI and validated with CLI. This is the step where you want WLC console access to monitor it’s progress once it is network unreachable.
show install summaryCLI Output: show install summary
WLC-prod-HA#show install summary
[ Chassis 1/R0 2/R0 ] Installed Package(s) Information:
State (St): I - Inactive, U - Activated & Uncommitted,
C - Activated & Committed, D - Deactivated & Uncommitted
--------------------------------------------------------------------------------
Type St Filename/Version
--------------------------------------------------------------------------------
IMG C 17.15.05.0.8370
--------------------------------------------------------------------------------
Auto abort timer: inactive
--------------------------------------------------------------------------------
What to validate:
- Image is status ‘C’ for Activated & Committed
- Auto abort timer is inactive
Step 6 – AP Fallback to Primary
After the primary WLC is back up and Fallback after Upgrade is enabled, APs begin moving from the N+1 back to their original upgraded WLC. This may take up to 20 minutes to begin after the WLC is reachable, so be patient.
Mobility messaging between the controllers must be working because that is how the controllers coordinate the move. This fallback was faster than the original move because the APs were already running 17.15.5 and only needed a CAPWAP restart, not a full image upgrade.
Command:
show ap upgradeNote: This output was captured on the N+1 WLC at completion of APs moving back to the primary WLC.
CLI Output: show ap upgrade
WLC-test#show ap upgrade
Status: Complete
Move Report Name: AP_upgrade_from_WLC-prod-HA
From version: 17.15.5.36
To version: 17.15.5.36
Configured percentage: 25
Percentage complete: 100
Client steering: Enabled
Client de-authentication: Enabled
Accounting percentage: 75%
Iteration expiry time: 9 minutes
Accounting action: None
Source controller: WLC-test
Destination controller: WLC-prod-HA
Progress Report
---------------
Iterations
----------
Iteration Start time End time AP count
------------------------------------------------------------------------------------------------
0 06/11/2026 00:15:32 CST 06/11/2026 00:15:36 CST 0
1 06/11/2026 00:15:36 CST 06/11/2026 00:17:44 CST 752
2 06/11/2026 00:17:44 CST 06/11/2026 00:19:50 CST 695
3 06/11/2026 00:19:50 CST 06/11/2026 00:21:58 CST 635
4 06/11/2026 00:21:58 CST 06/11/2026 00:24:03 CST 558
5 06/11/2026 00:24:03 CST 06/11/2026 00:26:09 CST 445
6 06/11/2026 00:26:09 CST 06/11/2026 00:28:14 CST 238
7 06/11/2026 00:28:14 CST 06/11/2026 00:30:20 CST 35
8 06/11/2026 00:30:20 CST 06/11/2026 00:32:25 CST 3
Upgraded
--------
Number of APs: ~3000APSP Hitless Upgrade
Step 1 – Prepare HTTPS AP Image Download
If you were not installing an APSP, you could move to post-upgrade validation at this point. In this case, after all APs were running 17.15.5 base code, we applied the 17.15.5 APSP using a hitless procedure.
For APSP, no N+1 controller is needed because the WLC can allow APs running the base code and APs running the APSP to be joined at the same time.
We used HTTPS image distribution now that the WLC was on a supported version. One caveat: HTTPS image distribution had issues with an internal domain-issued certificate where the certificate path included an intermediate CA. To work around this, we changed the HTTPS trustpoint to the WLC internal self-signed certificate. After changing it, wait for the GUI to stabilize. If you see broken images or incomplete GUI pages, wait a few minutes or hard-refresh the browser.
Command:
ap upgrade method httpsWhat we want to see:
- The WLC should be configured to use
ap upgrade method https. - The staggered AP upgrade settings should still match the intended hitless upgrade behavior.
client-deauthandclient-steeringshould match your intended client handling behavior.- The iteration completion and timeout values should match what you want to use for the APSP rolling AP upgrade.
Verify with:
show run all | i ap upgradeCLI Output: show run all | i ap upgrade
WLC-prod-HA#show run all | i ap upgrade
ap upgrade method https
ap upgrade staggered 25
ap upgrade staggered client-deauth
ap upgrade staggered client-steering
ap upgrade staggered iteration completion 70
ap upgrade staggered iteration timeout 9Step 2 – Add APSP
Install the APSP image from Administration → Software Management → AP Service Pack (APSP). Like the WLC code install, once you start the process, do not interrupt it.
GUI APSP install log excerpt
INSTALL ADD OPERATION:
--- Analyzing file C9800-universalk9_wlc.17.15.05.CSCwt44784.SPA.apsp.bin ---
Package Type is APSP
Initiating INSTALL_ADD operation for the package C9800-universalk9_wlc.17.15.05.CSCwt44784.SPA.apsp.bin
install_add: START Thu Jun 11 00:49:35 CST 2026
install_add: Adding SMU
install_add: Checking whether new add is allowed ....
install_add: install-add is allowed.
--- Starting initial file syncing ---
[1]: Copying bootflash:C9800-universalk9_wlc.17.15.05.CSCwt44784.SPA.apsp.bin from chassis 1/R0 to chassis 2/R0
[2]: Finished copying to chassis 2/R0
Finished initial file syncing
--- Starting SMU Add operation ---
Performing SMU_ADD on all members
[1] SMU_ADD package(s) on chassis 1/R0
[1] Finished SMU_ADD on chassis 1/R0
[2] SMU_ADD package(s) on chassis 2/R0
[2] Finished SMU_ADD on chassis 2/R0
Checking status of SMU_ADD on [1/R0 2/R0]
SMU_ADD: Passed on [1/R0 2/R0]
Finished SMU Add operation
SUCCESS: install_add Thu Jun 11 00:52:04 CST 2026Once the APSP is added, activate it. The iteration configuration should be the same as what was used for the N+1 upgrade. Selecting the APSP and clicking Activate starts AP predownload.
Step 3 – APSP Predownload
APSP predownload took about 1 hour 15 minutes. The majority of APs were done around 40 minutes, but some APs were stuck or on slow WAN links.
HTTPS image upgrade appeared to place significant load on the WLC:
- GUI and CLI became extremely unresponsive.
- SNMP monitoring timed out intermittently (that is the empty gaps in the image).
- No obvious client connectivity issue was observed, but that was not deeply validated.
- Maximum concurrent predownloads appeared to be about 400, versus about 800 with CAPWAP.
- WLC management interface utilization appeared to hit 2-4 Gbps according to monitoring.
- APs will auto fallback to CAPWAP if HTTPS is not working for that specific AP or site
- Some APs failed and required manual reboot.
Command:
show ap image | i 17.9.6Note: I’m including APs still on the old image 17.9.6 because ones without issue will have 17.15.5.36 (base 17.15.5 AP image) and 17.15.5.201 (APSP applied).
CLI Output: show ap image | i 17.9.6
onf-9k-wlc#show ap image | i 17.9.6
XXX-1AP-6 17.15.5.36 17.9.6.201 Fail to clean up 17.15.5.201 0 0 CAPWAP
YYY-1AP-2 17.15.5.36 17.9.6.201 Fail to clean up 17.15.5.201 0 0 CAPWAP
ZZZ-1ap-1 17.15.5.36 17.9.6.40 Predownloading 17.15.5.201 0 0 CAPWAP
GGG-BAP-3 17.15.5.36 17.9.6.201 Invalid tar file 17.15.5.201 574 3 CAPWAP
Failures observed included:
Fail to clean up
Invalid tar file
CLI Output: show ap image
WLC-prod-HA#show ap image
Total number of APs : ~3000
Number of APs
Initiated : 0
Downloading : 0
Predownloading : 397
Completed downloading : 0
Completed predownloading : 2014
Not Supported : 0
Failed to Predownload : 4
Predownload in progress : Yes
AP Name Primary Image Backup Image Predownload Status Predownload Version Method
----------------------------------------------------------------------------------------------------------------------------------
AP-EXAMPLE-001 17.15.5.36 17.15.5.201 Complete 17.15.5.201 HTTPS
AP-EXAMPLE-002 17.15.5.36 17.9.6.201 None 0.0.0.0 N/A
AP-EXAMPLE-003 17.15.5.36 17.15.5.201 Complete 17.15.5.201 HTTPSStep 4 – APSP Rolling AP Upgrade
With predownload complete, AP upgrade iterations begin again. APs are not moving between WLCs during this step, so the iterations were slightly faster than the N+1 hitless upgrade. The first iteration took around six minutes.
Command:
show ap upgradeNote: This output was captured during the APSP rolling AP upgrade. Since APs are not moving between controllers here, iterations complete slightly faster than the N+1 hitless upgrade.
CLI Output: show ap upgrade
WLC-prod-HA#show ap upgrade
Status: In progress
From version: 17.15.5.36
To version: 17.15.5.201
Configured percentage: 25
Percentage complete: 99
Expected time of completion: 06/11/2026 02:17:24 CST
Client steering: Enabled
Client de-authentication: Enabled
Accounting percentage: 70%
Iteration expiry time: 9 minutes
Progress Report
---------------
Iterations
----------
Iteration Start time End time AP count
------------------------------------------------------------------------------------------------
0 06/11/2026 02:11:24 CST 06/11/2026 02:11:24 CST 0
1 06/11/2026 02:11:24 CST 06/11/2026 02:17:29 CST 745
2 06/11/2026 02:17:29 CST 06/11/2026 02:23:35 CST 687
3 06/11/2026 02:23:35 CST 06/11/2026 02:29:41 CST 632
4 06/11/2026 02:29:41 CST 06/11/2026 02:34:46 CST 558
5 06/11/2026 02:34:46 CST 06/11/2026 02:40:52 CST 446
6 06/11/2026 02:40:52 CST 06/11/2026 02:44:57 CST 234
7 06/11/2026 02:44:57 CST 06/11/2026 02:49:02 CST 41
8 06/11/2026 02:49:02 CST ONGOING 5
Upgraded
--------
Number of APs: ~3000Step 5 – AP Exceptions
Some APs may not be handled by Rolling AP Upgrade if they do not have the correct backup image. These APs need to be remediated after the main upgrade flow. Most likely you will just need to reboot them.
Command:
show ap upgradeNote: At the bottom of the output you can see APs that will not be handled by Rolling AP Upgrade. These typically require manual remediation such as an AP reboot.
CLI Output: show ap upgrade
APs not handled by Rolling AP Upgrade
-------------------------------------
AP Name Radio MAC Status Reason for not handling by Rolling AP Upgrade
----------------------------------------------------------------------------------------------------------------------
AP-EXAMPLE-001 xxxx.xxxx.x001 Connected AP does not have the correct backup image
AP-EXAMPLE-002 xxxx.xxxx.x002 Connected AP does not have the correct backup image
AP-EXAMPLE-003 xxxx.xxxx.x003 Connected AP does not have the correct backup image
AP-EXAMPLE-004 xxxx.xxxx.x004 Connected AP does not have the correct backup image
AP-EXAMPLE-005 xxxx.xxxx.x005 Connected AP does not have the correct backup image
AP-EXAMPLE-006 xxxx.xxxx.x006 Connected AP does not have the correct backup image
AP-EXAMPLE-007 xxxx.xxxx.x007 Connected AP does not have the correct backup image
AP-EXAMPLE-008 xxxx.xxxx.x008 Connected AP does not have the correct backup image
AP-EXAMPLE-009 xxxx.xxxx.x009 Connected AP does not have the correct backup image
AP-EXAMPLE-010 xxxx.xxxx.x010 Connected AP does not have the correct backup image
AP-EXAMPLE-011 xxxx.xxxx.x011 Connected AP does not have the correct backup image
AP-EXAMPLE-012 xxxx.xxxx.x012 Connected AP does not have the correct backup image
AP-EXAMPLE-013 xxxx.xxxx.x013 Connected AP does not have the correct backup image
AP-EXAMPLE-014 xxxx.xxxx.x014 Connected AP does not have the correct backup image
AP-EXAMPLE-015 xxxx.xxxx.x015 Connected AP does not have the correct backup image
AP-EXAMPLE-016 xxxx.xxxx.x016 Connected AP does not have the correct backup image
Step 6 – Commit APSP
Make sure the WLC image and APSP are committed and rollback timers are inactive. You do not want the controller to roll itself back later. Look for C, meaning activated and committed, and verify the auto abort timer is inactive.
Command:
show install summaryNote: This was captured after the APSP was committed and activated. This confirms both the base image and APSP are in a committed state and rollback timers are inactive.
CLI Output: show install summary
WLC-prod-HA#show install summary
[ Chassis 1/R0 2/R0 ] Installed Package(s) Information:
State (St): I - Inactive, U - Activated & Uncommitted,
C - Activated & Committed, D - Deactivated & Uncommitted
--------------------------------------------------------------------------------
Type St Filename/Version
--------------------------------------------------------------------------------
IMG C 17.15.05.0.8370
APSP C bootflash:C9800-universalk9_wlc.17.15.05.CSCwt44784.SPA.apsp.bin
--------------------------------------------------------------------------------
Auto abort timer: inactive
--------------------------------------------------------------------------------
What to validate:
- WLC Image is status ‘C’ for Activated & Committed
- APSP is status ‘C’ for Activated & Committed
- Auto abort timer is inactive
Post-Upgrade Tasks
- Validate AP counts match the pre-upgrade export.
- For missing APs, shut/no shut the AP uplink switch interface if needed.
- Remove AP authorization restrictions from other WLCs. If you forget, an AP that reboots later may be unable to rejoin.
- Confirm all images are committed and rollback timers are inactive.
- Send all-clear notifications according to change management procedures.
Key Takeaways
- Test the target code with real client devices before upgrading production.
- N+1 upgrade lowers risk compared with ISSU. See all the bugs related to ISSU upgrades.
- Make sure your N+1 AP upgrade configuration matches your primary WLC settings
- Use one person to operate the GUI while others monitor.
- CLI commands were more responsive than the GUI in monitoring AP upgrade progress
- CAPWAP predownload took around 2x longer than HTTPS.
- Fallback from N+1 back to the upgraded primary was much faster than the original move to N+1.
- Always remember commit both the base WLC image and APSP.