Migration of Access Points

Retained Configuration

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.

Status as of AOS 10.4 / Central 2.5.6

The list below shows 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.

Aruba Central Managed Instant APs

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

Step 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.

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

• Aruba Central upgrades APs to AOS 10 version .
• 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 Firmware Version

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

Step 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.

Step 2 Move the APs back to the original group.

Step 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.

Locally Managed Instant APs

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

Step 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.

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

• Aruba Central upgrades the APs to AOS 10 version.

• 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

Step 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.

Step 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:

Step 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.

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

Step 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

Step 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

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

AirWave Managed Instant APs

Note: AirWave 8.2.15.1 and later does not allow AOS 10 images to be loaded for distribution. If using AirWave 8.2.15.1 or later for management of Aruba Instant, the Instant cluster must be removed from management and upgraded as directed below in the section “Alternate Method”.

Step 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.

Step 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’.

Step 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

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

Step 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

Step 6 Click the Save and Upgrade Devices button

Step 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.

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

Alternate Method

The APs also can be upgraded locally:

Step 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.

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

Step 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:

Step 1 Create a new AP group for ArubaOS 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 the AP is moved back into an Aruba Instant 8 group, a configuration mismatch will occur.

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

Step 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

Step 4 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.

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

Step 6 Enroll the IAP cluster to AirWave using the original method implemented.

Controller Managed APs

Convert Campus APs by using the existing infrastructure or by using a separate controller set up for the purpose. If the existing infrastructure is not running the correct software version to support the conversion (see “Initial Steps for Adoption Success” above), the APs can be provisioned statically to a separate, temporary, controller that has been loaded with one of the required software versions.

When planning the APs to be converted, consider which controller an AP connects to when using a cluster. 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|specified-aps}
  add {ap-group|ap-name}
  cancel
  clear-all
  delete {ap-group|ap-name}
  pre-validate {all-aps|specified-aps}

The steps below are perfomed on the Controller CLI.

Step 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>

Step 2 Pre-validate the Campus APs added to the conversion list:

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

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

Step 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 display.

Step 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

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

Step 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.

Step 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

Step 8 Execute the command to trigger the conversion using ftp, tftp, http, https, or scp as one of the available options for theserver. 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 used in the above command 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.

Step 9 Verify the conversion status using:

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

Step 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 Aruba Central from Activate, and connect to Aruba Central which places the AP in the assigned group.

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

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

Note: The Aruba discovery process is disabled in AOS 10. APs will ignore DHCP/DNS options during boot.

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:

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

Step 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

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

Step 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

Step 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

Note: In some cases, an AP reverted to AOS 8 may not come up on the controller. A powercycle of the AP should resolve the issue.

Note: Conversion of APs from AOS 10 to AOS 8 must be done for each individual AP, the process cannot be performed at the group level.