Making sense of Cisco WLC access point firmware pre-download

Firmware pre-download on the Cisco WLC wireless LAN controllers is a beautiful thing.

“In the old days"™ the update went like this:

1. Upload firmware to controller
2. Reboot controller
3. Accesspoints want to rejoin controller, see non matching firmware, start updating, 10 at a time … 1 hour later …
4. Most of your APs updated, some are still updating…

In large wireless LANs, this was not really an ideal solution, as the Wi-Fi was down for a long time if you had many APs on the controller. So Cisco introduced the pre-download feature with version 6.0, many years ago. It is documented in the official config guides, for example here.

The issue I have with this, that it was not really clear to me, which primary/backup command does what, because you have primary and backup images on WLC and AP.

So here a little guide, with the example of a usual upgrade path:

1. Transfer new image of your choice to contoller as usual, via TFTP/FTP/HTTP
2. This image will be by default the new primary boot image of the controller. Your currently running version will become the backup boot image (automatically).

(WiSM-slot8-1) >show boot

Primary Boot Image............................... 8.5.140.0 (default)
Backup Boot Image................................ 8.2.170.0

We don’t want that. If the controller reboots for whatever reason, it will come up with the new version, without supervision, and upgrading all APs, maybe during peak hours.

3. We swap the image for now, using the backup image (which is the currently running image).

(WiSM-slot8-1) >config boot backup 

(WiSM-slot8-1) >show boot          

Primary Boot Image............................... 8.5.140.0
Backup Boot Image................................ 8.2.170.0 (default)

If the controller would reboot now, everything will come up as usual. Note: The primary and backup boot image do not switch places - you just mark to boot the backup image.

4. We predownload the image to the APs. The command has the parameter of primary or backup image from the controller. This is not whether the primary or backup position on the AP! Predownloading to AP will always use the place of the backup-image there (for now). We just have to say which version we want to predownload. This is not whether we boot the primary or backup image.

(WiSM-slot8-1) >config ap image predownload primary all

(we are instructing all APs to download the new version, sitting on the controller in the primary spot).

5. Monitoring progress

(WiSM-slot8-1) >show ap image all

Total number of APs.............................. 4

Number of APs
        Initiated....................................... 0
        Downloading..................................... 0
        Predownloading.................................. 3
        Completed predownloading........................ 1
        Not Supported................................... 0
        Failed to Predownload........................... 0

                                                 Predownload     Predownload                                  Flexconnect
AP Name            Primary Image  Backup Image   Status          Version        Next Retry Time  Retry Count  Predownload
------------------ -------------- -------------- --------------- -------------- ---------------- ------------ ---------
AP0201           8.2.170.0      8.2.164.0      Predownloading  8.5.140.0      NA               0           
AP0202           8.2.170.0      8.2.164.0      Predownloading  8.5.140.0      NA               0           
AP0603           8.2.170.0      8.5.140.0      Complete        8.5.140.0      NA               NA          
AP0903           8.2.170.0      8.2.164.0      Predownloading  8.5.140.0      NA               0       

6. When the predownload is done on all APs (it can take a while, especially if the network is under load - since it is happening in the background), we plan our upgrade. I usually do this in the night hours via automated reboot, and check when it should be up again after a few minutes if all APs join correctly. Since we now have the desired version in backup position on AP and would boot the “old” image on the controller, we swap images too.

(WiSM-slot8-1) >reset system at 2019-01-04 04:30:00 image swap reset-aps save-config 

System reset is scheduled for Jan 04 04:30:00 2019.
Current local time and date is Jan 03 15:21:58 2019.
A trap will be generated 10 minutes before each scheduled system reset.
Use 'reset system cancel' to cancel the reset.
The system has unsaved changes.
Configuration will be saved before the system reset.

“reset-aps” will reset the accesspoints before the controller reboot, so they will come up faster with the new version. Now we wait for the scheduled reset to occur and will be greeted with a new version, after minimal downtime.

You can leave the primary image as boot image of course, if you prefer. You then would have to swap the AP images before rebooting.

(WiSM-slot8-1) >config ap image swap all 

You would then need to change the “swap” in the reboot command to “no-swap”.

Another pitfall: There is a bug in some versions (8.2.164.0, maybe others), that APs that would have an ID over the max concurrent predownload count would fail image predownload - see CSCvi73980. So the later joined APs would not predownload the newer software.