Aruba Access Point Firmware Upgrade

原文：Aruba Access Point Firmware Upgrade — theDXT (Daniel Keer)

I’m a fan of doing as much as possible with CLI. It always feels more complete and can sometimes be automated. In this post, I will detail step-by-step how to upgrade the firmware image on an Aruba AP (Access Point) with CLI.

ArubaOS is also called Aruba Instant and has nothing to do with Aruba Instant On as that is another product line that is cloud-managed but not cloud-managed with Aruba Central. I’ll be using the term ArubaOS (AOS) in this post to try and keep things as clear as possible.

If you upgrade to AOS 10 you will need to manage the APs with Aruba Central. AOS 8 is the last and still currently developed version that does not require Aruba Central. You can confirm that AOS 8 is still being developed and maintained by checking theAruba End of Life page for AOS 8.

Upgrade Path and Compatibility Checks

Every ArubaOS 8 release note contains a Supported Hardware Platforms table, and that table is the first thing you should read before downloading an image. Aruba drops support for older APs over time, and an image that is perfectly valid for an AP-515 will refuse to run on an AP-105. Find your model in the table and note the earliest and latest AOS version that supports it. If your model is missing for the release you wanted, you have found your ceiling and no amount of CLI creativity will get around it.

The second check is the upgrade path itself. Aruba does not guarantee that any version can be upgraded to any other version directly: large jumps, such as from an Instant 6.x code train straight to 8.10, are unsupported and the release notes state the minimum version you must be running first. In those cases the safe route is a two-step upgrade - bring the cluster to the intermediate release, let it stabilise, then repeat this whole process for the target release. It takes longer, but it is the only supported route and it keeps you out of a half-upgraded cluster.

Third, match the image file name to the hardware. An Aruba Instant image looks like ArubaInstant_Draco_8.10.0.8_87765; the word in the middle (Draco) is the platform codename, and APs report their own class in the output of show image. If the codename does not match, you have the wrong file. Aruba publishes separate images per platform family in the same release, so this is an easy mistake to make at midnight.

Finally, check the boring infrastructure: working NTP so log timestamps line up, enough flash to hold the new image alongside the running one, and an uninterrupted power source. An AP that loses power while writing a new image bank is the one scenario where this process can genuinely brick a device.

Preparing the TFTP Server

The CLI method needs a file server the APs can reach. TFTP is the simplest choice because ArubaOS speaks it natively, it needs no authentication, and it runs on the management VLAN where little else is happening. Any Linux host will do; on Debian or Ubuntu the setup is three commands and one config line.

sudo apt-get install -y tftpd-hpa
sudo mkdir -p /srv/tftp && sudo chown tftp:tftp /srv/tftp
# /etc/default/tftpd-hpa
#   TFTP_USERNAME="tftp"
#   TFTP_DIRECTORY="/srv/tftp"
#   TFTP_ADDRESS="0.0.0.0:69"
#   TFTP_OPTIONS="--secure --create"
sudo systemctl restart tftpd-hpa
sudo cp ArubaInstant_Draco_8.10.0.8_87765 /srv/tftp/
sha256sum /srv/tftp/ArubaInstant_Draco_8.10.0.8_87765

Three details matter. TFTP has no authentication or encryption at all, so restrict the service to the management subnet with a firewall rule and delete the image once the upgrade is finished. It runs on UDP port 69, which most enterprise firewall policies block by default, so open it for the AP subnet for the maintenance window only. And verify the checksum of the downloaded file before serving it: a truncated download uploads cleanly and then fails to boot, which is the worst possible failure mode because you will not discover it until the reload.

The Process

• Review the release notes for the version of AOS you want to upgrade to. Specifically the section Supported Hardware Platforms as that will help you determine your upgrade path.
• SSH into the Virtual Controller

If you have more than on AP in your VC (Virtual Controller) you need to define one of them as the preferred conductor. When a preferred conductor is set that will always be the AP running the VC.

• Run the command show ap-env to see if you have preferred conductor.

If the output doesn’t show iap_conductor:1 then you currently don’t have a preferred conductor. (If your firmware is really old it might show up as iap_master:1 as that was the old name for it.)

VC with no preferred conductor

• Run the command iap-conductor to set the AP that is currently running the VC to be the preferred conductor. (If your firmware is really old the command won’t be recognized and you’ll need to run the command iap-master instead.)

Running the iap-conductor command

• Run the command show ap-env again to confirm the preferred conductor setting is applied.

VC with a preferred conductor

• Run the command show version to confirm which version of AOS you are currently running. I am currently running AOS version 8.10.0.7.

Output of the show version command

• Run the command show image to show what images are on the AP and the device class.

Output of the show image command

With the device class you can figure out which firmware image you need to download for you AP.

• Download the firmware image from Aruba

• Backup your current config by running the following command copy config tftp IP_TFTP_SERVER AP_config_VERSION.cfg

For my setup I will run the following command copy config tftp 192.168.3.125 AP_config_8.10.0.7.cfg

backing up the config

There are various methods to upload the firmware image to the VC I’m going to use TFTP. I am going to upload it to the secondary image slot and tell it not to reboot so I can control the temporary WiFi outage. Once the firmware image is uploaded the upgrade process starts.

• Run the following command to upload the firmware image to the VC with TFTPupgrade-image2-no-reboot tftp://IP_TFTP_SERVER/IMAGE_FILE

For my setup I will enter the following command upgrade-image2-no-reboot tftp://192.168.3.125/ArubaInstant_Draco_8.10.0.8_87765

Uploading the firmware image to the VC

• Run the command show upgrade to see the current status of the upgrade.

viewing the status of the upgrade with the show upgrade command

What is happening is the AOS firmware image is being uploaded to the VC and then the AP that is running the VC will act as a seed to upload the AOS firmware image to the other APs.

• Wait until the status shows as upgrade-done

The AOS firmware image has been uploaded to all APs

Once the APs have the firmware it won’t be active until the APs are rebooted which will cause a temporary WiFi outage.

What Actually Happens During the Upgrade

It is worth understanding the mechanics, because they explain why this process has two distinct phases and why the WiFi does not drop until you decide it does.

When you run upgrade-image2-no-reboot, the Virtual Controller downloads the image from your TFTP server and writes it into the secondary image bank of the AP that is running the VC. That AP then acts as a seed and pushes the same image to every other AP in the cluster over the internal network. show upgrade reports this progress, moving through the upload phase and then the sync phase until it reports upgrade-done. Nothing reboots during this phase, so the only thing consumed so far is bandwidth on the VLAN carrying the inter-AP traffic.

Writing into the secondary bank is what makes this method safer than a staged reboot: the running image stays untouched until the AP restarts, so a failed or corrupt transfer can simply be repeated. If the upload fails part way through - and TFTP over a congested VLAN eventually will - run the command again and the AP overwrites the incomplete bank. Transfer time depends on image size and path speed. An 8.x Instant image is on the order of 60 to 100 MB, which a 100 Mbit management link moves in well under a minute per AP, while a legacy 10 Mbit out-of-band path will make the whole cluster take half an hour. On a large cluster the seed AP distributing the image to dozens of members is usually the bottleneck, not the TFTP transfer, so give yourself a generous window.

When the sync completes you are at a decision point: the new code is on the APs but not yet running. reload is the point of no return for the outage, and the only moment in the procedure where client connectivity is affected. Plan it for a maintenance window and do it deliberately. After the reload the preferred conductor returns first, becomes the VC again, and compares every member's version; members that do not match are rebooted by the VC until the cluster is homogeneous. That means WiFi can dip twice - once for the conductor and once while members catch up - so expect a couple of minutes in a small cluster and several minutes at a site with thirty APs.

• Run the command reload to reboot.

Rebooting

Because an AP was set to be the preferred conductor it acts as the main AP for all other APs. The process is the preferred conductor get’s upgraded which upgrades the VC then the preferred conductor sees that the other APs versions don’t match and will reboot them so the AOS versions match.

• Once the VC is back online run the command show version to confirm you are running the new AOS firmware image.

Output of show version displaying the new version

Rollback and the Old Image Bank

Because the upgrade writes into the secondary bank, the previously running image usually still sits in the primary bank until something overwrites it. That gives you a rollback option that costs nothing to prepare: if the new release breaks something, upload the older image with the same command, reload again, and you are back where you started. Keep the previous image file on the TFTP server for exactly this reason, next to the config backup you took before the upgrade.

What you must not do is assume the rollback is instant. It is another full upload, sync and reboot cycle with the same outage profile as the forward upgrade. Treat it as a second maintenance window rather than an emergency undo button, and decide in advance which symptoms would trigger it: clients failing to reassociate on a particular model, 802.1X authentication breaking, or a regression in a feature you depend on.

Also make sure the config backup is genuinely good. The copy config tftp step writes a plain text backup of the Virtual Controller configuration to your server, and that file is what lets you rebuild the cluster if a reload goes badly wrong. Include the version number in the file name so you keep a history instead of overwriting the only good copy each time.

Verifying the Upgrade

Do not declare victory the moment the VC answers ping. Work through these commands in order and confirm each layer before closing the window.

show version
show image
show upgrade
show ap-env
show summary
show log system

show version on the VC confirms what the conductor now runs. Because the cluster forces version parity, that should be what every member runs - but confirm it anyway, especially at a site with more than a handful of APs, by SSH-ing to an individual AP's management address or reading the firmware version column in the web interface's AP table. Any AP still on the old version after ten minutes is either failing to reach the seed AP or stuck; check its uplink and power.

show image tells you the active bank and the fallback bank, which is exactly what you want to know before the next upgrade. show upgrade should report no upgrade in progress, and show summary gives cluster health at a glance. Finally show log system is where you catch the quiet problems - certificate warnings, failed NTP syncs, repeated reboots - that never show up in a version check but become tomorrow's support ticket. Then do the things that are easy to forget: test client authentication from a real client, confirm the uplink is passing traffic at the expected rate, and record the new version against the site in your change management system.

Automating and Scheduling the Upgrade

The reason for doing this over the CLI rather than through a browser is that a CLI procedure is one you can repeat, document and eventually script. Every step is deterministic: set the preferred conductor, confirm the image state, back up the config, upload to the secondary bank, wait for upgrade-done, reload, verify. That sequence can be typed at one site today and replayed unchanged at ten sites next month. Two habits make the replay safe: standardise the config backup file name on a pattern that includes version and site, and record each AP model's device class in the site documentation so the next engineer knows which image to download without touching a live cluster.

Treat the upgrade like any other change: pick a window, notify users, take a backup, and start with the least critical cluster. If you run a lab or a small branch first, you see the release behave in your own environment before you touch the site carrying the CEO's calls. The upgrade is quick and low risk, but low risk is not no risk - a release that changes 802.11 behaviour in a way your client fleet dislikes will be found in the lab long before it is found in production. And since the preferred conductor carries the VC across the reboot, set one before you schedule the work if the cluster does not have it today; it costs one command and removes a whole class of "which AP is the controller now" confusion.

That’s all it takes to upgrade the ArubaOS firmware image on Aruba APs with a Virtual Controller. If you want to go further with wireless work, this site also covers Wi-Fi 7 and multi-link operation in the enterprise, 802.11k/v/r fast roaming configuration, PoE standards and how much power your AP really needs, and 802.1X port-based authentication on access switches.