15.2 Performing Firmware Updates
Key Takeaways
AOS-CX switches keep primary and secondary images;
copy <url> primary|secondaryloads an image,show imageslists versions, andboot system primary|secondaryreboots into the chosen image.VSX pairs can be upgraded with
vsx update-software <tftp-url>, which installs the image on both peers and reboots the secondary first, then the primary, so VSX-LAG clients stay connected.CX 6300 VSF stacks support VSF ISSU (
issu update-software) for upgrades between minor releases, keeping the data plane forwarding while the control plane upgrades.In Central, firmware compliance sets the target version for a group; AOS 10 Live Upgrade reboots APs in AirMatch partitions so neighbors stay up, and reloads gateway cluster members one at a time.
Always read the release notes for the supported upgrade path, back up the configuration, and schedule the upgrade in a maintenance window with a rollback plan.
15.2 Performing Firmware Updates
Quick Summary: Firmware updates are an Operate objective on HPE6-A85. The skills tested are practical: know where AOS-CX keeps its images, how to load and boot a new one, which method keeps traffic flowing for a VSF stack or a VSX pair, and how Central upgrades APs and gateways with firmware compliance and Live Upgrade. Every upgrade starts with the release notes and a backup.
Before Any Upgrade
- Read the release notes for the target version: supported upgrade paths, known issues, and changed defaults.
- Back up the configuration (
copy running-config <url> cli vrf mgmt) and create a checkpoint (Section 14.4). - Check the current state so you can compare after the upgrade:
show images,show version,show vsforshow vsx status, and key neighbor states. - Schedule a window and tell users; even "hitless" methods can cause brief disruptions.
- Plan the rollback: on AOS-CX, the previous image normally stays on the other image slot.
AOS-CX Dual Images
AOS-CX switches store two operating system images, primary and secondary, plus a service OS used for recovery (AOS-CX 10.14 Fundamentals Guide).
| Task | Command |
|---|---|
| List installed images and the default boot image | show images |
| Download an image into a slot | copy tftp://10.1.100.20/FL.10.xx.xxxx.swi secondary vrf mgmt (SFTP and SCP URLs are also supported) |
| Copy one slot to the other | copy primary secondary or copy secondary primary |
| Reboot into a slot and make it the default | boot system secondary |
| Change the default without rebooting | boot set-default primary |
| Review previous boots | show boot-history |
A common pattern is to load the new image into the slot that is not currently running, boot into it, and keep the old image in the other slot as a fallback. If the new version misbehaves, boot system back into the previous slot.
AOS-CX also supports hot patches (copy <url> hot-patch and the hot-patch command) for some fixes that can be applied without a full image change; whether a hot patch exists depends on the release.
Upgrading Redundant Systems
VSX pairs
vsx update-software tftp://<server>/<image> vrf mgmt (run on the primary) offers to save the running configuration, downloads the image, installs it to the alternate image of both peers, and then reboots them in sequence: the secondary first, then the primary (AOS-CX 10.14 CLI Guide). Devices dual-homed with VSX-LAGs and gateways using active-gateway keep working on whichever peer is up. Single-homed (orphan) devices lose connectivity while their peer reboots, which is one reason to dual-home important devices.
VSF stacks
A standard upgrade reboots the whole stack. On the CX 6300, VSF ISSU (issu update-software) upgrades the Conductor, Standby, and members while keeping the data plane forwarding, and it is supported for upgrades between minor releases (AOS-CX 10.14 VSF Guide). For a major-release jump, plan a full stack reload in a window.
Standalone switches
Load the new image into the alternate slot and boot system into it during the window. Access-layer devices behind a standalone switch lose connectivity during the reboot, and PoE devices lose power unless always-on PoE keeps them powered during a soft reboot.
Central Firmware Management
In Central, the Firmware area shows the running version of each device and lets you set firmware compliance for a group: the target version, the upgrade type, and when to run it (immediately or scheduled up to one month ahead).
AOS 10 Live Upgrade for APs
HPE's Live Upgrade service (AOS 10 TechDocs, "Live upgrade"):
- Asks AirMatch to split the APs into partitions so that APs in the same partition are not RF neighbors. While one partition reboots, clients can roam to neighbors that stay up.
- Selects seed APs: only seed APs download the image from Activate, and each serves up to 20 non-seed APs of the same model in the same Layer 2 domain, which saves WAN bandwidth.
- Reboots one partition at a time. Before rebooting, an AP disables its radios so clients roam to neighbors, which then synchronize the clients' sessions.
The default upgrade type in Central is Standard, in which all devices in the group download the image and reboot at the same time. Choose Live Upgrade when disruption must be minimized.
Gateway clusters
All gateways in a cluster download the image together but reload one at a time. Users on the reloading gateway move to their standby User Designated Gateway, and a gateway on the new version can rejoin a cluster still running the older version, so users are not disrupted.
AOS-CX switches managed by Central
Central can push AOS-CX upgrades as well. HPE's Central caveats note that upgrading an AOS-CX switch from Central needs a WAN connection of at least 2 Mbps and times out after 60 minutes.
After the Upgrade
- Confirm the version:
show versionandshow images, or the firmware view in Central. - Re-run the key validation checks (Section 15.1): VSF or VSX health, LAGs, routing neighbors, clients, and PoE.
- Compare against the pre-upgrade state and record the result in the change log (Section 15.4).
Common Exam Traps
- Upgrading both VSX peers at once by hand. The supported workflow reboots the secondary first, then the primary.
- Assuming VSF ISSU works for every upgrade. It applies to the CX 6300 and to upgrades between minor releases.
- Leaving Central compliance on when upgrading manually. If a group has a firmware compliance version set, Central will bring devices back to that version. Set compliance to "None" (Not Set) if you deliberately load firmware from your own server.
An administrator downloads a new AOS-CX image into the secondary slot of a standalone CX 6300. Which command reboots the switch into that image and makes it the default for future reboots?
boot system secondary
copy secondary primary
boot set-default secondary
issu update-software
A VSX pair is upgraded with 'vsx update-software tftp://192.0.2.10/image vrf mgmt'. In what order do the switches reboot?
Neither peer reboots until an administrator enters boot system on each
Both peers reboot at the same time
The primary reboots first, then the secondary
The secondary reboots first, then the primary
An organization wants to upgrade 200 AOS 10 APs in one building while keeping clients connected. Which Central option is designed for this?
Live Upgrade, which reboots APs in AirMatch partitions so neighbors stay up
Manually rebooting each AP from its console port after copying the image
Standard upgrade type, which reboots all APs in the group at once
Disabling firmware compliance for the group so APs upgrade one at a time
Sections you finish are checked off in the contents.