Access Point Deployments

Access Points are the underpinning of the Campus wireless architecture. To provide maximum flexibility, an ArubaOS 10 AP can support WLANs configured to either bridge or tunnel user traffic. A special WLAN is also supported that can offer both forwarding types. One important feature of the AOS 10 architecture is that APs are no longer dependent on Gateways. Customers are free to deploy APs with or without Gateways depending on their traffic forwarding needs, feature requirements, and size of the network.

An AOS 10 AP-only deployment consists only of APs, and no Gateways. The APs are strategically deployed in one or more buildings to establish RF coverage areas. Since no Gateways are used, the APs publish WLANs that are configured to bridge the user traffic directly onto the wired network at the access layer.

An AP-only deployment can be considered for any environment where must provide Wi-Fi access to client devices, but do not require tunneling or other advanced features offered by Gateways. This includes:

• Small offices and branches
• Regional branches or headquarters
• Warehouses
• Campuses

There are some environments where AP-only deployments might not be suitable. For example, large hospitals and medical centers where high scale and seamless roaming are key requirements for specific medical applications and real-time communications.

Roaming Domains

A roaming domain is the population of APs in a common RF coverage area that share VLAN IDs and broadcast domains (IP networks). The coverage area may be contained within a single physical location such as a building / floor or if scaling and the LAN architecture permits may be extended between physical locations such as co-located buildings in a campus environment.

As the WLANs bridge the user traffic directly into the access layer, VLANs must be created and extended between the APs. A typical AP-only deployment utilizes a single AP management VLAN and two or more wireless user VLANs. There is no hard requirement for using a single AP management VLAN, and a customer may implement multiple AP management VLANs, if required. The only requirement is that the AP management VLANs are dedicated for management and not shared with client devices.

The number of wireless user VLANs varies based on deployment size, broadcast domain tolerance, and customer segmentation requirements. These VLANs are extended between the APs within a given RF coverage area. This is needed so that the wireless client devices can seamlessly roam between the APs and maintain their VLAN membership and IP addressing.

The AP management and wireless user VLANs are terminated on a multilayer switch that resides in the core or aggregation layers. This may vary based on the customer environment and LAN architecture. The multilayer switch is the default Gateway for the AP-management and wireless user VLANs, and includes IP helper addresses to facilitate DHCP addressing.

Roaming Domain Scaling

Each roaming domain can scale to support a maximum number of APs and client devices. As the AP management and user VLANs are extended between the APs in a roaming domain, any broadcast/multicast frames forwarded over the AP or wireless user VLANs will be received and processed by all the APs in the roaming domain. Broadcast/multicast frames are normal and are used by both APs and clients for various functions. As a general rule of thumb, the more APs and clients you deploy in a roaming domain, the more broadcast/multicast frames will be transmitted and processed by all connected hosts in each VLAN.

The frequency of broadcast/multicast frames that are flooded over the AP and wireless user VLANs are the main limiting factor for scaling as CPUs on APs can only process so many of these frames before other software services are impacted. Aruba has validated that a single individual roaming domain can support a maximum of:

• 500 x APs

• 5,000 x clients

These are the maximum limits that have been tested and verified by Aruba with APs connected to a single management VLAN and wireless clients connected to a single wireless user VLAN. Broadcast/multicast traffic was also generated to ensure correct operation in heavier broadcast/multicast environments. These limits also apply when multiple AP management and user VLANs are deployed. The aggregate number of APs and clients should not exceed the verified limits across all the VLANs. For example, if a customer configures four user VLANs, we recommend that you do not exceed a total of 5,000 clients across all the user VLANs.

Multiple Roaming Domains

An AP-only deployment can include as many roaming domains of up to 500 APs / 5,000 clients as needed as long as the AP management and wireless user VLANs for each roaming domain are separated at layer 3 (that is, reside on separate IP networks / broadcast domains).

For example, a 10-building campus design can include up to 500 APs per building, with each building supporting a maximum of 5,000 clients. The campus in this example would include 5,000 APs supporting a maximum of 50,000 clients across the campus. The AP management and wireless user VLANs in each building will be assigned unique IP subnets resulting in unique broadcast domains for each building. Larger buildings requiring higher scaling may implement multiple roaming domains as needed.

Consider deploying multiple roaming domains for the following scenarios:

• Scaling—You have a coverage area such as a large building or co-located buildings that must support more than 500 APs and/or 5,000 clients. Additional roaming domains will be incorporated into the design to accommodate the additional APs and/or wireless client devices.

• LAN Architecture—The AP-management and wireless-user VLANs cannot be extended between access layer switches either between floors within a building or between buildings. If the LAN switches cannot be reconfigured to extend the needed VLANs, separate roaming domains will be required.

Overlapping RF Coverage

If the RF coverage areas between buildings or floors do not overlap, there is no expectation of network connectivity as you move between areas. But if the RF coverage areas overlap, you may expect continuous network connectivity as you move between buildings or floors. However, the IP network membership for client devices moving between two roaming domains will not be seamless. The client devices must obtain new IP addressing after the roam.

While the roam itself can be a fast roam, since the wireless-user VLANs in each roaming domain map to different broadcast domains, the client device must re-DHCP to obtain a new host address and default Gateway before it can continue to communicate over the intermediate IP network. The user VLAN ID can be consistent between roaming domains for simplified operations and management, but for scaling, the IP networks assigned to each roaming domain must be unique.

Deployments requiring multiple roaming domains with overlapping RF coverage therefore require careful planning and consideration:

• User Experience—Do you expect uninterrupted network connectivity when moving between roaming domains? For example, between buildings or floors?

• RF Design—Can the design accommodate or implement RF boundaries to minimize the hard roaming points between adjacent roaming domains to provide the best user experience?

• Client Devices—Do you have any specialized or custom client devices deployed? Test to validate that they can tolerate and support hard roaming. Modern Apple, Android, and Microsoft operating systems will issue a DHCP discover and re-ARP after each roam.

• Applications—What applications do you have deployed and can they tolerate hosts changing IP addresses? While some applications such as Teams and Zoom can automatically recover after host readdressing, others cannot.

A decision would need to be made on whether users, client devices, and applications can tolerate hard roaming in the environment before considering co-located roaming domains. If not, then Gateways and tunneling can be considered.

Types of Roaming

A client device can experience two types of roams in an AOS 10 deployment—hard roams and seamless roams. This section provides additional details for each roaming type and clarification on when we provide seamless and hard roaming in non-tunneled environments (i.e. AP only networks).

Hard Roaming

In a multiple roaming domain environment, client devices obtain new IP addressing and a default Gateway when transitioning between APs in separate roaming domains. Client devices may retain the same VLAN ID assignment depending on the LAN environment. While the user VLAN IDs may be common or unique between roaming domains, IP subnets or broadcast domains are always unique.

When a client device transitions between roaming domains, the following actions take place before the client device can continue to communicate over the intermediate IP network:

• The client device issues a DHCP discover to obtain new addressing. A full DHCP exchange occurs and new host addressing and options are assigned. As the DHCP discover is a broadcast frame, it also populates the MAC address tables on all the layer-2 switches where the new user VLAN extends.

• The client device sends an ARP for the default Gateway. This permits the client device to communicate with hosts on other IP networks.

• All running applications on the client device re-establish their sessions. This may occur automatically or require user intervention.

Seamless Roaming

In a single roaming domain, client devices experience a seamless roam since all the APs in the RF coverage share user VLANs and broadcast domains. Client devices can maintain their user VLAN ID, IP addressing, and default Gateway after each roam. The roaming time will vary based on the WLAN type, its configuration, and the fast-roaming capabilities of the client.

After a successful roam, the client device’s MAC address or port-bindings are updated on all the layer-2 switches where the user VLAN extends. There are two ways in which this happens:

• The client device sends a broadcast frame such as an ARP or DHCP-discover, which is flooded over the user VLAN.

• The new AP sends a Gratuitous ARP, if proxy ARP is enabled, which is flooded over the user VLAN.

FAQ

Do ArubaOS 10 APs support layer-3 mobility?

No. We do not have plans to support this. Gateways provide a scalable and resilient option if layer-3 mobility is required.

Does Aruba Central have limits on how many instances of 500 APs or 5,000 clients can be deployed? Are there any Aruba Central group or site limits?

There are no Aruba Central group or site restrictions.

Do the AP-management and wireless-user VLANs must be dedicated or can they be shared with other hosts?

Our best practice recommendation is to use dedicated VLANs for AP management and wireless users, especially in larger environments where large amount of broadcast or multicast traffic is expected.

Is there anything I can do additionally to prevent unwanted broadcast or multicast frames from impacting the APs?

In addition to implementing dedicated management and user VLANs, it is strongly recommended that you remove any unwanted VLANs on the AP switchports, on the access layer switches. These switchports should be explicitly configured to untag the AP-management VLAN and only tag the user VLANs. No other VLANs should be extended to the APs. This will ensure that any broadcast or multicast frames from other VLANs are not received by the APs.

Can APs in a roaming domain be connected to different management VLANs?

The APs may be distributed between multiple VLANs as long as you do not exceed 500 APs in the roaming domain. However, since DTLS tunnels are established between APs for session state synchronization and clean-up, the APs must be able to reach each other over same IP.

Can I deploy a single wireless-user VLAN supporting up to 5,000 clients in a roaming domain?

A single user VLAN is supported, however most real-world deployments will include two or more user VLANs that naturally establish smaller broadcast domains.

Can I exceed 500 APs or 5,000 clients if I deploy additional VLANs?

No. These recommended limits apply per roaming domain regardless of the number of AP management and user VLANs.

When do I need to consider Gateways for my customers’ deployment?

Please refer to the Gateway Use Cases section.

Can APs with foundation and advanced licenses be mixed in a roaming domain? What will happen if they are mixed?

While you may mix APs with different licenses, it is not recommended. Certain features such as Live Upgrade, HPE Aruba Networking AirGroup (custom services), Air Slice, UCC, and Multizone require an advanced license. Mixing APs with different license tiers in a building or floor will result in feature discrepancies and an operationally challenging environment.

What happens if the total number of APs or clients in a roaming domain exceeds 500 APs or 5,000 clients?

These are soft limits which are not enforced and have been provided as a recommended best practice. If either limit is exceeded, AP and client performance may degrade, especially in high traffic environments.

Can I deploy APs and tunneled WLANs across a WAN?

Not all WANs are created equally.

1. Public Internet including VPNs: Not supported

2. Private WANs (MPLS, TDM etc.): These types of deployments are not tested and are therefore, not supported without additional validation. Please contact your HPE Aruba Networking sales team to discuss these requirements further.

3. Metropolitan Ethernet Services or Ethernet extensions between sites: These are supported since they would not be much different from dark fiber implementations. However, we do require the service to support standard 1,518 byte or larger Ethernet frames. Gigabit Ethernet speeds or higher are also recommended.

Are APs and bridged WLANs supported with EVPN-VXLAN?

APs using bridge forwarding are now supported on the NetConductor solution, with the limitation of no role-to-role group-based policies. Support for 3rd party EVPN-VXLAN environments will vary depending on the vendor’s ability to support rapid MAC address moves. Please reference the validated solutions guide (VSG) for more information.