With AOS8, the update process changes slightly. It is possible to run different versions of code on controllers and the Mobility Master (VMM). This makes updating a lot easier because you do not have to plan for a long downtime, just for a firmware update.
In the following post, I show the different options to upgrade the controller and what strategy I prefer for the upgrade process.
Firmware Update – The Manual Way
This method is completely manual and works great for small environments. You can start with the VMM and update the controller afterward.
To update the VMM, select the VMM in the configuration hierarchy and go to “Maintenance–>Software Management–>Upgrade”:
I use a local file on my PC and install the image to partition 1. I use partition 1 because the current version is in partition 0. And if something goes wrong, I can boot to partition 0 and I’m back online. I let the controller reboot immediately, after the upload of the image is ready. But before, the controller saves the configuration. Just hit “Upgrade” and wait for the process to finish.
Is the VMM up and running again, you can start to upgrade the Managed Devices (MD). This is one of the only steps, you can only perform on the MD itself. So you have to log in to the MD and go to “Maintenance–>Software Management–>Upgrade”:
Same rules as above. Use the partition with the oldest image. I reboot the controller right after the upload, but before, save the configuration. Hit “Upgrade” to start the process.
Repeat this for every MD. This process allows you to update the VMM first and afterward the MD’s step by step. You can start with non-critical controllers, like LAB controller, and afterward the important ones.
Firmware Update – AP Preload Image
With the process above, the controller installs the new firmware first and afterward pushes the firmware to the AP’s. This adds additional downtime. To avoid this, you can configure the controller to preload the image to AP’s and reboot afterward. This reduces the downtime because the AP has the image already. In large environments, the download of the image can take a lot of time. During this time, all AP’s, which are not updated, are down. AP Preload Image avoid this and the AP is up and running right after the controller and the AP has rebooted.
To use this feature, upload the new firmware image to the controller without the reboot option:
Hit the “Upgrade” button and wait for the process to finish.
Afterward, go to “Maintenance–>Access Point–>Preload Image”:
If you see a page with an “Activate” link, use this link to get to the page above. Enable “AP Image Preload” and select the partition with the new firmware. In my setup, I load the image to all AP’s. but you can specify specific AP’s as well. Hit the “Apply” button to start the process.
You get a process summary and an entry per AP:
After the status for all AP’s is “Preloaded” you can reboot the controller to the new image. The AP’s reboot as well, after they can restore the connection to the controller. But this time, they can just reboot. They do not have to download the image first. This makes the process faster.
You have to configure this for every new upgrade, as the preload feature is disabled after controller reboot.
Firmware Update – Centralized Update
To update all controllers manually work great for small environments. But for larger deployments or deployments with many branch offices, this is not that handy. To make the process for those environments easy as well, you can have something like a centralized update. You only need a central file storage. From this file storage, all the controllers download the image. You do not have to touch every controller. Much better, is it?
I use FTP for the file transfer. You can also use SCP or TFTP. The first step is to configure the file storage location and the protocol in the controller. Log in to the VMM and select a hierarchy level under “/md” where you like to configure the centralized upgrade location. Now go to “Configuration–>System–>Profiles” and search for the “Upgrade” profile under “Controller Profile”:
Enter the “Server IP address” and the “File Path”. The “File Path” is the folder, where the firmware images are stored. If you choose FTP or SCP you need to specify a “Username” and a “Password”. Submit the changes and apply them. This process is only for MD’s. So you need to upgrade the MM with the process above. Do this before updating the MD’s.
To start the update for the MD you need to login to the CLI of the VMM. Here you can start the update process.
Change to the “/md” hierarchy level. From here you can issue the command to start the upgrade:
(MM) *[md] #upgrade managed-devices copy configured-fileserver version 22.214.171.124_61883 path /md/Haan-Live partition 0 upgrade managed-devices ----------------------- Affected Ignored -------- ------- 1 1
This command starts the download of the firmware file for version 126.96.36.199_61883. This assumes you have not changed the file name after downloading the file from the Aruba support page. If you use this command with the version parameter, the device selects the correct image from the server, even if you have different controller types in the node. In my case, all controllers under “/md/Haan-Live” are upgraded.
You can see a list of all supported commands here:
You can see the status of the process with this command:
(MM) *[md] #show upgrade managed-devices status copy all upgrade managed-node copy command status ---------------------------------------- MAC Last Cmd Last Cmd Time Copy Status Status Description --- -------- ------------- ----------- ------------------ 00:0b:86:be:84:00 copy-prof Sat Oct 21 16:18:33 2017 Update success Successfully updated flash with ArubaOS_70xx_188.8.131.52_61883
From the output above you see that the image upgrade was successful. I did not reboot the device by intent. So I have the chance to preload the AP image to all my AP’s before rebooting the device.
Assume the AP image preload is ready, you can finish the upgrade and reboot the device with this command:
(MM) *[md] #upgrade managed-devices reboot path /md/Haan-Live Do you really want to restart the selected managed devices? [y/n]: y upgrade managed-devices ----------------------- Affected Ignored -------- ------- 1 1
After the reboot, the controllers are updated.
The upgrade of a controller cluster is slightly different and I will describe this in a post dedicated to the controller cluster.
If you find this post interesting, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and share it with your enemy. But whatever you do, leave me a comment, now.