Why preload the image on the access points?
In a large wireless network, preloading the image to the access point may be something of 
interest to you. This process will lessen the overall downtime of your wireless network during the upgrade process. By preloading a new image to the access points in advance, negates the need to wait for your controllers to update the access points individually, which prolongs the upgrade process.
Normal Upgrade Process w/o preloading the access points
After a Cisco WLC is upgraded and rebooted. Access points drop into the discovery mode. When the access point rejoins the controller, it determines the access point code is different from the WLC. The access point will download the new code from the WLC. The access point upgrade process only takes a minute or so and then an additional minute for the access point to reboot and rejoin a WLC, so you are looking at 2 minutes of downtime for that access point.
The problem with this process, Cisco WLCs can not upload to all the access points at once, unless you have a 5508 WLC! The below list shows how many access points, can be upgraded concurrently, by controller model.
2100-XX 10 access point max
4402-XX 10 access point max
4404-XXX 10 access point max
WiSM 10 access point max (per controller)
5508-XXX 500 access point max
So, what is the big deal ?
Lets pick on a WiSM, shall we. Suppose you have 150 access points on a controller and the controller can only upgrade 10 access points concurrently at a time. Your controller would have to go through the upgrade process x15 times. This means access points would be offline not servicing clients until they take the upgrade. Potentially, it could take up to 15 minutes or longer to upgrade all 150 access points in this manner.
How Preloading The Image Speeds Up Your Upgrade Process and Limits Downtime
Certainly, if you have a controller model that is limited to the 10 AP download limit. The preload process will speed up your upgrade and lessen your downtime. I’ll go into the details below, but how it works is simple.
You push the new code to the WLC. Then from the WLC you push the new code to the access points while still in a live environment.
PRELOAD STEPS
1. Upgrade your WLC with your new image
2. Preload the image to the access points
3. Check image “positions” on the WLC and access points
Preload the image to the access points
You can do this via WCS or in the WLC CLI. I will show you the WLC CLI process.
(WiSM-slot1-1) >config ap image predownload ?
primary Predownload an image to a Cisco AP from the controller's Primary image.
backup Predownload an image to a Cisco AP from the controller's Backup image.
You have 2 positions where you can install the code (primary or backup). I call them positions, they are spots in memory stored in the access point. The primary position is the image that will get loaded when the access point reboots.
Check the current images and image positions on the controller and access points
ACCESS POINTS – Cisco access points (model dependency) allow you to store 2 images on the AP. You can use the following command to see the images on the access points and the position they are in.
(WiSM-slot8-2) >show ap image all
Total number of APs..............................2
Number of APs
Initiated............................................. 0
Predownloading................................... 0
Completed predownloading................... 0
Not Supported..................................... 0
Failed to Predownload........................... 0
AP Name Primary Image Backup Image Status Version Next Retry Time Retry
------------------ -------------- -------------- --------------- -------------- ---------------- ------------
TEST1 6.0.196.159 0.0.0.0 None None NA NA
TEST2 6.0.196.159 0.0.0.0 None None NA NA
*Primary Image – This is the image that loads when the AP is booted
*Backup Image – This is the image that is stored as a backup
CONTROLLERS - Cisco controllers allow you to store 2 images as well. You can see the images and their positions with the show boot command from the WLC CLI.
(WiSM-slot8-2) >show boot
Primary Boot Image............................... Code 7.0.98.0 (active)
Backup Boot Image................................ Code 6.0.196.159
Caution
When you upgrade your WLC the new image goes into the (active) position. If your intentions are to do the upgrade at a later time. It is important to “swap” the image from the primary location to the backup location. This is in case the controller reboots by accident. This goes for the access point images as well.
Controller and Access Point Image Swap
Access Point - Swapping the image can done by a single access point or by all access points
(WiSM-slot8-2) >config ap image swap all
(WiSM-slot8-2) >show ap image all
Total number of APs.............................. 2
Number of APs
Initiated............................................ 0
Predownloading.................................. 0
Completed predownloading.................. 2
Not Supported.................................... 0
Failed to Predownload.......................... 0
AP Name Primary Image Backup Image Status Version Next Retry Time Retry
------------------ -------------- -------------- --------------- -------------- ---------------- ------------
TEST1 7.0.98.0 6.0.196.159 Complete 7.0.98.0 NA NA
TEST2 7.0.98.0 6.0.196.159 Complete 7.0.98.0 NA NA
Controller- Swapping the image on the controller
(WiSM-slot8-2) >config boot primary (backup)
(WiSM-slot8-2) >show boot
Primary Boot Image............................... Code 7.0.98.0 (active)
Backup Boot Image................................ Code 6.0.196.159
Things you should know…
When you do a preload push there is a maximum number of concurrent predownloads. It is limited to half the number of concurrent normal image downloads (10 normally / half is 5). The access points not taking the download will then receive a random timer between 180 and 600 seconds. So this means your 4400s will do a preload of 5 access points at a time. The other 95 receive back off timers.
Dependency Homework
Guidelines and Limitations for Predownloading Images (from controller manual)
Keep these guidelines in mind when you use image predownloading:
- Maximum predownload limit: The maximum number of concurrent predownloads is limited to half the number of concurrent normal image downloads on 4400 series controllers; it is limited to 25 concurrent downloads on 5500 series controllers. This limitation allows new access points to join the controller during image downloading.
- If you reach the predownload limit, access points that cannot get an image back off and wait for a time between 180 to 600 seconds and then re-attempt the predownload.
- For predownloading to be effective, all controllers (primary, secondary, and tertiary) that your access points can join should use the same images for primary and backup images. For example, if you have three controllers, all three should use software release x as the primary image and release y as the backup image. This consistency is important because some controllers reboot more slowly than others, and access points rejoin a controller as soon as they reboot. If a 4400 controller reboots before a 5500 controller, it is important that both controllers are running the same images in case an access point joins one rather than the other.
- Before you enter the predownload command, Cisco recommends that you change the active controller boot image to the backup image. This step ensures that if the controller reboots for some reason, it comes back up with the earlier running image, not the partially downloaded upgrade image.
- Access points with 16MB total available memory (1130 and 1240 access points) sometimes do not have enough free memory to download an upgrade image, and they automatically delete crash info files, radio files, and any backup images to free up space. However, this limitation does not affect the predownload process because the predownload image replaces any backup image on the access point.
- These access point models do not support predownloading of images: 1120, 1230, and 1310.
I hope this helps with yout predownload efforts !