Link Search Menu Expand Document

  article Gateway Clustering with AOS 10
calendar_month 07-May-24

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

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.

8vs10TunnelModeDatapathNumbered_2

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:

AOS10TunnelVLANFlowChart

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.

Service/FeatureAOS 8 Campus ModeAOS 10
NAD IP / RADIUS AuthenticatorRADIUS 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 ServerAvailable 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 Controllers to act as an authentication server rather than a relay between the client and RADIUS server.Not supported

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.

Service/FeatureAOS 8 Campus ModeAOS 10
High Availability (HA)L2 & L3 Cluster, LMS/Backup LMSThe available modes are Auto Group, Auto Site, and Manual.
Radio Transmit Power, Channel Width, and DFS ChannelsARM Profiles, Dot11a/g Radio Profiles, and Regulatory Domain ProfilesAll radio Tx, channel width, and DFS channel decisions are handled by AirMatch and managed by Aruba Central.
ClientMatch Band Steering, Sticky, and Load BalancingConfigurable within ARM ProfilePart of Aruba Central WLAN Control and Services. Settings cannot be tuned.
Mobility ConductorUsed for configuration of its Member controllers in a Conductor-Member deploymentAll gateway configuration is performed in Aruba Central.
AP OverrideNot SupportedWhile supported in AOS 6, but not in AOS 8, AP Override has been replaced with device-level override that allows similar configuration for managed Gateways and switches.

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.

Service/FeatureAOS 8 Campus ModeAOS 10
AP Traffic Over the WireCommunication 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/ADPAP-Controller discovery order:
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
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 8 discovery method listed in the previous column.
Campus AP Management VLANNo VLAN or subnet restrictionsIf 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 1No VLAN or subnet restrictionsBy 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 framesOccurs at the controller in Tunnel SSID mode.
Not commonly used but also performed for the AP in Decrypt Tunnel or bridged SSID mode.
Always performed at the AP regardless of Tunnel, Bridge, or Mixed Mode SSID.
AP IP AddressingCan be static, or DHCPDHCP is required for APs to dynamically contact Aruba Activate and Central.

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

Back to top

© Copyright 2024 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. Aruba Networks and the Aruba logo are registered trademarks of Aruba Networks, Inc. Third-party trademarks mentioned are the property of their respective owners. To view the end-user software agreement, go to Aruba EULA.