Upgrading from ArubaOS 8 to 10

This section details the process of migrating from ArubaOS (AOS) version 8 campus mode to AOS 10 tunnel mode for Orange Widget Logistics (OWL), the fictional company introduced on the Reference Customer page. It is intended for IT professionals familiar with AOS 8 seeking a clear example of an upgrade process that they can reference and modify for their own migration projects.

It is important to note that the information in this guide is not meant as a complete reference. Experienced network professionals should be involved. For more details, check the links in the Related Content section at the top right of this page or contact HPE Aruba Networking for further assistance.

Project Overview

OWL is expanding. It recently acquired a company using AOS 8 WLAN architecture. To align with OWL’s firmware compliance standards, the first site of this newly acquired company will be upgraded to AOS 10. The goal is to complete the upgrade with minimal downtime within a short maintenance window.

The diagram and list below provide an overview of the site to be upgraded.

Assumptions

To keep the focus on the upgrade steps, the implementation engineer has discretion over related tasks typically associated with an infrastructure upgrade or implementation project. Assumptions regarding these tasks include.

• The customer’s HPE GreenLake account has been created.
• Subscriptions and licenses have been purchased.
• Controllers at the site are part of an L2 cluster.
• Pre-upgrade validations and health checks of both controllers and APs have been performed to identify and resolve existing issues to reduce chances of upgrade complications.
• Rollback procedures for each stage have been documented and are ready if necessary.
• Diverse client devices (phones, laptops, IoT) have been set aside and are ready for client testing and mimic production as closely as possible.
• Monitoring strategy is in place to proactively identify latent issues post-upgrade (e.g. performance degradations, roaming inconsistencies)

Preparation

To ensure a successful deployment, verify that all requirements listed in the AOS 8 to 10 Planning guide have been met before beginning the upgrade.

Prerequisites

The prerequisite list below applies to this example site. It is critical that all guidance is reviewed.

• APs and controllers must be able to reach Central.
• Ensure that the controllers are running 8.10.0.12, 8.12.0.1, or a later release before upgrading to AOS 10.
  • More details can be found in the Controller-based APs section of the AOS 10 guide
  • This site starts at AOS 8.9 to highlight the need to be at the proper code version before upgrading. The proper version can be downloaded from the HPE Networking Support Portal and installed on the site’s controllers and APs before proceeding to the next step.
• Ensure that controller discovery is configured properly, whether it is AP system profile, DHCP options, DNS, or ADP.
  • If the AP system profiles are set up using LMS IP addresses, verify that they are configured for the controllers’ VRRP virtual IP address, not for an individual controller’s management IP. This prevents APs from becoming stranded if they reboot after the controller for which they are statically configured is no longer available because it was upgraded to AOS 10 first.
  • More information about AP controller discovery can be found in the AOS 8 to 10 Planning Guide’s Access Points section.
• Make sure campus AP management and tunnel mode client VLANs are configured according to the AOS 8 to 10 Planning Guide’s Tunnel Mode SSID section.

AOS 8 Configuration Discovery

To configure the new AOS 10 solution in Central, collect all necessary information from the existing AOS 8 environment.

Gather Necessary Information

The graphic below provides some examples of where and how relevant information can be found for an AOS 8 to 10 upgrade project.

The following guidance expands on the information in the graphic above. It is one example of extracting the required information for an AOS 8 to AOS 10 upgrade. The methods may vary based on the use case.

Mobility Conductor Information Gathering

Launch a command line session using PuTTY, SecureCRT, or any preferred CLI tool. Enable logging and execute the “no paging” command to ensure that recorded outputs appear without the need for repeatedly pressing the space bar for more extended outputs. Additionally, use “encrypt disable” to view passphrases in clear text.

Step 1 Collect configuration node hierarchy.

• Purpose: Understand the existing configuration structure to plan and build the AOS 10 Site and Group hierarchy in Aruba Central.

• Command:

  (MobilityConductor) [mynode] #show configuration node-hierarchy
  

Step 2 Identify configuration nodes and commit locations.

• Purpose: Map where the current configuration was committed to determine where it will be applied in AOS 10.

• Commands:

  (MobilityConductor) [mynode] #show configuration effective detail <node path>
  (MobilityConductor) [mynode] #show configuration committed <node path>
  

Step 3 Record AP inventory.

• Purpose: Collect a detailed inventory of all APs for onboarding to Aruba Central and use as a baseline for validation post-upgrade.

• Information to Record:

  • AP Model
  • MAC Address
  • Serial Number

• Command:

  (MobilityConductor) [mynode] #show ap database long
  

Mobility Controller Information Gathering

Launch a command line session using PuTTY, SecureCRT, or any preferred CLI tool. Enable logging and execute the “no paging” command to ensure that recorded outputs appear without the need for repeatedly pressing the space bar for more extended outputs. Additionally, use “encrypt disable” to view passphrases in clear text.

Step 1 Collect AP group and WLAN-related configuration.

• Purpose: Record SSID, RF, and other WLAN-related configurations associated with each AP group. This will be applied to the AOS 10 environment.

• Commands:

  (USWH1MC01) [MDC] #show ap-group
  (USWH1MC01) [MDC] #show ap-group <group name>
  

• Details: Replace <group name> with one of the discovered AP groups to view the Virtual AP (VAP), 802.11 radio, and other profiles associated with the group.

Step 2 Record associated clients and authenticated users.

• Purpose: Establish a baseline of associated clients and authenticated users for validation after the upgrade.

• Commands:

  (USWH1MC01) [MDC] #show ap association
  (USWH1MC01) [MDC] #show user-table
  

Step 3 Identify the APs’ LLDP neighbors.

• Purpose: Record the switch and port where each AP is physically connected. This information will be useful for troubleshooting individual APs, if needed, during the upgrade.

  Command:

  (USWH1MC01) [MDC] #show ap lldp neighbors
  

Step 4 Review Active ESSIDs.

• Purpose: Summarize active SSIDs and track the number of APs servicing clients for each SSID.

• Command:

  (USWH1MC01) [MDC] #show ap essid
  

Step 5 Record Active APs and radio stats.

• Purpose: Collect data on all active APs broadcasting and their radio statistics to validate performance after the upgrade.

• Command:

  (USWH1MC01) [MDC] #show ap active
  

Step 6 Record the running config of each mobility controller.

• Purpose: Collect data to reference, validate, and obtain context for analysis

• Command:

     (USWH1MC01) [MDC] #show running-config
  

AirWave Information Gathering

In addition to mobility information gathering, AirWave provides an alternative way to view and validate:

• Group and Site structure.
• AP inventory, including associated SSIDs and configuration details.

Note: AirWave may overlap with some of the data collection points above, serving as a helpful cross-check during the migration process.

Checklist for Information Collection

Additional Helpful CLI Commands

Execute the commands above on the active mobility conductor and on both AOS 8 controllers that are being upgraded to AOS 10 gateways.

Implementation Engineer Notes

• Efficiency Tip: Use AirWave to consolidate some of the data above, especially for Group and Site structures.
• Cross-Validation: After collecting the data, compare outputs from AirWave and CLI commands to ensure consistency.
• Backup: Save all collected outputs in a structured format (e.g., spreadsheets) for reference during and after the upgrade.

AOS 8 Profile to AOS 10 Group WLAN Configuration Reference

The image below illustrates a general overview of the AOS 8 configuration and its corresponding settings within the AOS 10 group configuration page. The information collected from the previous discovery steps will supply all the parameters necessary for a successful upgrade.

Switchport Configuration Verification

When transitioning to an AOS 10 Tunneled AP deployment, the configuration of AP switchports depends on the WLAN deployment mode. Switchport configuration examples based on the WLAN forwarding mode are provided below.

Tunnel Mode Only WLANs

• Description: All WLANs are configured in Tunnel Mode, where client traffic is tunneled back to the Mobility Gateway.
• Port Configuration: AP switchports can be configured as access ports since no VLAN tagging is required for wireless client traffic.
• Alternative Option: Switchports also can be configured as trunk ports, but the native VLAN must match the access VLAN configuration to ensure that AP management traffic is handled properly (similar to AOS 6 or 8 campus mode deployments).

Configuration Example (Access Port):

interface 1/1/1 
  no shutdown
  description ACCESS_PORT
  no routing
  vlan access 23

Bridge Mode WLANs

• Description: In this situation, one or more WLANs operate in Bridge Mode, where client traffic is bridged locally onto the VLANs tagged on the AP switchport.
• Port Configuration:
  • AP switchports must be configured as trunk ports to allow bridged wireless traffic to access specific data VLANs.

Configuration Example (Trunk Port):

interface 1/1/2 
  no shutdown
  description TRUNK_PORT
  no routing
  vlan trunk native 23
  vlan trunk allowed 1-3,5-6

Mixed Mode WLANs

• Description: Use a trunk port configuration to support Mixed Mode WLANs, ensuring the native VLAN is set properly and allowed VLANs are pruned as required.
• Port Configuration:
  • Native VLAN for AP management traffic.
  • Tagged VLANs for bridged wireless traffic in Mixed Mode WLANs.
  • Prune all VLANs used for tunneled WLAN clients.

Configuration Example (Trunk Port):

interface 1/1/2
  no shutdown
  description TRUNK_PORT
  no routing
  vlan trunk native 23
  vlan trunk allowed 1-3,5-6

Checklist for Switchport Recommendations

Switchport Tips for Implementation

• Access Port Simplicity in Tunnel Mode: Using access ports in a Tunnel Mode Only deployment simplifies configuration and eliminates the need to manage trunk VLANs.
• VLAN Management in Mixed Mode: Be diligent about pruning VLANs for tunneled traffic in Mixed Mode WLANs to avoid misconfigurations that could lead to broadcast storms or unexpected traffic flows.
• Documentation: Keep a clear record of VLAN assignments for each port, especially in environments where both Tunnel Mode and Mixed Mode WLANs coexist.
• Validation: After configuring switchports, validate AP connectivity and client traffic flows to ensure that management, tunneled, and bridged traffic is properly routed.

By following these guidelines and examples, implementation engineers can confidently configure AP switchports to support the requirements of AOS 10 deployments while minimizing misconfiguration risks and ensuring efficient traffic management.

Preparing Configuration Information

To configure this site’s new AOS 10 environment, extract the relevant information from the AOS 8 Configuration Discovery section above.

Mobility Gateway Information

Configurations needed for this site are listed below.

AOS 8 Controller vs. AOS 10 Gateway Settings: Reference Examples

In the example above, the configurations can be collected by executing the show running-config command on each of the AOS 8 controllers. For the one below, the remainder of the settings for the Gateway Information Table is collected using the show inventory, show ap essid, and show running-config I begin “aaa authentication-server” commands detailed earlier in this guide.

VLAN Information

VLANs needed for this site include:

WLAN Information

The following parameters are needed to configure the WLANs in AOS 10, beginning with the CorpNet SSID.

CorpNet SSID (802.1X/Enterprise)

802.1X SSID Configuration Reference Example

The images below illustrate the sources of information for the CorpNet SSID configuration in the AOS 8 settings. In this project, the WLAN configuration has already been established and inherited since it was set at the Global scope in Central. However, an example from the AOS 10 WLAN configuration wizard is provided below to demonstrate how the two configuration versions are related.

The General tab below contains many base and advanced settings. For this project, there are three that apply:

• ESSID found in the SSID profile.
• Allowed bands in the VAP.
• Legacy transmit rates in the SSID profile.

The VLANs tab below needs the following:

• The traffic forwarding mode is not highlighted but it is set to tunnel based on design discussion during the planning phase.
• The primary gateway cluster also is not highlighted but it is needed and must be configured before WLAN configuration occurs.
• The VLAN ID is found in the VAP.

The Security tab below needs the following:

• The security level is set to Enterprise.
• The key management method is found under the SSID profile in AOS 8.
• The primary and secondary RADIUS servers are found under authentication servers.

Note: The settings above are not the only requirements for a functioning AOS 10 WLAN. This example serves to give the implementer an understanding of the process, enabling them to expand it for their own network.

OpsNet SSID (WPA3-Personal)

The following settings are needed for the OpsNet SSID.

WPA3-Personal Configuration Reference Example

The images below illustrate the sources of information for the OpsNet SSID configuration in the AOS 8 settings. In this project, the WLAN configuration has already been established and inherited since it was set at the Global scope in Central. However, an example from the AOS 10 WLAN configuration wizard is provided below to demonstrate how the two configuration versions are related.

The General tab contains many base and advanced settings. For this project, there are three that apply:

• ESSID is found in the SSID profile.
• Allowed bands are in the VAP.
• Legacy transmit rates are in the SSID profile.

The VLANs tab needs the following:

• The traffic forwarding mode is not highlighted but it is set to tunnel based on design discussion during the planning phase.
• The primary gateway cluster also is not highlighted but it is needed and must be configured before WLAN configuration occurs.
• The VLAN ID is found in the VAP.

The Security tab needs the following:

• The security level is set to Personal.
• The key management method is found under the SSID profile in AOS 8.
• The WPA passphrase also is found under the SSID profile.

Note: The settings outlined above are not the sole requirements for an operational AOS 10 WLAN. These configurations pertain specifically to this use case and may vary for different situations. This example is intended to provide implementers with a clear understanding of the process, allowing them to adapt it for their own network needs.

Prepare Central

Perform HPE GreenLake Platform Initial Setup

To prepare Central for the upgrade, follow the steps in the GreenLake Platform chapter of the VSG, then return to this page to continue.

Configure Groups

Configure Groups according to the data collected during the discovery phase. The steps are in the Wireless Group Configuration chapter of the VSG.

Configure Gateways

Configure gateway appliances according to the Gateway Device Configuration chapter of the VSG and the data collected during discovery.

Configure WLANs

Configure the WLANs by following the steps in the Wireless Access Configuration chapter of the VSG and referencing the information collected during the discovery phase.

Upgrade Site 1

For this site’s migration process, OWL IT will begin by upgrading the first controller in the cluster, proceed to upgrade the access points (APs), and then upgrade the second controller. The example workflow is illustrated below.

Note: Before upgrading to AOS-10, ensure that the AOS-8 environment is running the correct software version, as described in the Prerequisites section of this guide.

Move APs to Controller 1

The two controllers at this site have been configured in a cluster at Layer 2 (L2) for redundancy and load balancing of access points (APs). Before starting the manual upgrade of a controller in an ArubaOS 8.x L2 cluster, it is important to ensure that the cluster is operating as expected and to take steps that minimize any impact on the network. Verifying that the cluster is running in L2-connected mode and then proactively moving all APs to the other, still-active controller helps maintain seamless service continuity and reduces downtime.

The following steps are for confirming cluster stability and moving APs to one of the two AOS 8 controllers in preparation for an upgrade.

Step 1 Verify the cluster is L2-connected.

• Purpose: Verify that the controllers in the cluster recognize each other as cluster members and are L2-connected.

  Command:

  (USWH1MC01) [MDC] #show lc-cluster group-membership
  

Step 1 Move all APs to controller 1.

• Purpose: Although Aruba APs in an L2-connected controller cluster are designed to failover automatically to the second controller in case of a failure, proactively transferring all APs to the controller that will remain operational allows for a more controlled transition. This gives the upgrading engineer one less concern during the upgrade of the primary controller.

  Command:

  (USWH1MC01) [MDC] #apmove all target-v4 172.16.23.48
  

Upgrade First Controller

After all APs have been successfully moved to controller 1 (USWH1MC01), the upgrade of the first controller (USWH1MC02) can begin. The following steps outline how to download the AOS-10 software, upload it to the controller, initiate the upgrade, and verify its status after the reboot. This approach helps maintain a smooth and reliable transition to the new software version.

Step 1 Download AOS-10 software from HPE Networking Support Portal.

Step 2 On a web browser, log into MC02 directly through its IP or FQDN.

Step 3 Go to the Maintenance > Software Management > Upgrade tab and install the recently downloaded AOS-10 image.

Always perform a backup and save a copy of the appliance configuration prior to any upgrade.

Step 4 After the upload is complete, click the button in the window, when prompted, to confirm the reboot.

Step 5 The controller can be monitored through the console during the upgrade process rather than waiting for it to appear in the designated Aruba Central group. In CLI, the console should look similar to the image below. Note ArubaOS Version 10.x at the beginning of the output confirms that the AOS 8 mobility controller is now an AOS 10 mobility gateway.

Step 6 After the newly upgraded gateway is connected to the network and can be seen in the expected Central group, proceed to the AP upgrade process.

Note: This example uses static management IP addresses for each controller or gateway which does not require Zero Touch Provisioning (ZTP). If using ZTP, please refer to the Zero Touch Provisioning section in the AOS 10 guide.

Upgrade First Test AP

Before upgrading the entire fleet of access points, it is advisable to test the conversion process on a single device. The following steps outline how to prepare a test AP, validate its readiness, and initiate the upgrade procedure. Verifying that the process works as intended with one AP helps ensure a smoother transition when scaling the upgrade to the whole site.

Step 1 Log into the active AOS 8 controller (USWH1MC01) via SSH.

Step 2 Add AP to the conversion list using AP name with the following command:

   (USWH1MC01) [MDC] #ap convert add ap-name <ap-name>

Step 4 Pre-validate the test AP with the following command:

   (USWH1MC01) [MDC] #ap convert pre-validate specific-aps

Step 5 Check the status with the following command (expected output should show the Upgrade State as “Pre Validate Success”):

   (USWH1MC01) [MDC] #show ap convert-status

Step 6 Initiate the upgrade of the test AP with the following command:

   (USWH1MC01) [MDC] #ap convert active specific-aps server http common.cloud.hpe.com path ccssvc/ccs-system-firmware-registry/IAP <image name>
   
   EXAMPLE: (USWH1MC01) [MDC] #ap convert active specific-aps server http common.cloud.hpe.com path ccssvc/ccs-system-firmware-registry/IAP ArubaOS_Norma_10.6.0.1_89990;ArubaOS_Scorpio_10.6.0.1_89990

Command usage:

    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}    

Option descriptions:

Tip:

When monitoring APs remotely, verification that APs have at least changed from campus to AOS10 mode can be done by checking LLDP neighbor information from the switch. If it is still running AOS8, it appears as a CAP. If it is running AOS10, it displays as an IAP.

More details can be found in the Controller Managed APs section of the AOS-10 guide, including troubleshooting commands and steps to revert to AOS-8 if necessary.

Upgrade Remaining APs

After the first AP upgrade is successful and the standard client testing procedures are finished, the subsequent batch of APs can be upgraded following the same steps outlined in the previous Upgrade First Test AP section and using the other ap convert command options (e.g., all-aps, ap-group).

Upgrade Second Controller

After all APs have been moved to USWH1MC01, confirm that USWH1MC02 is without APs and follow the steps in the Upgrade First Controller section earlier in this document. When the upgrade is complete, proceed to site validation and other remaining steps.

Additional Tasks and Resources

When all WLAN devices have been upgraded successfully to AOS 10, the remaining steps involve tasks such as configuration validation and stakeholder communication, which differ based on each organization’s IT policies. The suggestions below, while not detailed in this document, will contribute to a successful implementation and a favorable user experience when employees return to the office on Monday morning.

• Pre/post-upgrade validation - Use the information collected during the discovery phase to compare site health before and after changes.
• Troubleshooting - Troubleshooting commands can be found in the Troubleshooting section of the HPE Aruba Networking AOS 10 documentation website.
• Rollback Planning - Find rollback commands in the Revert to AOS 8 Firmware Version section of the HPE Aruba Networking AOS 10 documentation website.
• Upgrade Commands - Some CLI upgrade commands not used in this guide can be found in the Upgrade Process section of the HPE Aruba Networking AOS 10 documentation website.
• Retained vs. Migrated Configuration - Know which information is retained from the previous configuration by visiting the Configuration Retained or Migrated page of the HPE Aruba Networking AOS 10 documentation website.
• AOS 10 Prerequisites - Validate that all applicable prerequisites are met before migrating any hardware to AOS 10 by visiting the Prerequisites section of the HPE Aruba Networking AOS 10 documentation website.
• Instant APs and More - The steps to migrate Aruba Instant APs, whether managed by AirWave, Central, or locally by the IAP cluster’s Virtual Controller (VC) can be found in the Access Points page of the HPE Aruba Networking AOS 10 documentation website.

Conclusion

This guide has covered upgrading from ArubaOS 8 campus mode to AOS 10 tunnel mode, using Orange Widget Logistics as an example. By following steps such as gathering data, aligning prerequisites, confirming switchport configurations, and upgrading controllers and access points, IT professionals can perform the migration confidently. After completion, validate the new environment and reference the provided resources for questions or issues. This method helps maintain network performance, improve user experience, and streamline future infrastructure changes in an AOS 10 environment.