This section highlights key considerations for a network architecture or operations team planning to migrate from AOS 6 to AOS 10.
It is important to review each layer of the network against the guidelines presented below in order to plan the steps of the migration accurately.
The information provided here is not intended as 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 6 to AOS 10 Migration
- AOS 6 Campus Network Architecture Review
- AOS 10 Tunnel Mode Architecture Review
- AOS 6 Campus to AOS 10 Bridge Mode
- Mixed Mode
The Aruba OS 6 platform offered customers a wide range of topology and configuration options. Deployments could be as simple as installing a standalone Conductor controller, APs, and data traffic on the same VLAN and subnet. Or, they could encompass fully redundant Conductor-Member topologies with NAT and DHCP services running on the controllers or elsewhere in the network.
The collapsed core topology illustrated below represents a common AOS 6 campus deployment. It contains Layer 2 and Layer 3 switches connected by redundant links as the underlay to support a Conductor-Member deployment. External DHCP, DNS, monitoring, and authentication servers are represented by the single “Servers on Prem” icon.
In an AOS 6 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. This overlay capability also can be used to achieve IP mobility (L3 Roaming) and to transport guest traffic between a local Mobility Controller and a guest anchor Mobility Controller in a DMZ.
Two management protocols are used between the components of the network:
- Process Application Programming Interface is used for ARM, WIDS, and config download via UDP port 8211 between AP and controllers.
- 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.
Reviewing AOS 6 best practice can help the architect or delivery engineer better understand existing configuration and deployed services on the AOS 6 network.
Jumbo frame support should be enabled on the wired LAN to support fully encapsulated wireless traffic. This is also best practice for AOS 10. 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 for rogue AP detection and wired port detection.
As customers build a plan to migrate from AOS 6 Campus Mode to an AOS 10 Tunnel Mode, it is important to understand the differences to determine the changes required, if any, to the supporting architecture before migration.
For many customers, the most noticeable change moving from AOS 6 to 10 is the management plane. AOS 6 deployments typically required permitting SNMP and AMON to/from an AirWave server for configuration management and monitoring, whereas most AOS 10 deployments only require traffic on TCP port 443 between Aruba Central and the management interface of each managed device.
AOS 6 campuses configured to deny Internet access from devices residing in the management LAN require an update in security policy to permit connections with Central. If campus APs currently cannot reach the Internet, access to reach Central is required before migrating to AOS 10.
Refer to the Opening Firewall Ports for Device Communication section of the Aruba Central User Guide for complete details.
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.
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 that it is distinct from the VLAN used for AP management.
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 6 deployments have the data VLAN of a tunneled SSID extended to AP switch ports. Prune these VLANs from the AP switch ports as part of the AOS 10 preparations for Tunnel Mode SSIDs.
The decision chart below shows one method of addressing the VLAN requirement described above:
The following tables serve as reference for important features, requirements, and functional differences between AOS 6 and AOS 10.
To ensure 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.
|Service/Feature||AOS 6 Campus Mode||AOS 10|
|NAD IP / RADIUS Authenticator||RADIUS requests in ClearPass Access Tracker show Mobility Controller as the source IP.||Mixed mode: Source IP is the gateway’s management address.|
Bridge Mode: Source IP is the individual AP’s management address.
|Internal Authentication Server||Available on Mobility Controller as an internal database that can be used for small-scale or test deployments.||Local user authentication service is not supported.|
|AAA FastConnect (EAP-Offload)||Can be enabled for Mobility Controller to act as an authentication server rather than a relay between the client and RADIUS server.||Not supported|
Whether upgrading existing AOS 6 Mobility Controllers or deploying new AOS 10 Gateways, it si important to understand that some of the features and functions of the controllers will move to Central or the APs after migration. Understanding this change is helpful both for migration planning and for post-upgrade support of the migrated network.
|Service/Feature||AOS 6 Campus Mode||AOS 10|
|High Availability (HA)||LMS/Backup LMS, Active-Active, and AP Fast Failover||The available modes are Auto Group, Auto Site, and Manual.|
|Radio Transmit Power, Channel Width, and DFS Channels||ARM Profiles, Dot11a/g Radio Profiles, and Regulatory Domain Profiles||All radio Tx, channel width, and DFS channel decisions are handled by AirMatch and managed by Aruba Central.|
|ClientMatch Band Steering, Sticky, and Load Balancing||Configurable within ARM Profile||Part of Aruba Central WLAN Control and Services. Settings cannot be tuned.|
|Conductor Controller||Used for configuration of its Member controllers in a Conductor-Member deployment||All gateway configuration is performed in Aruba Central.|
|AP Override||Supported||AP Override has been replaced with device-level override that allows similar configuration for managed Gateways and switches.|
Similar to the migration of services for Controllers or Gateways, understanding the following AP feature is useful for “day one” support of the migrated network.
|Service/Feature||AOS 6 Campus Mode||AOS 10|
|AP Traffic Over the Wire||Communication between AP and Controller only. See the “Firewall Port Configuration” section above for specific ports.||Tunnel Mode APs require HTTPS (TCP 443) to Aruba Central as well as east/west traffic between APs.|
|Dynamic AP Discovery/ADP||AP-Controller discovery order:|
1. DHCP option 43 and 60
2. AP multicast ADP packet to group 126.96.36.199
3. AP broadcasts ADP packet to L2/L3 recipients
4. AP sends DNS query for Aruba-master
|1. Contact Central for configuration on TCP 443 for configuration|
If the AP does not exist in the customer’s Aruba Central database, is not yet running AOS 10, and is not licensed, it will follow the AOS 6 discovery method listed in the previous column.
|Campus AP Management VLAN||No VLAN or subnet restrictions||If a VLAN is assigned to Wi-Fi clients by a Tunnel Mode infrastructure, it cannot exist on the trunk uplink of Tunnel Mode AP. (For example: If SSID “CorpWiFi” places users on VLAN 10, then VLAN 10 should not be allowed as native or tagged on switch ports connected to APs to prevent APs from learning “CorpWiFi” client’s MAC address). This is by design.|
|VLAN 1||No VLAN or subnet restrictions||By default, VLAN 1 should not be used for Tunneled SSID clients.|
The AP uplink VLAN is VLAN 1 by default. Currently, this cannot be updated.
|Encrypt and Decrypt 802.11 frames||Occurs at the controller in Tunnel SSID mode. |
Not commonly used but also performed at the AP in Decrypt Tunnel or bridged SSID mode.
|Always performed at the AP regardless of Tunnel, Bridge, or Mixed Mode SSID.|
|AP IP Addressing||Can be static, or DHCP||DHCP is required for APs to dynamically contact Aruba Activate and Central.|
Most AOS 6 customers transition to an AOS 10 Gateway Cluster topology to preserve the same traffic flows. Others may 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. And, 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.
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 because 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.
One of the most significant changes when moving from AOS 6 to AOS 10 is the management plane. AOS 10 is a cloud-native operating system managed by Aruba Central. Aruba AirWave is not used with an AOS 10 deployment.
The diagrams below illustrate key considerations for datapath changes when moving from AOS 6 Campus to AOS 10 Bridge Mode. The AirWave server is removed, so 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 6 Controller, In AOS 10, client traffic is switched locally at each AP onto a data VLAN. Although GRE and PAPI traffic between APs and controllers is no longer needed, 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.
- For AP Management, the maximum supported subnet size is currently /20.
- Wireless user VLANs should use a subnet no greater than /20. If a requirement exists for a greater number of hosts in the VLAN, deploy a gateway cluster and Tunnel Mode SSIDs.
- The current maximum for Bridge Mode support is 500 APs and 5000 clients.
Note: The scaling values above are the maximum tested and supported at the time of document publication. They are not hard limits and are subject to increase.
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. Some key requirements are listed below:
- 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 configuring 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).