Migrating to AOS 10

• 1: Preparing Central for AOS 10 Migration
• 2: Access Points
• 2.1: Configuration Retained or Migrated
• 2.2: Migrating Aruba Central Managed Instant APs to AOS 10
• 2.3: Migrating Locally Managed Instant APs to AOS 10
• 2.4: Migrating AirWave Managed Instant APs to AOS 10
• 2.5: Migrating Controller Managed APs to AOS 10
• 3: Upgrading Mobility Controllers to Gateways
• 4: FAQ - Migrating to AOS 10

1 - Preparing Central for AOS 10 Migration

Migrating to AOS 10, regardless of the starting point, requires some initial configuration within Central for the best outcome during migration.

Prepare an AOS 10 Group in Central

1. Create a new group on the Aruba Central account. Go to Global > Organization > Network Structure > Groups. A new group must be created; do not attempt to use a cloned or existing group with IAP 8.X configuration for AOS 10. Use the + (plus sign) button to add a new group.

   

2. Choose the hardware the Group will administer. A single group can contain a single type or a mixture of hardware.
   Group dedicated to APs:
   

   

   
   Group dedicated to Gateways:
   

   

   
   
   Note

   If there is a need to preserve the naming convention for this new AOS 10 group for a particular customer requirement, clone the original group with a different name, move devices to the temporary group, and delete the original. As a good practice, avoid deleting the temporary group until you are completely satisfied with the AOS 10 conversion.

3. Choose ArubaOS 10 as the architecture to use for the new group and select the appropriate Network Role for the APs:
   

   

   
   If creating a group including or dedicated to Gateways, the role for the gateways must be indicated:
   

   

   
   
   Note

   The VPN Concentrator (VPNC) role is available only when configuring a Gateway-only group, the VPNC group cannot contain APs or switches.

4. Select the newly created group and choose the desired hardware type. In the left menu, use the Firmware option to set the firmware compliance to an AOS 10 firmware version. Click Set Compliance in the upper right.
   

   

5. Enable the Set firmware compliance toggle and choose a version of AOS 10 from the dropdown to ensure that devices added to the group will be upgraded appropriately.
   

   

6. Prepare the configuration for this new AOS 10 group by configuring System settings such as country code, time zone, NTP, WLAN configuration, etc. For AP groups, refer to Configuring ArubaOS 10 APs in Aruba Central. Gateway configuration information can be found at Gateway Deployment.

Mixed Model Aruba Instant Cluster

Before migrating a cluster of Aruba Instant APs to AOS 10, any models unsupported in AOS 10 must be removed or moved to a separate management network to split the cluster. Attempting to upgrade firmware to AOS 10 when unsupported models are in the cluster will result in an error for the download and none of the APs will be upgraded.

2 - Access Points

2.1 - Configuration Retained or Migrated

When an AP is loaded with AOS 10 and checks in with Central for the first time, some of the previous configuration is retained on the AP, and a subset of that configuration can be migrated into the configuration for the AP stored in Central. Some of this retained configuration will allow the AP to operate properly on the network. Some settings can cause failures or interruptions.

Potential migration impactful configuration

This is the list of configuration settings, either at the AP or AP Group/Virtual Controller level, that can impact connectivity of the AP to the local network and/or Central when the AOS 8 AP is upgraded to AOS 10.

• DHCP

  • No changes, default configuration.

• Static IP Address

  • Campus: Migrated into the device-level AP configuration in Central.

  • Microbranch: Not supported.

• Native VLAN

  • Native VLAN configuration is not retained on the AP and not migrated to Central. The AP will always assume VID 1 for the native VLAN on the uplink.

• Management VLAN

  • Management VLAN configuration is not retained on the AP and not migrated to Central. The AP will always assume the management interface is VID 1.

• LACP

  • Non-default LACP configuration is retained on the AP and migrated into the device level AP configuration.

• AP1X

  • AP1X configuration is retained on the AP but not migrated into the configuration on Central.

  • Mismatch of configuration can result in AP flapping when synchronized with Central and potentially revert configuration due to loss of connectivity and enact auto-restore.

• HTTP Proxy

  • HTTP proxy configuration is retained on the AP but not migrated into the configuration on Central.

  • Mismatch of configuration can result in AP flapping when synchronized with Central and potentially revert configuration due to loss of connectivity and enact auto-restore.

• PPPoE

  • Nothing is retained or migrated into Central.

• Mesh

  • The existing mesh profile will be retained on the AP for the purpose of allowing reconnection to a mesh network.

Configuration required to maintain or restore connectivity

In some situations the upgrade will cause the AP to operate in a partially functional state, with the local configuration continuing to provide connectivity but the pushed Central configuration causing connectivity interruptions. Automatic restoration of the last configuration state should return the AP to a functional state until the configuration is synchronized once again from Central, resulting in the AP state appearing to flap.

• Static IP Address

  • Microbranch: only DHCP is currently supported for IP assignment. Design the deployment around this requirement.

• Native and Management VLAN

  • Configure the AP and/or network so that an untagged VLAN is provided to the AP for management.

  • Deployments that require bridging of VLANs through the AP must postpone upgrading to AOS 10 or account for the potential VID mismatch between AP and switched networks.

• LACP

  • The default LACP state on the AP in AOS 10 is enabled as “Passive”. Best practice is to use this option and configure “Active” only on the switch ports.

• AP1X

  • Before upgrading the AP and placing the device in a Central group, configure the AP settings within the target Central AP group with the appropriate AP1X settings to maintain operation.

• HTTP Proxy

  • Before upgrading the AP and placing the device in a Central group, configure the AP settings within the target Central AP group with the appropriate HTTP Proxy settings to maintain operation.

• PPPoE

  • The AP must be connected to a network that provides a DHCP IP assignment and can be configured with PPPoE settings for the end installation location.

• Mesh

  • Before upgrading the AP and placing the device in a Central group, configure the AP settings within the target Central AP group with the appropriate mesh settings to maintain operation.

2.2 - Migrating Aruba Central Managed Instant APs to AOS 10

Upgrade process

1. Go to Global > Organization > Groups. On the Network Structure tab, find the group in which the InstantOS 8 APs are present.

2. Select the Virtual Conductor and/or APs to be migrated by clicking the entry in the list, then click the Move Devices button to choose a target AOS 10 enabled group as the destination
   

   

   
   
   Note

   Moving an IAP acting as the Virtual Controller (VC) also moves the member APs to the new group.

3. After this action, the following AP boot process starts:

   • Aruba Central upgrades APs to AOS 10.

   • APs boot up in AOS 10 mode and reconnect with Aruba Central using AOS 10 firmware.

   • Aruba Central performs a configuration audit and pushes the AOS 10 config from the destination group.

   • Aruba Central cleans up the old, swarm-related state.

Revert to Aruba Instant 8

If needed, convert the APs back to Aruba Instant 8:

1. Make sure a firmware compliance policy matching the current IAP version is configured on the original group.
   

   Caution

   Setting this compliance is crucial. If the compliance is not set and the AP is moved back into an Aruba Instant 8 group, a configuration mismatch will occur.

2. Move the APs back to the original group.

3. After the APs are moved, Aruba Central pushed the specified image to the APs. The APs reboot and resume operation as Aruba Instant 8 APs.

2.3 - Migrating Locally Managed Instant APs to AOS 10

One of the first requirements for migrating to AOS 10 is to prepare the AP for management by adding to GLCP and Central. Once that has been done, even the locally managed IAP is just another Central managed IAP.

Upgrade process

1. Go to Global > Organization > Groups. On the Network Structure tab, expand the Unprovisioned devices group.

2. Select the Cluster and/or APs to be migrated by clicking the entry in the list, then click the Move Devices button to choose a target AOS 10-enabled group as the destination.
   

   

   
   
   Note

   Moving a VC also moves the member Instant APs to the new group.

3. After this action, the following AP boot process starts:

   • Aruba Central upgrades the APs to AOS 10.

   • APs boot up in AOS 10 mode and reconnect with Aruba Central using AOS 10 firmware.

   • Aruba Central performs a configuration audit and pushes the AOS 10 config from the destination group.

   • Aruba Central cleans up the old, swarm-related state.

Alternate methods

1. IAPs can be directly upgraded to an AOS 10 image using one of the traditional upgrade methods through the WebUI or CLI. Add the APs to Aruba Central. After they are rebooted, the APs will operate as AOS 10 APs managed by Aruba Central. This step could be used if the current running version on the IAPs is 8.5 or earlier.

2. Using TAC’s help, with Activate:

   • AOS 10 image can be pushed to APs.
   • APs are added to Aruba Central.

Revert to Aruba Instant 8 and local control

If needed, convert the APs back to Aruba Instant 8 and use local control again:

1. Create a new AP group for Aruba Instant 8 and set a firmware compliance policy to the desired version of software.
   

   Caution

   Setting this compliance is crucial. If the compliance is not set and an AP is moved back into an Aruba Instant 8 group, a configuration mismatch will occur.

2. Move the APs to the newly created ArubaOS 8 group.

3. After the APs are moved, Aruba Central pushes the specified image to the APs. The APs reboot and resume operation as Aruba Instant 8 APs.

4. After the APs are converted successfully back to AOS 8, remove the Central application assignment using the HPE GreenLake console to remove the APs from Central management.

5. Reboot the IAP cluster to immediately revert to local management.

2.4 - Migrating AirWave Managed Instant APs to AOS 10

Upgrade process

1. Remove AirWave discovery options or configuration:

   • If the APs get their AirWave information from DNS discovery or DHCP options, remove the relevant pieces from the DNS zone or DHCP scope configuration.

   • If the APs get their AirWave information from Activate, remove the provisioning rule from Activate.

   • If the APs are manually configured to report to AirWave, no additional actions are required.

2. Skip this step if the APs are in Managed mode with AirWave. For Monitor Only mode, make sure that AirWave has been configured to allow firmware upgrades. In AirWave, go to AMP Setup > General > Firmware Upgrade/Reboot Options and set the ‘Allow firmware upgrades in monitor-only mode’ option to ‘Yes’.
   

   

3. Upload all the necessary AOS 10 images to support the APs to be migrated by following the directions in the AirWave User Guide subject “Uploading Files and Firmware”. Be sure to provide images for each class of Instant AP.

4. In AirWave, go to Groups > List and click the group containing the APs to be migrated.
   

   

5. Assign the desired AOS 10 firmware version to be used for the upgrade by choosing the version from the “Aruba Instant Virtual Controller” dropdown in the Group’s Firmware menu. Select the Enforce Group Firmware Version to have AirWave immediately begin an upgrade.
   

   

6. Click the Save and Upgrade Devices button.
   

   

7. The firmware upgrade process follows these steps:

   • AirWave upgrades the APs to AOS 10.

   • The APs boot to AOS 10, receive provisioning rule to connect to Aruba Central from Activate, and then connect to Aruba Central, where the APs are placed in the assigned group.

   • Aruba Central performs a config audit and pushes the group configuration.

   • Aruba Central cleans up the old swarm-related state.

8. Migrated Aruba Instant APs must be removed from AirWave manually.

Alternate method

The APs also can be upgraded locally:

1. Remove configuration pointing the APs at AirWave:

   • Server configuration: Remove all the AirWave configuration from DNS, DHCP, and/or Activate servers.

   • Local configuration: Remove the AirWave configuration from the System tab on the IAP.

2. Remove the APs from AirWave by deleting them. The Instant APs revert to local management after AirWave has ceased management

3. Follow the steps in the “Locally Managed Instant APs” section.

Revert to Aruba Instant 8 and AirWave management

If needed, convert the APs back to Aruba Instant 8 and use AirWave management again:

1. Create a new AP group for ArubaOS 8 and set a firmware compliance policy to the desired version of software.

1. Move the APs to the newly created ArubaOS 8 group.

2. After the APs are moved, Aruba Central pushes the specified image to the APs. The APs reboot and resume operation as Aruba Instant 8 APs

3. After the APs are successfully converted back to AOS 8, remove the Central subscription using the HPE GreenLake console to remove the APs from Central management.

4. Reboot the IAP cluster to revert to local management.

5. Enroll the IAP cluster to AirWave using the original method implemented.

2.5 - Migrating Controller Managed APs to AOS 10

Convert controller managed APs by using the existing infrastructure or by using a separate controller set up for the purpose. If the existing infrastructure is not running a correct software version to support the conversion, the APs can be re-provisioned statically to a separate, temporary controller that has been loaded with one of the required software versions.

When using a cluster and planning which APs are to be converted, consider which controller the APs are connected to. The AP conversion process can be started only from the currently active controller for the AP. If a large cluster is in production, consider using a separate, non-clustered controller for AP staging and upgrading.

The conversion from AOS 8 to AOS 10 uses the “ap convert” command.

ap convert
  active {all-aps|specific-aps}
  add {ap-group|ap-name}
  cancel
  clear-all
  delete {ap-group|ap-name}
  pre-validate {all-aps|specific-aps}

Upgrade process

Using the CLI on the controller:

1. Add APs to the conversion list by specifying the AP Group using the command:

   (host) [mynode] #ap convert add ap-group <group-name>

   or add individual APs into the conversion list using the command:

   (host) [mynode] #ap convert add ap-name <ap-name>

2. Pre-validate the APs added to the conversion list:

   (host) [mynode] #ap convert pre-validate specific-aps

   This command checks the connectivity to Central before attempting to push the firmware conversion. This command prompts the APs to check NTP, Activate, and Central URL reachability and checks if the APs are licensed on Central with a group assigned. This can be useful in narrowing down issues that might occur during the conversion process.

3. Verify the conversion pre-validation status:

   (host) [mynode] #show ap convert-status

   If the pre-validation is successful, the ‘Upgrade Status’ should read ‘Pre Validate Success’, and the assigned ‘Aruba Central Group’ is displayed.

4. The pre-validation job continues until canceled. After all APs have been tested, issue the command to cancel the job and move forward:

   (host) (host) [mynode] #ap convert cancel

5. Download the AOS 10 firmware files for the AP models to be upgraded. Download image files from HPE Networking Support Portal or with assistance of an HPE Aruba Networking account team.

6. Firmware images can be specified individually by AP type, or a TAR file containing all the images can be created to simplify file handling.

7. Firmware images are delivered to the APs by a file server or directly from the controller

   • If using the ‘server’ option, use an ftp, tftp, http, https, or scp server and copy the AOS 10 image files to the server.

   • If using the ‘local-flash’ option, the AOS 10 firmware image file(s) must be copied to the controller’s flash using the ‘copy’ command on the CLI or under Controller > Diagnostics > Technical Support > Copy Files on the GUI.

   • In addition to the local options, the firmware can be pulled from the web using the Central software repository at common.cloud.hpe.com/ccssvc/ccs-system-firmware-registry/IAP

8. Execute the command to trigger the conversion using ftp, tftp, http, https, or scp as one of the available options for the server.

   Examples:

   (host) [mynode] #ap convert active specific-aps server scp username <username> <hostname> <image filename>

   or

   (host) [mynode] #ap convert active specific-aps server http common.cloud.hpe.com path ccssvc/ccs-system-firmware-registry/IAP <image filename>

   Note

   Multiple filenames can be used in the command above if there is more than one model of AP present in the group by using a semi-colon “;” delimiter, e.g.:

   (host) [mynode] #ap convert active specific-aps server scp username admin 1.2.3.4 firmware1;firmware2

   or a TAR file containing multiple images can be used e.g.:

   (host) [mynode] #ap convert active specific-aps server scp username admin 1.2.3.4 ImageFile.tar

   or

   (host) [mynode] #ap convert active specific-aps local-flash <image filename>

   Note

   Multiple filenames can be specified in the local-flash if there is more than one model of AP present in the group by using a semi-colon “;” delimiter, e.g.:

   (host) [mynode] #ap convert active specific-aps local-flash firmware1;firmware2

   or a TAR file containing multiple images can be used e.g.:

   (host) [mynode] #ap convert active specific-aps local-flash ImageFile.tar

   A third option, ‘activate’, is available but not currently recommended for use.

9. Verify the conversion status using:

   (host) [mynode] #show ap convert-status

10. The firmware upgrade process follows these steps:

    • The controller upgrades the APs to AOS 10.

    • The APs boot to AOS 10, receive the provisioning rule to connect to Central from Activate, and connect to Central which places the AP in the assigned group.

    • Central performs a config audit and pushes the group configuration.

    • Central cleans up any old configuration on the APs except for the uplink parameters.

Troubleshooting

AP groups or individual APs can be removed from the conversion list using the relevant command below:

(host) [mynode] #ap convert delete ap-group <ap-group>

(host) [mynode] #ap convert delete ap-name <ap-name>

To clear all APs from the conversion list, execute the following command:

(host) [mynode] #ap convert clear-all

To abort the conversion of APs or stop the pre-validation tasks:

(host) [mynode] #ap convert cancel

Revert to AOS 8 firmware version

If needed, convert the APs back to AOS 8:

1. Make sure that the target controller is licensed and has the capacity to add the APs.

2. Make sure no conversion tasks are pending on the controller from previous conversions; otherwise APs will try to convert back to AOS 10.

   (host) [mynode] #show ap convert-status

   If the current status is ‘Active,’ the running job must be canceled:

   (host) [mynode] #ap convert cancel

3. Open the AP’s console using serial, SSH, or Central Remote Console.

4. Issue the command to the AP for conversion back to controller-based:

   convert-aos-ap cap <controller-address>

   • The AP will download the AOS 8 image from the controller and reboot.

   • The AP will sync configuration based on provisioning status

5. After the APs are successfully converted back to AOS 8, remove the Central subscription using the HPE GreenLake console to remove the APs from Central management

3 - Upgrading Mobility Controllers to Gateways

In AOS 8, the Mobility Controller provides many services that have been moved to Central in AOS 10. To reflect the change in functionality and to better describe the role of the appliance, the name has been changed to Gateway. The two names often are used interchangeably; however, for AOS 10, the correct terminology is Gateway.

Zero Touch Provisioning

Zero Touch Provisioning (ZTP) is a fast, convenient way to onboard a new or existing Gateway into Central without requiring configuration from the installer. Successful ZTP requires the Gateway to be connected to a switchport configured with an untagged VLAN that provides DHCP addressing and Internet access. Any port on a Gateway except GE 0/0/1 can be used for ZTP.

Depending on how the Gateway is deployed or connected to the LAN, ZTP can be performed over a WAN port, uplink port, or a dedicated staging port. A dedicated staging port can be used to onboard a Gateway in situations where the management VLAN will be 802.1Q tagged on the Gateway uplink, the Gateway is connected using LACP trunks, or DHCP services are not available. After a Gateway is provisioned and configured by Central, the Gateway can be configured to use a desired uplink port(s).

Provision the Gateway

1. To monitor the ZTP process, connect to the serial console port on the Gateway and power on the Gateway. After booting, the initial provisioning screen is presented:

   

   Note

   You can view the full ZTP exchange by typing enable-debug in the setup screen before connecting the Gateway’s ZTP port to the switchport.

2. Connect a ZTP-capable port on the Gateway to a switchport configured with an untagged (access) VLAN that provides DHCP and Internet access. All ports on the Gateway support ZTP except GE 0/0/1.

   

3. After receiving a DHCP response, the Gateway resolves the Activate FQDN and communicates with Activate for provisioning:

   • If the Gateway is new and has not been previously provisioned, Activate will push a Central-enabled firmware upgrade and reboot the Gateway.

   • Activate provisions the Gateway with the FQDN for the assigned Central instance.

4. After booting to a Central enabled firmware and being provisioned with the FQDN, the Gateway can communicate with Central.

5. The firmware version defined in firmware compliance for the Group is enforced and an upgrade is pushed if necessary. After the upgrade is complete, the Gateway reboots.

6. The Gateway initializes using the specified AOS 10 version, contacts Central for configuration, based on the Central’s assigned device configuration.

7. After the configuration is applied successfully, the Gateway is up and operational in Central using the staging port or the configured uplink port(s).

Static Activate

Static activate is a one touch provisioning (OTP) option used to provision a Gateway that requires static addressing or PPPoE authentication. The OTP process requires the installer to use a serial console port or web browser to supply minimum information to the Gateway to permit initial communication with Activate and Central. The use of a web browser requires a computer to be connected to the Gateway on the GE 0/0/1 Ethernet port, which provides a DHCP address for local access.

The available configuration options vary by release when using OTP. A new Gateway shipped from the factory currently is loaded with a version of AOS 8 that permits provisioning over PPPoE WAN links or an untagged VLAN but does not support provisioning a new Gateway over an 802.1Q tagged VLAN or an LACP trunk. Gateways already upgraded to AOS 10 support provisioning using 802.1Q tagged VLANs and/or LACP trunks.

Serial Console

1. Connect to the serial console port on the Gateway and power on the Gateway. After booting, the initial provisioning screen displays:

   

2. Type “static-activate,” then press ENTER to start the process. Choose the options appropriate for the required uplink type (“static” or “pppoe”), then provide the required information. The example shows a statically configured IP address:

   

3. After initial provisioning is complete, the Gateway resolves the Activate FQDN and communicates with Activate for further provisioning:

   • If the Gateway is new and has not been provisioned, Activate pushes a Central-enabled firmware upgrade and reboots the Gateway.

   • Activate provisions the Gateway with the FQDN for the assigned Central instance.

4. After booting to a Central-enabled firmware and provisioning with the FQDN, the Gateway can communicate with Central.

5. The firmware version defined in firmware compliance for the Group is enforced. An upgrade is pushed if necessary. After the upgrade is complete, the Gateway reboots.

6. The Gateway initializes using the specified AOS 10 version, then contacts Central for configuration based on assigned Central device configuration.

7. After configuration, the Gateway is up and operational in Central.

Web-UI

1. Connect a computer to the GE 0/0/1 Ethernet port on the Gateway. An IP address will be offered by DHCP in the 172.16.0.0/24 network. Open a web browser and navigate to https://172.16.0.254, proceeding past the warning for the invalid SSL certificate:

   

2. Select By connecting to activate/central, then click Next:

   

3. Select Static IP Address or PPPoE as the connection method. Enter the required information. The example below provisions a Gateway to use the GE 0/0/0 port and a static IP address; a Gateway running AOS 10 has additional options for a trunk port and port-channel:

   

4. Verify that the information is correct then click Deploy and Reboot.

   

5. After the initial provisioning is complete, the Gateway resolves the Activate FQDN and communicates with Activate for further provisioning:

   • If the Gateway is new and has not been previously provisioned, Activate pushes a Central-enabled firmware upgrade and reboots the Gateway.

   • Activate provisions the Gateway with the FQDN for the assigned Central instance.

6. After booting to a Central-enabled firmware and provisioning with the FQDN, the Gateway can communicate with Central.

7. The firmware version defined in firmware compliance for the Group is enforced and an upgrade pushed if necessary. After the upgrade is complete, the Gateway reboots.

8. The Gateway initializes using the specified AOS 10 version and contacts Central for configuration based on the assigned Central device configuration.

9. After the configuration is applied successfully, the Gateway is up and operational in Central.

4 - FAQ - Migrating to AOS 10

Is my AP supported on AOS 10?

Find your model in the list: Supported Devices for AOS 10

Can I convert my existing Central group to AOS 10?

No. The configuration constructs behind the scenes do not allow for a direct conversion from a group supporting IAP to a group supporting AOS 10.

Can I duplicate my AOS 10 group?

You can clone the existing group as long as no orchestrated configuration, i.e., tunneled or mixed WLANs, has been setup.

Can my AP be downgraded back to AOS 8 or IAP 8 after converting to AOS 10?

Yes. Steps are mentioned at the end of each section above.

What happens if the AP is configured with an uplink VLAN prior to upgrade?

In Aruba Instant 8, the AP automatically uses the uplink native VLAN as the management VLAN, but AOS 10 does not. AOS 10 continues to expect management to occur on VLAN 1 and will tag the management traffic on the uplink. Make sure to clear the uplink native VLAN configuration before installing AOS 10 to prevent the AP from losing communication.