Forwarding Modes of Operation

In AOS 10, client traffic can be bridged locally by the APs or be tunneled to a Gateway cluster. How the client traffic is forwarded by the APs is determined by the traffic forwarding mode configured in each WLAN and downlink wired port profile:

• Bridge – APs will bridge client traffic out its uplink interface on the desired VLAN.

• Tunnel – APs will tunnel client traffic to a Gateway cluster on the desired VLAN.

• Mixed – The AP will bridge, or tunnel client traffic based on VLAN assignment.

The traffic forwarding mode configured in each profile determines if the APs or the Gateways are the authenticators and where the VLAN and user-role assignment decisions are made:

• Bridge Forwarding – APs are the authenticators and determine the static or dynamic VLAN and user role assignment for each client.

• Tunnel or Mixed Forwarding – Gateways are the authenticators and determine the static or dynamic VLAN and user role assignments for each client.

For mixed forwarding, the assigned VLAN ID determines if the client’s traffic is bridged locally by the AP or tunneled to a Gateway cluster. Client traffic is bridged if the assigned VLAN is not present within the assigned Gateway cluster and is tunneled if the VLAN is present within the assigned Gateway cluster.

The traffic forwarding modes are extremely flexible permitting wireless client traffic to be bridged or tunneled as needed. Selecting the Bridge or Tunnel forwarding mode will exclusively configure the forwarding mode of the WLAN profile to the specified forwarding mode. Mixed forwarding permits both forwarding types but requires dedicated VLANs to be implemented for bridged and tunneled clients. A profile configured for bridge forwarding cannot tunnel user traffic and vice versa.

Bridge Forwarding

When bridge traffic forwarding is configured in a WLAN or downlink wired port profile, the client traffic will be directly forwarded out of the APs uplink port(s) onto the access switching layer with an appropriate 802.1Q VLAN tag. To support bridge forwarding, the APs management and bridged user VLANs are extended from the access switching layer to the APs uplink ports. Each bridged client is assigned a VLAN that is 802.1Q tagged out the APs uplink port. As a recommended security best practice, no bridged clients should be assigned to the APs management VLAN.

An example of a bridge forwarding deployment is depicted below where the AP management VLAN (not shown) and bridged user VLANs 76 and 79 are extended from the access switching layer to hospitality AP which services wired and wireless clients. In this example the WLAN client is assigned VLAN 76 while the wired client is assigned VLAN 79. The core / aggregation switch has IP interfaces and IP helper addresses defined for each VLAN and is the default gateway for each VLAN.

Seamless Roaming

To provide the best possible experience for bridged clients and their applications, the AP management and user VLANs are extended between APs that establish common RF coverage areas within a building or floor. The AP management and bridged user VLANs are shared between the APs and are allocated a specific IP network based on the number of hosts each VLAN needs to support.

Clients roaming between APs sharing VLANs are able to maintain their VLAN assignment, IP addressing and default gateway after a roam. This often is referred to as a seamless roam as it is the least disruptive to applications. The roam can be a fast roam or slow roam depending on the WLAN profile configuration and capabilities of the client.

A seamless roam is depicted in below where bridged user VLAN 76 and its associated IP network (10.200.76.0/24) has been extended between all the APs within a building. In this example the client is able to maintain its VLAN 76 membership, IP addressing and default gateway after each roam.

Bridge Forwarding Scaling

The total number APs and bridged clients that can be supported across shared management and user VLANs will also influence your VLAN and IP network design. Broadcast / multicast frames and packets are normal in IP networks and are used by both APs and clients to function. The higher the number of active hosts that are connected to a given VLAN, the higher the quantity and frequency of broadcast / multicast frames and packets that are flooded over the VLAN. As broadcast / multicast frames are flooded, they must be received and processed by all active hosts in the VLAN.

When bridge forwarding is deployed, HPE Aruba Networking has validated that we can support a maximum of 500 APs and 5,000 bridged clients across all shared management and user VLANs. The total number of APs in a shared management VLAN cannot exceed 500 and the total number of clients across all bridged user VLANs cannot exceed 5,000.

When scaling beyond 500 APs and 5,000 clients is required for a deployment within a building or campus, two design options are available:

1. A cluster of Gateways can be deployed with centralized user VLANs offering higher scaling and seamless mobility.

2. Multiple instances of 500 APs and 5,000 clients can be strategically deployed where the AP management and user VLANs for each instance are layer 3 separated (i.e., implement separate broadcast domains).

If Gateways are not an option, with careful planning and design multiple instances of APs can be deployed where the AP management and user VLANs for each instance of APs connect to separate IP networks providing scaling. Each instance of APs and clients being limited to a floor, building or co-located buildings as needed. There is no limit as to how many instances of 500 APs and 5,000 clients you can deploy as long as each instance of APs and clients are layer 3 separated from other instances. The VLAN IDs used by each instance of APs and clients can be common to simplify configuration and operations, but the IP networks for each instance must be unique.

The compromise for this design is that roaming between separate instances of APs such as between buildings requires a hard roam as bridged clients will require new IP addressing and a default gateway to be assigned (see Hard Roaming). As such a good understanding of your user expectations, application and client behavior needs to be understood before considering a hard roaming design. If hard roaming is not acceptable, a cluster of Gateways must be deployed.

A good understanding of the LAN architecture is also helpful when scaling as larger LANs will typically include natural layer 3 boundaries such as aggregation switching layers within buildings that prevent AP management and user VLANs from being extended. These layer 3 boundaries provide natural segmentation boundaries between each instance of APs and clients.

An example of a campus design implementing bridge forwarding is depicted below. In this example each building implements a dedicated layer 3 aggregation switching layer that connects to a routed core. Each building is completely layer 3 separated from neighboring buildings preventing AP management and user VLANs from being extended. Each building in this example implements a specific number of APs that use the same VLAN IDs but with unique IP networks. Each building can potentially scale to support a maximum of 500 APs or 5,000 clients (whichever limit is reached first).

Hard Roaming

When scaling without Gateways is required or the LAN architecture precludes VLANs and IP networks from being extended between APs across buildings or floors, a bridged forwarding implementation is still possible but with compromises to application and user experience.

There are some situations where it is not possible to extend VLANs and their IP networks between APs in larger deployments such as within a building or between buildings. The local area network (LAN) design may include intentional layer 3 boundaries within the distribution switching layer that prevent VLANs and their associated IP networks from being extended between access layer switches servicing buildings or floors. Access layer switches configured for routed access will also prevent VLANs and IP networks from being extended between wiring closets within a building or floor.

When a client device roams between APs separated by a layer 3 device, a hard roam is performed as the client’s broadcast domain membership changes. While the APs in each building or floor may implement the same management and user VLAN IDs, the associated IP networks will be unique for each. Clients roaming between APs separated across a layer 3 device will require new IP addressing and a default gateway to be assigned after the roam. While modern clients are able to obtain new IP addressing to accommodate the IP network change, the transition between IP networks will impact active applications as the source IP addresses of the clients will change after a hard roam.

A hard roam between APs deployed in separate buildings within a campus separated by layer 3 aggregation switching layers is depicted below. In this example, a common bridged user VLAN ID 76 is deployed in both buildings but has a different IP network assigned in each building:

• VLAN 76 / Building A – 10.200.76.0/24

• VLAN 76 / Building B – 10.201.76.0/24

Bridged clients roaming between APs within each building will have a seamless roaming experience while bridged clients roaming between buildings have a hard roaming experience. The roam can be a fast roam or a slow roam depending on the configuration of the WLAN profile and client capabilities.

Depending on your LAN architecture and environment, a hard roam may be required for clients moving between buildings within a campus, between floors within a multi-story building or between co-located buildings. This will be dependent on where the layer 3 boundaries reside within the LAN for each environment. For most deployments these boundaries will reside between buildings.

Before considering a hard roaming design, the following needs to be investigated and considered:

• User Experience – Do the users expect uninterrupted network connectivity when moving between buildings or floors?

• RF Design* – Can the AP placement and cell design accommodate / implement RF boundaries to minimize the hard roaming points across layer 3 boundaries to provide the best possible user and application experience?

• Client Devices – Do you have any specialized or custom client devices deployed? These will need to be tested to validated to ensure they can tolerate and support hard roaming. Modern Apple, Android and Microsoft operating systems will initiate the DHCP DORA process after each roam.

• Applications – What applications are you using, and can they tolerate hosts changing IP addresses? While some applications such as Outlook, Teams and Zoom can automatically recover after host re-addressing others cannot.

Ultimately you will need to decide if your users, client devices, and applications can tolerate hard roaming before considering and implementing a hard roaming design. If a hard roaming design cannot be tolerated and seamless roaming is required, a design using Gateways and tunnel forwarding should be considered.

MAC Address Learning

When bridge forwarding is enabled, client traffic is forwarded out the APs uplink ports on the assigned VLAN to the access switching layer. Each bridged client MAC address will be learned by all the layer 2 devices participating in the VLAN using normal layer 2 learning. Each bridged client’s MAC address is initially learned from DHCP and ARP broadcast messages transmitted by each client during association, authentication and roaming. Each switch participating in the VLAN will either learn a bridged client’s MAC address from a switchport that is connected to the AP where the client is attached or from its uplink / downlink port connecting to a peer switch.

An example of MAC learning for a bridge forwarding deployment is depicted below. All the layer 2 switches participating in VLAN 76 in this example will learn client 1’s MAC address upon client 1 transmitting a broadcast frame or packet after a successful association and authentication:

• SW-2 – Will directly learn Client 1’s MAC address on port 1/1/1 that connects to the AP (where Client 1 is attached).

• SW-1 – Will learn client 1’s MAC address on port 1/1/20 that connects to SW-2 (layer 2 path to Client 1).

• SW-3 – Will learn Client 1’s MAC address on port 1/1/52 that connects to SW-1 (layer 2 path to Client 1).

When a bridged client roams between APs, a MAC move will occur. Upon a successful roam, a frame or packet from the roaming client will trigger the upstream switches to update their layer 2 forwarding tables to reflect the new layer 2 path to the roamed client.

A MAC address move resulting from a roaming bridged client is depicted below. In this example client 1 has roamed from an AP connected to SW-2 to an AP connected to SW-3. Upon client 1 transmitting a broadcast frame or packet after the roam, all the switches participating in VLAN 75 will update their MAC address forwarding tables to reflect the new layer 2 path to client 1:

• SW-3 – Will re-learn client 1’s MAC address on port 1/1/2 that connects to the AP (where client 1 is attached).

• SW-1 – Will re-learn client 1’s MAC address on port 1/1/2 that connects to SW-3 (new layer 2 path to client 1)

• SW-2 – Will re-learn client 1’s MAC address on port 1/1/52 (new layer 2 path to client 1).

Tunnel Forwarding

When tunnel traffic forwarding is configured in a WLAN or downlink wired port profile, the client traffic is encapsulated in GRE by the APs and is tunneled to the primary Gateway cluster. Client traffic forwarded within the GRE tunnels are tagged with the clients assigned VLAN. As covered in the clustering section, the role of each Gateway within the primary cluster determines which Gateway is responsible for transmitting and receiving traffic for each tunneled client.

With tunnel traffic forwarding, the user VLANs are centralized and reside within each cluster. Each tunneled profile terminates within a primary cluster and can optionally failover to a secondary cluster. For each primary cluster, the Gateways management and user VLANs are extended from each Gateway in the cluster to their respective core / aggregation switching layer. As a best practice, all the VLANs are 802.1Q tagged. Each Gateway within a cluster shares the same management VLAN, user VLANs and associated IP networks. Each tunneled client is either statically or dynamically assigned to a centralized user VLAN within its primary cluster.

An example of a bridge forwarding deployment is depicted below where the tunneled user VLANs 73 and 75 are extended from the Gateway to the core / aggregation switching layer. In this example the WLAN client is assigned VLAN 73 while the wired client is assigned VLAN 75. The core / aggregation switch has IP interfaces and IP helper addresses defined for each VLAN and is the default gateway for each VLAN.

The above example uses a single Gateway to simplify the datapath of each tunneled client. When multiple Gateways are deployed within a cluster, each AP establishes IPsec and GRE tunnels to each cluster node. The role of each Gateway within the cluster determines which Gateway is responsible for anchoring each client’s traffic and which Gateway is responsible for forwarding broadcast / multicast traffic destined to clients attached to each AP. The Gateway role effectively determines which GRE tunnel the AP selects when forwarding traffic from a client and which tunnel is selected by the Gateway for unicast, broadcast and multicast return traffic.

The figure below expands on the previous example by adding an additional Gateway to the cluster and includes each Gateways role assignment. In the below diagram:

• Client 1 is dynamically assigned VLAN 73, and GW-A is assigned the UDG role.

• Client 2 is dynamically assigned VLAN 73, and GW-B is assigned the UDG role.

• GW-A is assigned the DDG role for the AP.

In the above example GW-A is assigned the UDG role for client 1 and is responsible for receiving all traffic transmitted by client 1 and transmitting all unicast traffic destined to client 1. GW-B is assigned the UDG role for client 2 and is responsible for receiving all traffic transmitted by client 2 and transmitting all unicast traffic destined to client 2. This traffic is encapsulated and forwarded in the respective GRE tunnels that terminate on GW-A or GW-B based on the UDG role assignment for each client.

GW-A is also assigned the DDG role for the AP and is responsible for transmitting all broadcast and multicast traffic that is flooded on VLAN 73. This traffic is encapsulated and forwarded in the IPsec tunnel that terminates on GW-A.

Roaming

Each tunneled WLAN terminates in a primary cluster where the user VLANs are centralized. Each tunneled client is either statically or dynamically assigned a VLAN which is present on all the Gateways within the primary cluster. For each client, one Gateway in the cluster is assigned a UDG role that determines which Gateway the client’s traffic is anchored to. As the bucketmap is published per cluster, each client will maintain its UDG assignment as it roams. Each client’s traffic is always be anchored to the same Gateway within a cluster regardless of which AP the client roams to.

When a client roams between APs that tunnel to the same primary cluster, the client is able to maintain its VLAN assignment, IP addressing and default gateway after each roam providing a seamless roaming experience. Clients can perform a slow roam or fast roam depending on the WLAN profile configuration and capabilities of the client. Seamless roaming can be achieved between APs in the same Central configuration group (same profile) or between APs in separate configuration groups (duplicated WLAN profiles). The only requirement for a seamless roam is that the primary cluster must be the same between the APs.

A seamless roam is depicted below where user VLAN 73 and its associated IP network (10.200.73.0/24) is centralized within a primary cluster consisting of four Gateways. In this example APs in each building and floor connect to AP management VLANs implementing separate IP networks. Using the published bucketmap for the cluster, GW-B is assigned the UDG role for the client which is maintained after each roam. Regardless of which AP the client is connected to, the client is able to maintain its VLAN membership, IP address and default gateway.

For some larger campus deployments, tunneled WLANs might be distributed between primary clusters located in separate datacenters to distribute traffic workloads. The IP networks for each user VLAN being unique in each cluster. Using configuration groups in Central, APs in each building are strategically distributed between the primary clusters to evenly distribute the user traffic between each datacenter. For availability and failover, the alternate cluster is assigned as the secondary cluster.

As with bridged forwarding, clients roaming between APs serviced by a separate cluster will perform a hard roam as new IP addressing will be required. While the VLANs will be common, the IP networks for each user VLAN in each datacenter will be unique. Clients roaming between APs tunneling to separate primary clusters will require a new IP address and default gateway after each roam.

MAC Address Learning

When tunnel forwarding is enabled, the APs tunnel the client’s traffic to the Gateway in the cluster that is assigned the UDG role. Each tunneled clients MAC address will be learned by the core / aggregation switch along with all the active Gateways within the cluster:

• Core / Aggregation Switch – Will learn each client’s MAC address from the physical or logical aggregated port that connects to the UDG Gateway for each client.

• Gateways – Will learn each client’s MAC address either from the GRE tunnel (UDG role) or physical or logical aggregated uplink port from the core / aggregation switch.

Each tunneled client’s MAC address is anchored to the Gateway assuming the UDG role for each client. The layer 2 path for each tunneled client will remain bound to the physical or logical port of its assigned UDG Gateway regardless of which AP the client roams. No MAC address move will occur between the Gateways and the core / aggregation switching layer after a roam. A client’s MAC address will only move between Gateways as a result of a UDG -> S-UDG transition.

An example of MAC learning for a tunnel forwarding deployment is depicted below. In this example, client 1 is dynamically assigned VLAN 73 and GW-A is assigned the UDG role. During normal operation, SW-GW-AGG learns client 1’s MAC address on port 1/1/1 that connects to GW-A. GW-B learns the client 1’s MAC address on port 0/0/0 that connects to SW-GW-AGG.

Mixed Forwarding

When mixed traffic forwarding is configured in a WLAN or downlink wired port profile, the client traffic will either be directly forwarded out of the APs uplink port(s) onto the access switching layer with an appropriate 802.1Q VLAN tag or encapsulated in GRE by the APs and is tunneled to the primary Gateway cluster:

• Bridged – The AP will bridge the traffic when a client device is assigned a VLAN ID or Name that is not present in the primary or secondary Gateway cluster.

• Tunneled – The AP will tunnel the traffic when a client device is assigned a VLAN ID or Name that is configured in the primary or secondary Gateway cluster.

When a profile configured for mixed forwarding is created and a primary cluster is selected, the VLANs present in the primary and secondary cluster are learned by the APs and are tagged in the GRE tunnels. The APs use this knowledge to determine when to bridge or tunnel clients when a VLAN is assigned.

For branch deployments using Branch Gateways, the AP management and bridged user VLANs are typically extended from the Branch Gateways to the APs and are common to both. The Branch Gateways provide DHCP services and routing for each VLAN within the branch. When no layer 3 separation exists between the APs and the Gateways in a branch deployment, profiles implementing mixed traffic forwarding will always tunnel the clients. If bridge traffic forwarding is required and layer 3 separation between the APs and the Branch Gateways is not possible, separate profiles implementing bridge traffic forwarding must be implemented.

To support mixed forwarding, the APs management and bridged user VLANs are extended from the access switching layer to the APs uplink port(s). It is recommended that dedicated VLAN IDs be used for bridged and tunneled clients and the VLANs must not overlap. As a recommended best practice, only the AP management and bridged user VLANs should be extended to your APs.

An example of a typical mixed WLAN deployment is depicted below where dedicated VLANs are implemented for bridged and tunneled clients. In this example the untagged AP management VLAN (not shown) and 802.1Q tagged bridged user VLAN 76 is extended from the access switching layer to an AP. VLAN 73 is centralized within a cluster and is 802.1Q tagged from the Gateway to the core / aggregation switching layer. Client 1 is dynamically assigned VLAN 73 and is tunneled to the primary cluster while client 2 is dynamically assigned VLAN 76 and is locally bridged by the APs.

Best Practices & Considerations

AOS 10 APs can support any combination of WLAN and downlink wired port profiles implementing bridge, tunnel, or mixed forwarding modes. When profiles of different forwarding types are serviced by APs, the following considerations and best practices should be followed:

1. Implement dedicated VLAN IDs for bridged and tunneled clients. An AP can only bridge or tunnel clients for a given VLAN ID and cannot do both simultaneously.

2. Prune all tunneled VLANs from the APs uplink ports at the access switching layer. A tunneled VLAN must not be extended to the uplink ports on the APs. As a recommended best practice, only the AP management and bridged user VLANs should be extended to the APs.

3. Avoid using VLAN 1 whenever possible. VLAN 1 is the default management VLAN for APs and is also present on the Gateways. Assigning clients to VLAN 1 may have unintentional consequences such as bridging clients onto the APs native VLAN or blackholing tunneled clients.

4. If profiles using bridge traffic forwarding are implemented, it is recommended that you change the APs default management VLAN ID to match the native VLAN ID configured on your access layer switches.

5. If the APs default management VLAN 1 is retained, avoid assigning tunneled clients to a VLAN in the primary cluster that indirectly maps to the APs untagged management VLAN. For example, if your APs are managed on untagged VLAN 70 which is terminated on a Branch Gateway, you must not assign tunneled clients to VLAN 70.

6. If implementing mixed forwarding with Branch Gateways, bridged user VLANs must be layer 3 separated from the Gateways. If no layer 3 separation is implemented, all the clients will be tunneled as all the VLANs will be present within the primary cluster. If layer 3 separation cannot be implemented, a dedicated profile using bridged forwarding must be implemented.