Planning Aruba Instant AP to AOS 10 Migration
This section highlights key considerations for a network architecture or operations team planning to migrate from Instant AP (IAP) to AOS 10.
It is important to review each layer of the network against the guidelines below to plan the migration steps 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 Instant AP to AOS 10 Migration
- IAP Network Architecture Review
- AOS 10 Tunnel Mode Architecture Review
IAP Network Architecture Review
The Instant AP platform offered enterprise-grade features without requiring a mobility controller. APs within the same subnet form an IAP cluster, configurable through one of the members elected as the conductor. This conductor runs the Virtual Controller (VC) service and could be managed and monitored directly by a web user interface or remotely through Aruba Central or AirWave.
IAP Campus LAN Design
The collapsed core-aggregation topology illustrated below represents a common Aruba IAP campus deployment. It contains Layer 2 and Layer 3 switches connected by redundant links in the underlay to support an IAP cluster deployment. DHCP, DNS, monitoring, and authentication servers are represented by the single “Servers on Prem” icon.
IAP – Physical Topology
IAP Campus Datapath
In an IAP Cluster, Wi-Fi client data is bridged locally at the APs rather than being tunneled to a centralized controller. As traffic from an endpoint reaches an AP over its radio interface, it is inspected, assigned a user role, tagged, and forwarded on the AP’s local interface to a trunked user VLAN. To illustrate these differences, the two-AP example cluster below highlights data traffic from trusted and untrusted clients along with management/control traffic between APs.
IAP – Datapath
Continuing with the example above, trusted Enterprise Network traffic from the corporate laptop reaches the AP over its radio interface. It is then inspected, assigned a user role, tagged with a VLAN ID, and placed on the local LAN (3) to be sent to its destination address. The Guest Network traffic, on the other hand, is handled differently because this WLAN is configured as VC-managed. When configured this way, traffic from the guest phone reaches the AP over the wireless interface; it is forwarded from the member IAP to the one functioning as a VC and NATed before being placed on the local LAN to its destination.
Two management protocols are used between components in the network:
- PAPI
- Process Application Programming Interface used for ARM, config download, and WIDS, is sent between the IAPs.
- HTTP/HTTPS
- Sent from IAPs to AirWave or Central for monitoring and management purposes.
IAP Wired LAN Common Best Practices
Reviewing IAP best practice can help the architect or delivery engineer better understand the existing configuration and deployed services on the IAP network.
Switch ports connected to IAPs are configured as trunk ports (or tagged interfaces) with the AP management VLAN set as native (or untagged). These trunk ports should be configured to allow the VLANs necessary to support the WLANs in the IAP cluster. All IAPs expected to be part of the same cluster must be connected to trunk ports with the same native (or untagged) VLAN ID.
AOS 10 Tunnel Mode Architecture Review
As customers build a plan to migrate from an IAP to an AOS 10 Bridge Mode solution, it is important to understand how deployment, support, and maintenance will change. The tables in this section serve as a convenient reference of key features, requirements, and functional differences between IAPs and AOS 10.
Bridge Mode Management & Monitoring
In an IAP environment, management and monitoring can be performed in three ways: locally through the Virtual Controller’s web UI, centrally with AirWave, or with Aruba Central.
After upgrading to AOS 10, all monitoring and configuration management performed through the VC or AirWave in InstantOS 6.x/8.x will be transferred to Aruba Central. Most communication between AOS 10 managed devices and Aruba Central is made over HTTPS (TCP 443). To enable Central-managed devices to communicate through a network firewall, allow the domain names and ports listed on the “Opening Firewall Ports for Device Communication” section of the Aruba Central Online Help site found here.
Features, Functions, and Service Considerations
The following tables serve as convenient reference for important features, requirements, and functional differences between IAP and AOS 10.
Authentication, Authorization, and Accounting
Depending on ClearPass Service and NAD/RADIUS client (or comparable third-party authentication server) configuration, some updates may be required to ensure that 802.1X WLAN user authentication continues uninterrupted after migration.
In AOS 10 Bridge Mode deployments, the authentication source is always the AP to which the client is associated. All RADIUS requests are sourced from the access point, and the RADIUS server must have the AP management subnet or individual AP IP addresses configured as NADs. Additional information about this is provided in the Authentication Considerations/Features section at the bottom of this page.
| Service/Feature | IAP | AOS10 |
|---|---|---|
| NAS IP / RADIUS Authenticator | RADIUS source IP is individual IAP or Virtual Controller (VC) IP if Dynamic Radius Proxy (DRP) is enabled. | 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 VC 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 to reduce traffic to an external RADIUS server by terminating the authorization protocol on the AP. | Not supported |
Virtual Controller (VC) Configuration
As you upgrade from IAP to AOS 10, it is important to understand that some features and functions of the old IAP Virtual Controller will move to Central or be handled by individual APs. Understanding these changes is helpful for migration planning and for post-upgrade support of the migrated network.
Services such as HA, radio management, and ClientMatch are handled differently, as shown in the table below.
| Service/Feature | IAP | AOS 10 Bridge Mode |
|---|---|---|
| High Availability (HA) | VC and Conductor AP election occurs between APs in a cluster | Central Services improves the resiliency of controller-less APs by moving the VC, Conductor AP, and cluster function to containerized services. |
| Radio Transmit Power, Channel Width, and DFS Channels | Configurable within RF menu of VC | 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 RF menu of VC | Part of Aruba Central WLAN Control and Services. Settings cannot be tuned. |
| Conductor AP / Virtual Controller (VC) | Used for configuration of IAPs in a cluster | All AP configuration is performed in Aruba Central |
| User Roles | Supported | Supported |
| L3 Mobility | Supported at limited scale | The improved roaming domain size eliminates the need for L3 roaming between clusters. |
Access Points
Similar to the change in VC management above, understanding AP feature and service changes is useful for “day one” support of the newly migrated AOS 10 network. The table below details the behavior of AP traffic over the wire, AP discovery, and VLAN considerations.
| Service/Feature | IAP | AOS 10 Bridge Mode |
|---|---|---|
| AP Traffic Over the Wire | Data traffic is bridged at each AP. APs require HTTPS (TCP 443) to Central or AirWave. | Data traffic is bridged at each AP, and APs require HTTPS (TCP 443) to Aruba Central. |
| Dynamic AP Discovery/ADP | Unified AP discovery: 1. DHCP options 43 and 60 2. AP multicast ADP packet to group 239.0.82.11 3. AP broadcasts ADP packet to L2/L3 recipients 4. AP sends DNS query for aruba-master 5. AP begins IAP VC discovery 6. AP begins AirWave discovery 7. AP connects to Aruba Activate 8. Broadcast “SetMeUp:xx:xx:xx” SSID where the “X’s” represent the last 3 octets of the AP MAC address. | 1. Contact Central for configuration on TCP 443 for configuration. If the AP does not exist in the customer’s Aruba Central database and is not licensed, it follows the Unified AP 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. (e.g., if SSID “CorpWiFi” places users on VLAN 10, then VLAN 10 should be pruned at all APs’ uplink switchports to prevent APs from learning the “CorpWiFi” client’s MAC address). This is by design. |
| VLAN 1 | No VLAN or subnet restrictions | No VLAN or subnet restrictions |
| Encrypt and Decrypt 802.11 frames | Occurs at the controller in Tunnel SSID mode. Not commonly used but performed for the AP in Decrypt Tunnel or bridged SSID mode. | Always performed at the AP regardless of Tunnel, Bridge, or Mixed mode SSID |
IAP and AOS 10 Bridge Mode Datapath
For customers who historically have managed their IAP deployments centrally through AirWave or locally through the VC, the most significant change when moving to AOS 10 is the management plane. AOS 10 is a cloud-native operating system managed by Aruba Central.
The following side-by-side comparison shows an example deployment before and after upgrading from an Airwave-managed IAP cluster to AOS 10 Bridge Mode.
Although the underlay configuration remains the same, there are some key datapath differences between the IAP and AOS 10 Bridge Mode examples above.
Connectivity to Aruba Central is required. The function of the on-prem AirWave server is replaced by the Central cloud service in AOS 10; any firewall between the APs and Central must be configured to permit management traffic according to the Aruba Central Help page found here.
Since the VC is not used in AOS 10, a NAT or DHCP function is no longer offered by one of the APs. In the example above, the Guest Network, which was originally configured for VC management on the left, will now receive DHCP from an external server and NAT services from a firewall or router upstream. Any WLAN configured as VC-managed must be configured similarly.
Finally, note that PAPI traffic will continue to pass between APs.
Bridge Mode AP and Client Scaling
AOS 10 removes the limitation of the number of APs and clients in a single roaming domain compared to IAP clusters. Currently, the supported AOS 10 Bridge Mode scaling recommendations are up to 500 APs and 5000 clients. With almost four times the previous recommended maximum for 128 IAPs in a cluster, this resolves several limitations in the IAP architecture:
- Multi-floor IAP deployments with one cluster per floor can be consolidated and no longer require managing multiple individual clusters in one building.
- Campuses with multiple buildings can be consolidated for the same benefits as the multi-floor consolidation above. In addition, when multiple IAP clusters provide contiguous RF coverage, there is no need for L3 mobility.
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 change.
Bridge Mode Infrastructure Considerations
Subnet Sizing - Currently, the tested and supported maximum is /20 for AP management. Similarly, wireless user VLANs should use a subnet no greater than /20. If a greater number of hosts in the VLAN is required, an Aruba gateway cluster and Tunnel Mode WLANs should be deployed.
L3 Mobility - Due to the expanded Layer 2 roaming domain scale, AOS 10 eliminates the Layer 3 Mobility feature set. To provide a singular roaming domain, VLANs must maintain Layer 2 adjacency. If a roaming domain must be maintained across Layer 3 boundaries, an Aruba gateway cluster using Tunnel Mode should be considered.
PAPI - In prior releases of AOS, the PAPI protocol was optionally secure and occurred between the AP and the VC in the case of IAP. AOS 10 changes this behavior by requiring that Secure PAPI (UDP 8211) be allowed between all APs in a particular roaming domain. If there are firewalls or ACLs on the management VLAN, modify the policies appropriately.
NAT & DHCP Server - AOS 10 Bridge Mode APs do not provide NAT or DHCP services. If the current IAP deployment has WLANs configured with the “Virtual Controller Managed” option, the service must be provided upstream by an L3 switch, firewall, router, or Aruba Gateway before deployment.
Authentication Considerations and Features
Cryptographic Keys - In AOS 10, cryptographic key distribution is managed by Central. In previous software, key distribution was handled by the VC or by controllers. Aruba Central now distributes keys to neighboring APs for fast roaming.
Latency - Global deployments must consider round-trip time latency to Central services to ensure responsive performance. Target latency should be below 200 ms.
Authentication Requests - In AOS 10 Bridge Mode, SSIDs configured for 802.1X, authentication requests are always sourced from the AP to which the client is associating. If there is Bridge Mode site with 250 APs, the RADIUS server(s) must be updated to receive authentication requests from all of them. In Aruba ClearPass, these could be entered as individual client IP addresses or as a range.