Migrating to AOS 10
5 minute read
Migrating existing hardware to HPE Aruba Networking Wireless Operating System AOS 10 (AOS 10) will require some consideration and planning before firmware can be loaded. While Mobility Controllers that, now known as Gateways in AOS 10, are currently running HPE Aruba Networking Wireless Operating System AOS 8 (AOS 8) have a straightforward path to AOS 10, access points (APs) can be deployed in multiple ways:
- An AP operating in controller managed mode, running AOS 8 with a Mobility Conductor and/or Mobility Controller
- HPE Aruba Networking Instant Operating System AOS 8 (Instant AOS 8) managed by HPE Aruba Networking Central (Central)
- IAP 8 with local management, i.e., the virtual controller
- IAP 8 managed by HPE Aruba Networking AirWave
How the APs are currently deployed, the software type and version, and the management and operation tool used, will determine the required path for successfully migrating to AOS 10. In the case of an AOS 8 deployment with APs deployed in controller managed mode and directly controlled by Mobility Controllers, migrating to AOS 10 also introduces a major architectural change as Central is now required to operate and manage the APs and Gateways. With this change, the migration to AOS 10 requires the entirety of the AOS 8 configuration be recreated in Central.
Considerations
Familiarity with AOS 10 is a requirement for success with the adoption process; if necessary, review these helpful articles for further information:
- HPE Aruba Networking Central Help - Architectural Overview of AOS10
- Validated Solution Guide - Campus WLAN architecture
- Validated Solution Guide - Campus WLAN deployment
- Supported Devices for AOS 10
Prerequisites
Make sure to validate that all of the applicable prerequisites are met before attempting to migrate any hardware to AOS 10.
General
-
The device hardware (AP or Gateway) is supported on AOS 10.
-
Devices are present within the inventory of HPE GreenLake Edge-to-Cloud Platform (GLCP) and have a valid application and subscription applied; see Setting up Your Aruba Central Instance for assistance.
- The
pre-validate
option for conversion of controller managed APs requires pre-provisioning the AP into an AOS 10 Access Point Group in Central.
- The
-
Devices can resolve all applicable FQDNs and reach those targets on required ports; refer to the guide “Opening Firewall Ports for Device Communication” for assistance.
-
Access Points must be running IPv4 or dual stack mode; native IPv6 on APs is not supported
-
Using AirWave 8.2.15.1 or later to perform a firmware upgrade to AOS 10 is not possible.
Instant APs
-
Instant APs must be running Instant AOS 8.6.0.18, 8.7.1.0, or later releases for a successful firmware upgrade.
-
A cluster of Instant APs must not contain any AP models not supported by AOS 10; attempting to upgrade a mixed model cluster that contains models unsupported in AOS 10 will result in an upgrade failure. Make sure to remove all unsupported models from the cluster prior to attempting the upgrade.
-
Instant APs must not have the uplink native VLAN configured as the VLAN configuration is not retained or migrated through the software upgrade.
Instant APs configured with an uplink native VLAN will have connectivity issues after upgrading to AOS 10. Configuration through the WebUI of the “Uplink Switch Native VLAN” or through the CLI of the “enet-vlan” values will not behave in the same manner in AOS 10. Instant AOS 8 automatically used the configured native VLAN as the management VLAN; AOS 10 does not. Instant APs must be operating without the uplink VLAN set for successful migration and operation of the AP post upgrade.
Support for configuration of native and management VLANs on AOS 10 APs is available with AOS 10.5. Once the AP has been upgraded to AOS 10.5 or later, the native and/or management VLAN can be configured through Central.
Controller based APs
-
To convert controller managed APs, the associated gateway should be running AOS 8.10.0.12, 8.12.0.1, or a later release.
-
If using release of AOS 8.10 prior to 8.10.0.5, transferring an image to the controller using SCP will result in incorrect permissions applied to the image; upload the image to the controller using a method other than SCP.
-
If using release of AOS 8.10 prior to 8.10.0.11 and CPSec is enabled, the pre-validate operation will fail due to the packet routing used for CPSec; bypassing the validation process will allow the upgrade to complete at the risk of incomplete setup of the APs.
-
-
If an HTTP proxy is in place between the AP and access to Central, configuration of the HTTP proxy must be completed prior to upgrade. The proxy settings can be configured through the Mobility Conductor or Controller.
Controllers
-
Mobility Controllers/Gateways running AOS 6 or AOS 8 may require manually upgrading the software to AOS 10.
-
Controllers shipped from the factory prior to 2017 and running a version prior to AOS 6.5.1.4 will not contact Activate and therefore will not automatically be upgraded to a version that permits provisioning by Central.
-
Controllers running AOS 6.5.1.4 or later and that have never had a software upgrade (i.e., are essentially new in box from the factory) are capable of contacting Activate and upgrading to a cloud enabled version of AOS.
-
Any controller that has previously undergone a firmware upgrade must be manually upgraded to AOS 10. After the software is loaded, the controller must have the configuration erased (
write erase
) and the appliance must be reloaded to boot AOS 10 before the gateway can be provisioned in Central. -
Controllers already running an AOS 8 based SD-Branch version of software will perform standard provisoning behavior when reloaded after erasing the configuration and can then be managed in Central after initial provisioning.
-
-
Mobility Controllers/Gateways to be upgraded must be removed from any customer assigned Activate folder with existing provisioning rules before attempting the upgrade or connecting to Central.
Feedback
Was this page helpful?
Glad to hear it!
Sorry to hear that.