Ask any network engineer to name one thing they do that makes them cringe and I would bet that at least 90% of those asked would say firmware upgrades. Firmware upgrades can be a blessing and a curse because of the unknowns that come with running any new code in the network.
The only thing more troubling to an engineer than the unknowns of how new code will perform, since all code should be tested thoroughly in the lab before production, is the time and effort required to implement the new code. With wireless now the de facto standard of how users connect to the network, wireless network uptime and reliability have become mission-critical. Maybe even a level above mission-critical, if there were one. So how has Aruba attempted to make the lives of WLAN administrators easier?
Live Upgrade
In ArubaOS 8, Aruba introduced a revolutionary feature to the wireless industry called Live Upgrade. Live Upgrade allows the upgrades of an Aruba controller’s firmware at any time, while also providing peace of mind to the engineer in charge of the upgrade.
With the ability of ArubaOS 8 to form controller clusters, all APs have active connections to one controller while simultaneously having a standby tunnel operational to a secondary cluster member. This allows for seamless failover of APs (and their associated users) to another controller during the upgrade process. Logic within the Live Upgrade feature strategically chooses which APs will go offline to users for code upgrade and reboot, while maintaining full network operations for active clients. This almost sounds too good to be true. Let’s look at how the process works.
Once the upgrade process is initiated from the Mobility Conductor, the APs are grouped into logical partitions based on their operating channel and assigned to a target controller. Cluster Upgrade AP PartitionsYou might wonder how the controller moves existing client associations from the AP before it reboots. The magic is…it doesn’t. It seems as though Aruba adopted Occam’s Razor here, in that the simplest explanation of how to move clients around for the AP upgrade was the easiest one. Just reboot the AP. (Before you say well “it depends,” you are correct in thinking that for this to work you need proper secondary (overlapping) coverage throughout your deployment. Then again, you should have that already!) Once the AP has upgraded, it becomes homed to the target controller after reboot and can accept new connections.
On the controller side, the upgrade process pushes the new code revision to all controllers in the cluster and reloads the controllers one at a time. Once a controller has rebooted, it forms its own cluster temporarily and all APs that are set to use it as their target controller are rebooted for upgrade. This process continues until all controllers are upgraded, at which time the initial cluster architecture is restored.
A true hitless failover from the client perspective is almost unfathomable to an engineer. While this process isn’t truly “hitless,” you will see the client associate to a neighboring AP when the controller decides it’s time for the currently associated AP to upgrade, it’s pretty close. Cluster Upgrade Status
Having tested this upgrade process in both lab and production environments, I can speak firsthand both to how easy it is to use and the lack of impact to associated users throughout the upgrade process. The only indications of anything happening at all to my test clients were the messages notifying the of the move to a new BSSID and a missed ping during the roam. Even real-time voice and video applications didn’t appear to skip a beat during the process. This is due largely in part to the ability of AOS8 clustering to maintain high value session information between all cluster members in case of a failure.
So, what about upgrading smaller components like DRT files or AppRF information? Aruba thought of that as well with the introduction Loadable Service Modules (LSMs). No longer does an upgrade of smaller components like these require downtime and a full controller code upgrade.
While there are many things in the life of an engineer that cause worry and sometimes great consternation, Aruba is seeing to it that code upgrades for your mission-critical wireless network no longer create worry. The ability to do a clustered upgrade, with almost an almost truly hitless process to the client, continues to move WLANs forward by allowing unprecedented levels of uptime and performance. It's something that is greatly needed across all environments where a wireless network is mission-critical.
Follow Scott Lester on Twitter @theITrebel.
