User VLANs

Each client is either statically or dynamically assigned a VLAN upon connecting to a WLAN or downlink port on an AP. The VLAN assignment decision is either made by the AP or the Gateway depending on the traffic forwarding mode configured in the profile:

• Bridge Forwarding – The VLAN assignment decision is made by the APs

• Mixed or Tunnel Forwarding – The VLAN assignment decision is made by the Gateways

For mixed forwarding, the static or dynamically assigned VLAN Id determines if the client’s traffic is locally bridged by the AP or tunneled to the primary cluster. If the assigned VLAN is present within the cluster, the client’s traffic is tunneled. If the assigned VLAN is not present within the cluster, the client’s traffic is locally bridged by the AP.

When planning an AOS 10 deployment that implements a combination of bridged, tunneled, and mixed forwarding profiles, it’s extremely important to dedicate VLAN IDs for bridged and tunneled clients. The VLAN IDs must be unique for each forwarding mode and must not overlap. An AP can only bridge or tunnel client traffic to each VLAN ID and cannot do so simultaneously. Mixing bridged and tunneled client traffic on the same VLAN ID is not recommended or supported.

Static VLANs

Each profile requires a static VLAN to be configured which is assigned to client devices if no dynamic VLAN assignment is derived. The VLAN you assign can be considered a catchall VLAN if no other VLAN is derived. For WLAN profiles the static VLAN can be individual VLAN ID or VLAN Name that you specify or select depending on the configured forwarding mode. If named VLANs are implemented, additional configuration is required to map the VLAN names to their respective VLAN IDs. The mapping configuration is either performed within the WLAN profile (bridge forwarding) or Gateway configuration group (tunnel forwarding).

As a recommended best practice, the static VLANs you assigned within a profile should not be the management VLAN of the AP or the Gateway. The assigned VLAN should be dedicated to bridged or tunneled clients. VLAN 1 should also be avoided for bridged and mixed forwarding as VLAN 1 is used as the APs default management VLAN and is also present within each primary cluster. VLAN 1 should only be used if the APs management VLAN has been changed to a different value or is legitimately used to serve client traffic within the primary cluster.

An example of VLAN Id and VLAN name assignments for a WLAN profile is depicted in the below figure. In this example WLAN clients with no dynamic VLAN assignment will be assigned to VLAN 75.

For downlink wired port profiles, the static VLAN configuration options will vary depending on the configured traffic forwarding mode. For bridge forwarding, the downlink ports can be configured as access supporting a single VLAN or trunk supporting multiple VLANs. The configuration is identical to how access or trunk ports are configured on an Ethernet switch:

• Access – A single access VLAN ID is required which determines the VLAN ID the AP uses to forward the bridged clients traffic out its uplink port.

• Trunk – A Native VLAN ID and a list of Allowed VLANs must be configured. This will determine which 802.1Q tagged VLANs are accepted by the downlink port and which VLAN is used to forward untagged traffic received from a wired client.

An example of a bridged downlink wired port profile configured as access is depicted in figure XXX. In this example the APs will assign bridged wired clients with no dynamic VLAN assignment to VLAN 75. The AP will forward wired clients traffic out its uplink port on to the access switching layer with the 802.1Q tag 75.

An example of a bridged downlink wired port profile configured as a trunk is depicted in the below figure. This example represents a downlink port profile that is configured to support a VoIP telephone that implements an untagged data VLAN (72) and an 802.1Q tagged voice VLAN (73). Untagged traffic from the VoIP phone is placed into the native VLAN 72 while 802.1Q tagged voice traffic is accepted. As only VLANs 72-73 are accepted by the downlink port, all other tagged VLAN IDs received on the downlink port will be discarded by the AP.

Wired port profiles configured for tunnel forwarding support a single VLAN and must be configured for access mode. The access VLAN can be a VLAN ID or Named VLAN that resides within primary cluster. Downlink wired port profiles configured for tunnel forwarding can only be configured for access mode and will only accept untagged traffic from the wired clients. All traffic received with an 802.1Q tag will be discarded by the AP.

An example of a valid tunneled downlink wired port profile is depicted in the below figure. In this example the APs will assign tunneled wired clients with no dynamic VLAN assignment to VLAN 73 that resides within the primary cluster.

Default VLAN

WLAN profiles configured for mixed traffic forwarding or with dynamic VLAN assignment enabled require a default VLAN to be assigned. As with a static VLAN, the default VLAN is assigned to WLAN clients if no dynamic VLAN assignment is derived from RADIUS or VLAN assignment rule. The default VLAN can be an individual VLAN ID or VLAN Name that you specify or select depending on the configured traffic forwarding mode.

The default VLAN that you defined within each WLAN profile can be considered a catchall VLAN if no dynamic VLAN assignments are made. As a recommended security best practice, the default VLAN should be different than the APs or Gateways management VLAN. If a default AP management VLAN is used, it is recommended that you change the default VLAN to a different value (below figure). This will ensure that no bridged clients are accidentally assigned to the APs management LAN.

VLAN Pools

A VLAN pool allows bridged or tunneled WLAN clients to be distributed across multiple VLANs. When VLAN pooling is implemented, each client is assigned to a VLAN within the pool based using a MAC address hashing algorithm. The implemented algorithm is consistent on both the APs and Gateways and ensures each client will maintain its VLAN assignment each time it connects or roams.

For bridge traffic forwarding, a VLAN pool can consist of a range of contiguous VLAN IDs, a list of non-contiguous VLAN IDs or a list of selected VLAN Names. VLAN Names requiring the respective VLAN Name to ID mappings to be performed within the WLAN profile before selection. A VLAN pool using a contiguous range of VLAN IDs and a list of VLAN names is depicted in figure below:

For tunnel traffic forwarding, a VLAN pool is selected by configuring a Named VLAN within the Gateway configuration group that includes a range of VLAN IDs. The Named VLAN is selected and assigned to the WLAN profile after the primary cluster is selected. A VLAN pool assigned to a WLAN profile configured for tunnel forwarding is depicted in figure below. The Named VLAN and VLAN IDs mappings were configured and managed within the Gateway configuration group:

RADIUS Assigned

Clients connected to WLANs or downlink ports requiring MAC or 802.1X authentication can be dynamically assigned a VLAN from a RADIUS server such as ClearPass or the Cloud Auth service. A RADIUS server can directly assign a VLAN by directly providing a VLAN ID or VLAN Name to an AP or Gateway. A RADIUS server may also indirectly assign a VLAN to a client by providing a user role name which includes the VLAN assignment.

APs and Gateways can directly assign a VLAN provided by a RADIUS server or Cloud Auth service that are configured to provide HPE Aruba Networking vendor-specific attribute value pairs (AVPs) or standard IETF AVPs in RADIUS Access-Accept or change or authorization (CoA) messages. A VLAN can be dynamically assigned from a RADIUS server that is configured to return one of the following AVPs:

• Aruba-User-VLAN – HPE Aruba Networking AVP that provides a numerical VLAN ID (1-4094).

• Aruba-Named-User-VLAN – HPE Aruba Networking AVP that provides a VLAN Name that maps to a VLAN ID (1-4094) configured in the WLAN profile (bridged) or Gateway configuration group (tunneled).

• Tunnel-Private-Group-ID – IETF AVP that provides a numerical VLAN ID (1-4094).

A VLAN can also be dynamically assigned based on user role assignment. Each user role may optionally include a VLAN ID assignment that is configured within the user role as part of the WLAN profile configuration. For tunneled or mixed WLANs, the configured VLAN ID is automatically copied to the user role orchestrated on the Gateways. A RADIUS server or Cloud Auth service dynamically assigns the user role to the clients which determines the bridged or tunneled VLAN assignment. A user role can be dynamically assigned by a RADIUS server by returning the following HPE Aruba Networking vendor-specific AVP:

• Aruba-User-Role – HPE Aruba Networking AVP that provides the user role name.

To simplify operations and troubleshooting, only one dynamic VLAN assignment method should be implemented at a given time. A VLAN ID or VLAN Name assignment should either be directly assigned or indirectly assigned via a user role. If both VLAN assignment options are provided to an AP or a Gateway, the VLAN ID or VLAN Name will take precedence.

VLAN Assignment Rules

A VLAN assignment may also be determined by creating VLAN assignment rules as part of the profile configuration. VLAN assignment rules are optional and permit dynamic VLAN assignments based on admin defined rules that include an attribute, operator, string value and resulting VLAN assignment.

VLAN assignment rules are often implemented during migrations to HPE Aruba Networking by permitting VLAN assignments to be made by an existing RADIUS server and policies that implement IETF or some 3^rd party vendor specific AVPs. Assignment rules permit customers to easily migrate to AOS 10 without having to modify their existing RADIUS policies.

An example of VLAN assignment rules can be leveraged during a migration is depicted in figure XXX. In this example the RADIUS server policies implement the IETF filter-id AVP that returns string values such as employee-acl, iot-acl and guest-acl. Each VLAN assignment rule matches a partial string value and assigns an appropriate VLAN ID. For example, if filter-id returns the string value employee-acl, VLAN 75 is assigned. If no assignment rule is matched, the clients are assigned to VLAN 76.

VLAN assignment rules are supported for bridged, tunneled, and mixed forwarding profiles. When VLAN assignment rules are configured for tunneled or mixed profiles, the assignment rules are automatically orchestrated on the Gateways. Each VLAN assignment rule will be added as a server defined rule (SDR) under the server group for the tunneled or mixed profile.

Assignment Priorities

Depending on the traffic forwarding mode configured within a profile, the AP or the Gateway will make the VLAN assignment decision. For bridge profiles the AP makes the VLAN assignment decision while for tunneled and mixed profiles the Gateway makes the VLAN assignment decision. By default, if no VLAN is dynamically derived, the static VLAN or default VLAN configured in the profile will be assigned.

When multiple VLANs outcomes are possible for a client, an assignment priority is followed by the APs and Gateways. When multiple VLAN outcomes are presented, the AP or Gateway will assign the VLAN based on the assignment option with the highest priority. As a general rule, the VLAN ID or VLAN Name assigned by a RADIUS server, or Cloud Auth service will have the highest priority.

Below table provides the AP VLAN assignment priority for bridged profiles. When multiple VLAN assignment outcomes are presented for a bridged client, the AP will select the assignment option with the highest priority:

Below table provides the Gateway VLAN assignment priority for tunneled WLAN profiles. When multiple VLAN assignment outcomes are presented, the Gateway will select the assignment option with the highest priority:

VLAN Best Practices & Considerations

AOS 10 APs can support any combination of profiles implementing bridge, tunnel, or mixed forwarding modes. When profiles of different forwarding types are implemented, the following considerations should be followed:

• Avoid using VLAN 1 whenever possible. VLAN 1 is the default management VLAN for APs and is also present on the Gateways. VLAN 1 should only be implemented if the default management VLAN is changed on the APs from 1 to a different value.

• If the default AP management VLAN 1 is retained, avoid assigning tunneled clients to a VLAN on the Gateway that indirectly maps to the APs untagged management VLAN. For example, if APs are managed on untagged VLAN 70 on the access layer switch and this VLAN is extended to a Branch Gateway, don’t assign tunneled clients to VLAN 70.

• Implemented dedicated VLAN IDs and broadcast domains for bridged and tunneled clients. An AP can either bridge or tunnel clients on a given VLAN ID and cannot do both simultaneously.

• 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 best practice, only the AP management and bridged user VLANs should be extended to the APs.

• 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 cluster. If layer 3 separation cannot be implemented, a dedicated WLAN using bridged forwarding must be implemented.