Planning Aruba AOS 8 to AOS 10 Migration

This section highlights key considerations for a network architecture or operations team planning to migrate from AOS 8 to AOS 10.

Review each layer of the network against the guidelines presented below to plan the steps of the migration accurately.

The information provided here is not intended to be an exhaustive reference. It serves as a starting point for planning an actual project. Experienced network professionals should be involved. Contact Aruba or an Aruba channel partner for further assistance.

Table of contents

• Planning Aruba AOS 8 to AOS 10 Migration
  • AOS 8 Campus Network Architecture Review
    • AOS 8 Campus LAN Design
    • AOS 8 Campus Datapath
    • AOS 8 Wired LAN Common Best Practice
  • AOS 10 Tunnel Mode Architecture Review
    • Datapath Comparison
    • Campus Management and Monitoring
    • SSID Mode Considerations
      • Tunnel Mode SSID
      • Tunnel and Bridge or Mixed Mode SSIDs
    • Features, Functions, and Service Considerations
      • Authentication, Authorization, and Accounting
      • Mobility Controller/Gateway Configuration
      • Access Points
  • AOS 8 Campus to AOS 10 Bridge Mode
    • Authentication Requirements
    • AOS 8 Tunnel and AOS 10 Bridge Mode Datapath
    • Bridge Mode Scaling
  • Mixed Mode

AOS 8 Campus Network Architecture Review

When introduced in 2016, the ArubaOS 8 platform offered new services such as AirMatch, Layer 2 redundant controller clustering (Hitless Failover), Mobility Conductor hierarchy, and more. It provided customers with a more holistic approach to RF management, high availability, and configuration management. To assist with planning a successful upgrade, a brief review of AOS 8 key terms, topologies, and common configurations is provided below.

AOS 8 Campus LAN Design

The collapsed core topology illustrated below represents a common AOS 8 campus deployment. It contains Layer 2 and Layer 3 switches connected by redundant links as the underlay to support a Mobility Conductor hierarchical deployment. External DHCP, DNS, monitoring, and authentication servers are represented by the single “Servers on Prem” icon.

AOS 8 Campus Datapath

In an AOS 8 controller-based deployment, Wi-Fi client traffic is encapsulated in a GRE tunnel between the AP and a controller. As traffic from an endpoint reaches the AP over its radio interface, it is encapsulated and forwarded through the wired LAN to the Mobility Controller. The controller then inspects the traffic, assigns a user role, tags it, and forwards it on a local interface to a trunked user VLAN. The diagram below illustrates this process.

The Guest Network carries untrusted traffic between the guest phone and Internet, via the controller. The Voice Network carries prioritized traffic from a soft client on the laptop to the controller. The Enterprise Network carries trusted corporate traffic between corporate assets such as laptops and printers. A GRE Tunnel transports client data traffic between access points (APs) and the controller. IPsec secures all control plane traffic exchanged between Mobility Conductor and the Mobility Controller.

Two management protocols are used between the components of the network:

• PAPI
  • Process Application Programming Interface is used for ARM, WIDS, and config download via UDP port 8211 between AP and controllers.
  • Note that PAPI between Mobility Conductor and Mobility Controller is encapsulated in IPsec, which is not reflected in the illustration above.
• AMON
  • Advanced Monitoring contains detailed monitoring and diagnostic information such as spectrum, radio stats, and channel utilization. It is sent from Mobility Controller to AirWave in addition to traditional AirWave SNMP polling.
  • Similar to PAPI (above), AMON traffic exists between Mobility Conductor and AirWave; however, it is not reflected in the illustration above.

AOS 8 Wired LAN Common Best Practice

Reviewing AOS 8 best practice can help the architect or delivery engineer better understand existing configuration and deployed services on the AOS 8 network.

Jumbo frame support should be enabled on the wired LAN to support fully encapsulated wireless traffic. This is best practice for AOS 10 as well. Avoid packet fragmentation when possible.

APs supporting only tunnel mode WLANs are connected to an access mode switch port with the native VLAN set to that of the WLAN management VLAN. If APs were deployed to operate in bridge mode, those switch ports likely would be trunked with multiple VLANs for AP management and user access. In some cases, AP ports are trunked to allow rogue AP detection and wired port detection.

AOS 10 Tunnel Mode Architecture Review

The first consideration for planning a successful migration to AOS 10 Tunnel Mode is traffic flow.

Datapath Comparison

Although Wi-Fi client traffic is handled similarly in both AOS 10 Tunnel Mode and AOS 8 Campus Mode, several important changes require planning, as highlighted in the side-by-side diagrams below.

To keep the diagrams as simple as possible while effectively showing the most important elements, both deployments include single appliances. In a real-world deployment, redundancy would be in place to take advantage of Aruba’s Hitless Failover feature. The numbered markers in the illustration above are described below.

Step 1 Wi-Fi client traffic from the corporate laptop and guest phone is encapsulated using GRE in both platforms. The AOS 10 deployment can be configured in Central to encapsulate traffic in GRE with IPsec.

Step 2 AOS 8 Mobility Conductor and AirWave appliances are decommissioned since they are not available in AOS 10.

Step 3 AOS 10 hardware requires Aruba Central for management and monitoring.

Step 4 IPsec, AMON, and SNMP traffic sent to the Mobility Conductor and AirWave AOS 8 is replaced by HTTPS traffic sent from Aruba gateways and APs.

Step 5 PAPI, used for configuration downloads, ARM control, and WIDS in AOS 8, will instead be used for communication between applications for features like cluster formation in AOS 10. For details about how PAPI functions in AOS 10, see the Gateway Clustering link in the Related Content section at the top of this page.

Campus Management and Monitoring

One of the most evident changes described above is the management plane. AOS 8 deployments typically required permitting SNMP, AMON, and IPsec between certain Aruba appliances.

For managing and monitoring, most AOS 10 deployments only require traffic on TCP port 443 between Aruba Central and the management interface of each managed device.

AOS 8 campuses configured to deny Internet access from devices residing in the management LAN must require security policy updates to permit connection with Central. If campus APs cannot connect to the Internet to reach Central, access must be provided before migrating to AOS 10. Refer to the Opening Firewall Ports for Device Communication section of the Aruba Central User Guide for complete details.

SSID Mode Considerations

An SSID in an AOS 10 deployment can be configured for three different forwarding modes:

• Tunnel Mode
• Bridge Mode
• Mixed Mode.

When clients are tunneled to a gateway in Tunnel Mode or Mixed Mode, the AP must be prevented from learning the client device’s wireless MAC address through the AP’s wired interface. This requires careful consideration when reusing existing campus VLANs for wireless data traffic.

Tunnel Mode SSID

In a deployment using Tunnel Mode SSIDs exclusively, configure AP switch ports in access mode with a VLAN ID that is the AP management VLAN for the campus. This VLAN must not be reused for wireless tunneled client data traffic. When client traffic is switched at the controller onto a user data VLAN, ensure it is distinct from the VLAN used for AP management.

Tunnel and Bridge or Mixed Mode SSIDs

When using Bridge Mode or Mixed Mode, it is necessary to configure AP switch ports in trunk mode and distribute data VLANs for bridged wireless traffic on those switch ports. Data VLANs used for tunneled wireless traffic must be pruned on switch ports used for APs serving Bridge Mode or Mixed Mode SSIDs. Bridged and tunneled clients cannot share the same VLAN.

Some AOS 8 deployments extend the data VLAN of a tunneled SSID to AP switch ports. Prune these VLANs from the AP switch ports to prepare AOS 10 for Tunnel Mode SSIDs.

The decision chart below shows one method to address the VLAN requirements described above:

Features, Functions, and Service Considerations

The following tables serve as convenient reference for important features, requirements, and functional differences between AOS 8 and AOS 10.

Authentication, Authorization, and Accounting

To ensure that 802.1X WLAN client authentications continue uninterrupted after migrating to AOS 10, updates may be needed in the NAD/RADIUS client IP list on all RADIUS servers. When using Internal Authentication Server or EAP-Offload, prepare to accommodate changes when moving to AOS 10.

Mobility Controller/Gateway Configuration

Whether upgrading existing AOS 8 Mobility Controllers or deploying new AOS 10 Gateways, it is important to understand that some of the features and functions of the controllers will move to Central or to the APs after migration. Understanding this change is helpful for migration planning and for post-upgrade support of the migrated network.

Access Points

Similar to the migration of services in relation to Controllers or Gateways, understanding the following AP feature changes is useful for “day one” support of the migrated network.

AOS 8 Campus to AOS 10 Bridge Mode

Most AOS 8 Campus Mode customers transition to an AOS 10 Tunnel Mode topology to preserve the same traffic flows. Others benefit from moving to a Bridge Mode design.

When moving from controller-based to Bridge Mode, there is no need to tunnel traffic to a centralized Gateway cluster. Although jumbo frame support is not required for Bridge Mode infrastructure, best practice is to keep it enabled on switches between APs and gateways.

Similar to IAPs, Bridge Mode AP management IP addresses must be Layer 2 adjacent. Wireless user VLANs also must be Layer 2 adjacent to provide a single roaming domain.

Authentication Requirements

In AOS 10 Bridge Mode deployments, the authentication request’s source IP is always the AP to which the client is associated. All RADIUS requests are sourced from the access point. The RADIUS server must have the AP management subnet or individual AP IP addresses configured as RADIUS clients or NADs. The IAP VC is deprecated in AOS 10 to allow scaling capabilities four times the current IAP recommended limit of 128 APs per cluster. Without a VC, Dynamic Radio Proxy (DRP) is no longer an option in AOS 10 Bridge Mode.

AOS 8 Tunnel and AOS 10 Bridge Mode Datapath

Similar to the AOS 8 Campus to AOS 10 Tunnel Mode migration, the management plane is the most notable difference. AOS 10 is a cloud-native operating system managed by Aruba Central.

The diagrams below illustrate key considerations for datapath changes when moving from AOS 8 Campus to AOS 10 Bridge Mode. The AirWave server is removed, which means AMON and SNMP between Mobility Controller and AirWave are no longer used.

Because Bridge Mode deployments do not require a Gateway, client traffic is no longer encapsulated and sent to an AOS 8 Controller. Client traffic is now switched locally at each AOS 10 AP onto a data VLAN. Although there is no longer a need for GRE and PAPI traffic between APs and controllers, PAPI is still used between the APs.

Port 443/TCP for HTTPS is required between APs and Aruba Central. AP to AP broadcast and secure PAPI must be permitted. Use QoS policies to prioritize AP management traffic in dense, Bridge Mode deployments.

Bridge Mode Scaling

• For AP Management, the maximum supported subnet size is currently /20.
• Wireless user VLANs should use a subnet no greater than /20. If a greater number of hosts in the VLAN is required, deploy a gateway cluster and Tunnel Mode SSIDs.
• The current maximum for supported Bridge Mode is 500 APs and 5000 clients.

Note: The scaling values above are the maximum tested and supported at the time of document release. They are not hard limits and are subject to increase.

Mixed Mode

A Mixed Mode SSID enables an AP to tunnel traffic to a Gateway cluster or to bridge it locally. To support this capability, the network must meet the same switching, scaling, and datapath requirements as when configuring Bridge Mode only. Key requirements are:

• Tunnel Mode SSID data VLANs must be configured at the Gateway cluster only.
  • Tunnel Mode SSID data VLANs must be pruned at the AP switchport.
• Bridge Mode SSID data VLANs must be allowed at the AP switchport.
  • The AP switch port must be configured as a trunk.
• Best practice is to configure the AP management VLAN as native (untagged) on AP switch ports.
• When using 802.1X:
  • Tunnel Mode and Mixed Mode SSIDs require registering the gateway(s) as the RADIUS client (NAD).
  • Bridge Mode SSIDs require registering all APs as a RADIUS client (NAD).

---