WLC 7.2 VLAN Select and Multicast Optimization Features

Introduction

This document describes in detail the operation and configuration of the Virtual LAN (VLAN) Select modified feature in the controller software release version 7.2.103. In addition, this document describes the operation of the VLAN Select feature in different mobility scenarios and Multicast VLAN operation and configuration when used with the VLAN Select feature.
In order to configure the VLAN Select feature in Wireless LAN Controller (WLC) prior to release 7.2, refer to WLC 7.0 and Later: VLAN Select and Multicast Optimization Features Deployment Guide.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

VLAN Select Feature Overview

In current WLC architecture, it is mandatory to map the Wireless Local Area Network (WLAN) to an interface/VLAN and the default mapping is to the management interface. The limitation is that only one WLAN can be mapped to a single interface/VLAN. This limitation requires availability of a single large subnet in dense deployments, which may not be feasible for many users because of existing network design and IP subnet allocation in their network. Existing features like AP Groups and AAA override may help to some extent, but are unable to meet the complete requirement and may not be feasible in all kinds of user deployments. The same limitation also exists in guest anchor setups where guest clients in remote locations always receive an IP address from a single subnet mapped to a WLAN at an anchor location. Also, an IP address assignment to wireless guest clients is not dependent on foreign locations and all guest clients at different foreign locations will get an IP address from same subnet, which again is not feasible for many users.
Integration of VLAN Pooling or the VLAN Select feature in release 7.0.116 provided a solution to the restriction where the WLAN can be mapped to a single interface or multiple interfaces using an interface group. Wireless clients associating to this WLAN receive an IP address from a pool of subnets identified by the interfaces in a round robin fashion.
In WLC release 7.2, the VLAN Select feature (which is supported only on the newer WLCs like 5508, WiSM-2, 7500, and 2500) was modified and now supports VLAN Select with a new modified algorithm. In the previous implementation, using the round robin algorithm was causing clients to obtain new IP addresses on every re-association, thus depleting IP addresses fast from the available DHCP pools. The new algorithm is based on the Client’s MAC address and operates in this way:

When a client associates to a WLAN on a controller, an index is calculated based on the MAC address of the client and the number of interfaces in the interface group using a hashing algorithm.
Based on this index, an interface is assigned to the client.
Whenever this client joins the controller, the hashing algorithm always returns the same index and the client is assigned to the same interface.
If the interface is “dirty”, then a random index is generated and the interface is assigned based on that random index.
If that interface is still dirty, then a fall back to round robin implementation occurs.

Note: In order to support the new VLAN Select feature on legacy controllers (such as the 4400 Series, WiSM, and 2100 Series) with the same MAC-based algorithm, the VLAN Select feature was modified in release 7.0.230 and now operates in the same fashion as release 7.2.
This flow chart illustrates the DHCP address selection when the MAC Hashing algorithm is used in the interface/interface group configuration:

Note: With IRCM, controllers in releases prior to 7.0.116 and above cannot understand the VLAN list payload. As a result, sometimes L3 mobility occurs where L2 mobility could have occurred.
Note: If you want to downgrade from release 7.2 to a release prior to 7.0.116, make sure that all WLANs are mapped to interfaces and not interface groups, and multicast interface is disabled.
Note: The interface group returned from AAA is now a supported feature in release 7.2.
Note: Interfaces can be added to an interface group, but cannot be deleted while it is mapped to a WLAN/AP group.
Note: One VLAN or Interface can be a part of many different interface groups.
Note: If you change the number of interfaces in the interface group, then the hashing algorithm may return a different index and the client is assigned to a different interface.
Note: If the number of interfaces in an interface group remains fixed, the client will always be assigned to the same interface provided the interface is not dirty.
The VLAN Select feature also extends current AP group and AAA override architecture where AP groups and “AAA override” can override the interface or the interface group to which the WLAN is mapped. This feature also provides the solution to guest anchor restrictions, where a wireless guest user at a foreign location can now get an IP address from multiple subnets based on their foreign locations/foreign controllers from the same anchor WLC.
This flow chart indicates WLAN selection when the AP group and AAA override are configured on the controller, and the WLAN has been mapped to the interface or interface groups:

Note: Some exclusions apply for static IP clients:

If a client has a static IP configured in, for example, subnet A, and they are allotted subnet B, they will get moved to subnet A (override), before moving to the RUN state, if these conditions are met:
- DHCP Required is disabled on the WLAN.
- Subnet A is included in the VLAN or the AP group is configured on the WLAN.
- The client sends some packet sourced with a static IP in subnet A within the DHCP_REQD interval (~ 2 min default value).
The DHCP_required interval is configurable and can have a maximum value of 120 seconds. Go to Controller > Advanced > DHCP Parameters > DHCP timeout (5-120 seconds).
If the static IP client has an IP address from a subnet that is part of the interface group which is mapped to the WLAN, then the static IP client that joins over that WLAN will move to a RUN state and can pass traffic. Otherwise, the static IP client cannot pass traffic.

Same Subnet Mobility

In the current solution, when a client roams from one controller to another, the foreign controller sends the VLAN information as part of the mobility Announce message. Based on the VLAN information received, the anchor decides whether the tunnel should be created between the anchor and foreign controllers. If the same VLAN is available on the foreign controller, then the client context is completely deleted from the anchor controller, and the foreign controller becomes the new anchor controller for the client.
As part of the VLAN Pooling feature, the “Mobility Announce” message will carry an additional vendor payload containing the list of VLAN interfaces mapped to a WLAN. This helps the anchor controller to decide on Local > Local type of handoff. The introduction of this feature also ensures that the inter release mobility is not affected. In a guest tunneling scenario, clients joining on “export foreign” will receive an IP address from the interface group mapped to the WLAN on the “export anchor” or as per the foreign mappings configured on the “export anchor”. If the clients who have joined over “export foreign” move to the “export anchor” controller, they may lose their IP address, which means mobility is not supported between those two. However, if the clients move between two “export foreign” controllers, they will retain their IP address, which means roaming is supported in that scenario.

Multicast Optimization

At present, multicast is based on the grouping of the multicast address and the VLAN as one entity: mgid. The VLAN pooling feature has the potential of increasing the duplicate packets on the air. Since each client listening to the multicast stream is on a different VLAN, the WLC will create different mgids for each pair of multicast addresses and VLAN. As a result, the upstream router sends one copy for each VLAN. This results in the worst case, in as many copies as there are VLANs in the pool. Since the WLAN is still the same for all clients, multiple copies of the multicast packet are sent on the air.
The integration of the VLAN Select feature also introduces some issues in current multicast architecture where wireless clients may receive duplicate packets. The issue of receiving duplicate multicast packets was already present in current multicast architecture, but it was only visible when AAA override was configured and two clients on different subnets (one on a WLAN-mapped subnet and another on an overridden subnet) listen to the same multicast group. With the introduction of the VLAN Select feature, this problem is more obvious and easily visible on open WLAN.
The multicast VLAN method is introduced in an effort to suppress the duplication of a multicast stream on the wireless medium and between the WLC and access points (APs). This VLAN is used for multicast traffic. One of the VLANs of the WLAN is configured as a multicast VLAN on which multicast groups are registered. Configuring the multicast VLAN for the WLAN is controlled by the user. Clients are allowed to listen to a multicast stream on the multicast VLAN. The mgid is generated using mulicast VLAN and a multicast IP address. As a result, multiple clients on a VLAN pool of the same WLANs listening to a single multicast IP address will always generate a single mgid. The WLC will make sure that all multicast streams from the clients on this VLAN pool will always go out on the multicast VLAN. This ensures that the upstream router has just one entry for all the VLANs of the VLAN pool. As a result, only one multicast stream will hit the VLAN pool even if the clients are on different VLANs. Therefore, the multicast packets also sent out on the air will be just one stream.
On the network interface, the corresponding VLAN is still used for all their traffic.

Platforms Supported

This feature is supported on all Lightweight APs with 32MB or more flash space:

LAPs supported: 1130, 1140, 1240, 1250, 1260, 3500, 3600, 1260, and 1522/1524
Controllers supported: 7500, 5508, WiSM-2, and 2500

Note: Controllers will support this number of interface groups/interfaces:

WiSM-2, 5508, 7500, 2500 -- 64/64

Configuration through CLI and GUI

Check that the initial code on the WLC is 7.2.103:

(Cisco Controller) >show boot 
Primary Boot Image............................... 7.2.103
Backup Boot Image................................ 7.0.230.0

Complete these steps:

Create a new interface group.
- CLI : config interface group create <interface group name>
- GUI: Go to Controller > Interface Groups > Create a new Group.
Add the interfaces to the group.
- CLI: config interface group interface add <interface> <interface name>
- GUI: Click the Interface Group Name.
Select the interfaces from the drop-down menu, and add it to the group.
Apply the interface group to a WLAN.
- CLI : In order to configure mapping of interface/interface group to the WLAN, issue this command:
```
config wlan interface <wlan id> <Interface/Interface group name>
```
- GUI: The interface groups are identified by postfix (G). Go to WLAN > General, and choose the interface group.
  
  Note: When AAA override is not enabled on a WLAN, clients joining the WLAN receive an IP address based on the interface or interface group mapping on the WLAN.
  Note: When AAA override is enabled on a WLAN, clients joining the WLAN receive an IP address based on the interface or the interface group returned by the AAA server.
Configure the AP group or AAA override of the WLAN.
Map the interface group to a foreign WLC. Configure subnet/address assignment based on foreign site/location in the guest anchor setup.
- CLI: config wlan mobility foreign-map add <wlan-id> < mac address > <interface/interface group>
- GUI: A new Foreign Maps option is created under the WLAN.
  
  As part of the VLAN Select feature, the “Mobility Announce” message will carry an additional vendor payload containing the list of VLAN interfaces mapped to a WLAN. This helps the anchor to decide on Local > Local type of handoff.
  When a client roams from one controller to another, the foreign controller sends the VLAN information as part of the Mobility Announce message, and, based on the VLAN information received, the anchor decides whether the tunnel should be created between the anchor and foreign controllers. If the same VLAN is available on the foreign controller, the client context is completely deleted from the anchor controller and the foreign controller becomes the new anchor controller for the client.
  Note: In a Guest Tunneling scenario, roaming between export foreign and export foreign is supported. However, roaming between export foreign and export anchor is not supported with VLAN Select.
  In the case of Auto Anchor:
  - Clients joining a foreign WLC which is exported to an anchor WLC and mapped to an interface group will receive an IP address in a round robin method inside the interface group.
  - Clients joining a foreign WLC which is exported to an anchor WLC and mapped to an interface only will receive an IP address from that interface only.
  - Clients roaming between two or more foreign controllers mapped to a single anchor WLC with an interface group configured will be able to maintain its IP address.
  Note: Anchors have to be in the same Mobility Group.
  Note: WLANs should be configured identically in the foreign and anchor controllers.

L3 Multicast Configuration in Interface Group

With interface groups, multiple VLANs are mapped to a single SSID. When the clients in different VLANs subscribe to a Multicast stream, duplicate entries are created in the WLC for a single SSID. As a result, single multiple streams may be sent multiple times over the air depending on the number of VLANs present in an interface group. In order to prevent this, an enhancement is performed where a single VLAN is selected as the representative VLAN for flow of all IGMP and multicast over the air.
Configuration:

CLI: config wlan multicast interface <wlan-id> enable <interface name>
GUI:

Note: This configuration is allowed only when IGMP snooping is enabled.

L2 Multicast Configuration in Interface Group

Just like L3 Multicast optimization, L2 multicast and broadcast optimization is very important with the VLAN Select feature. Additional commands were added in release 7.0.116 and above in order to optimize L2 multicasts and broadcasts.
L2 Multicast/ Broadcast use L2 MGID in order to forward the packet to the AP. L2 Multicast/Broadcast from all the VLANs in the group will be sent on the WLAN. This causes duplication packets on AIR.
In order to limit these duplications, L2 Multicast/Broadcast enabling/disabling per interface was introduced.
CLI: Enable/Disable L2 Multicast and Broadcast for the interface:

(WLC) >config network multicast l2mcast <enable/disable> <interface-name>

Note: This command is applicable only for 5508, 2500, 7500, and WiSM-2 controllers.
Note: GUI support for enabling/disabling L2 multicast/broadcast per interface is not available in this release.