This document explains the VLAN Select feature that is introduced in the Wireless LAN Controller (WLC) release 18.104.22.168. The document also discusses how to deploy this feature in a Cisco Unified Wireless Solution.
In order to configure the VLAN Select feature in WLC release 7.2 and later, refer to WLC 7.2 VLAN Select and Multicast Optimization Features Deployment Guide.
Cisco recommends that you have knowledge of these topics:
This feature is supported on all Lightweight APs (LAPs) with 16MB or more flash space.
LAPs Supported: 1120, 1230, 1130, 1140, 1240, 1250, 1260, 3500 and 1522/1524
Controllers Supported: 7500, 5508, 4402, 4404, WISM, WiSM-2, 2500, 2106, 2112, 2125
Note: Controllers will support these number of Interface groups/Interfaces:
WiSM-2, 5508, 7500, 2500 -- 64/64
WiSM, 4400, 4200 –- 32/32
2100 and NM6 series -- 4/4
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.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
In current WLC architecture, it is mandatory to map the WLAN to an interface/VLAN. Default mapping is to management interface. The limitation is that one WLAN can be mapped to a single interface/VLAN. This limitation requires availability of a single large subnet, in dense deployments, which might not be feasible for many customers because of existing network design and IP subnet allocation in their network. Existing features, such as AP Groups and AAA override, can help to some extent but cannot meet complete requirements and might not be feasible in all kinds of customer deployments. This same limitation also exists to the guest anchor setup where guest clients on remote locations always get an IP address from a single subnet mapped to the WLAN on anchor location. Also, the IP address assignment to wireless guest clients is not dependent on foreign locations and all guest clients on different foreign locations will receive an IP address from the same subnet. Once again, this is not feasible for many customers.
Integration of VLAN Pooling, or the VLAN Select feature, in the 22.214.171.124 release provides a solution to this restriction where the WLAN can be mapped to a single interface or multiple interfaces using interface group. Wireless clients associating to this WLAN will receive an IP address from a pool of subnets identified by a MAC hashing algorithm which is calculated based on the MAC address of the client and the number of interfaces in the interface group. In the instance that the interface selected from the interface group by the MAC hashing algorithm does not serve the IP address to the client for some reason (dhcp server unreachable, dhcp scope exhausted, etc.), that interface will be marked as dirty and a random interface is selected from the interface group.
This flowchart illustrates the DHCP address selection when the round robin mechanism is used in interface or interface group configuration:
Note: If the DHCP lease time is high, there is a possibility of DHCP IP leakage if the clients frequently de-authenticates and re-authenticates.
Note: With Inter-Release Controller Mobility (IRCM), controllers in releases before 126.96.36.199 cannot understand the VLAN list payload. Therefore, sometimes a L3 mobility is performed where L2 mobility could have been done.
Note: If you want to downgrade from the 188.8.131.52 release to a previous release, make sure that all WLANs are mapped to interfaces and not interface groups, and multicast interface is disabled.
Note: Cisco does not support an interface group being returned from AAA, only interface.
Note: Interfaces can be added to an interface group but cannot be deleted when it is mapped to the WLAN/AP Group.
Note: One VLAN or interface can be a part of many different interface groups.
The VLAN Select feature also extends current AP group and AAA override architecture where AP groups and AAA override can override the interface/interface group the WLAN is mapped to with an interface or interface group. This feature also provides the solution to guest anchor restrictions where now wireless guest user on foreign location can get an IP address from multiple subnets based on their foreign locations/foreign controllers from same Anchor WLC.
This flowchart indicates WLAN selection when AP group and AAA override are configured on the controller and WLAN has been mapped to an Interface or Interface Groups:
Note: Some exclusions apply for static IP clients:
If client has a static IP configured in subnet A and is allotted subnet B, the client is moved to subnet A (override) before moving to RUN state, if these conditions are met:
DHCP Required is disabled on the WLAN.
Subnet A is included in VLAN or AP group configured on WLAN.
Client sends some packet sourced with static IP in subnet A within 4 min DHCP_REQD interval.
Note: 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 joining over that WLAN moves to 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 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. If the same VLAN is available on the Foreign, then the client context is completely deleted from the Anchor and the Foreign becomes the new Anchor Controller for the client.
As part of the VLAN Pooling feature, the Mobility Announce message carries an additional vendor payload that contains the list of VLAN Interfaces mapped to a WLAN. This helps the Anchor to decide on Local > Local type of handoff. It is ensured that the inter-release mobility does not get affected because of the introduction of this feature. In a guest tunneling scenario, clients joining on “export foreign” receive the IP from the interface group mapped to the WLAN on “export anchor”, or as per the foreign mappings configured on “export anchor”. If the clients who have joined over “export foreign” move to the “export anchor” controller, they might lose their IP address which means mobility is not supported between those two. However, if the clients move between two “export foreign” controllers, they retain their IP address which means roaming is supported in that scenario.
Multicast at present 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. Because each client listening to the multicast stream is on a different VLAN, the WLC creates different mgids for each pair of multicast address and VLAN. Therefore, the upstream router sends one copy for each VLAN. This results, in the worst case, as many copies because there are VLANs in the pool. Because the WLAN is still the same for all clients, multiple copies of the multicast packet are sent on the air.
Integration of the VLAN select feature also introduces some issues in current multicast architecture where wireless clients can 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 is configured and 2 clients on different subnet (one on WLAN mapped subnet and another on overridden subnet) listen to same multicast group. With the introduction of VLAN select feature, this problem will be more obvious and easily visible on open WLAN also.
In order to suppress the duplication of a multicast stream on the wireless medium between the WLC and APs, the multicast VLAN method is introduced. This VLAN is used for multicast traffic. One of the VLANs of the WLAN is configured as multicast VLAN on which multicast groups are registered. Configuring the multicast VLAN for the WLAN is controlled by the user. Clients will be allowed to listen to a multicast stream on the multicast VLAN. The mgid is generated using ‘multicast VLAN’ and multicast IP address. Therefore, if multiple clients in the VLAN pool of the same WLAN are listening to a single multicast IP address will always generate single mgid. The WLC will make sure that all multicast stream from the clients on this VLAN pool will always go out on the multicast VLAN. This will ensure the upstream router will have just one entry for all the VLANs of the VLAN pool. Hence only one multicast stream will hit the VLAN pool even if the clients are on different VLANs. Therefore, the multicast packets sent out on the air will be just one stream.
On the network interface the corresponding VLAN is still used for all their traffic.
Complete these steps:
Verify that the Initial code on the WLC is 184.108.40.206 (???).
(Cisco Controller) >show boot
Primary Boot Image............................... 7.0.X.X (active)
Backup Boot Image................................ 7.0.x.x
Create a new Interface Group.
Add interfaces to the Group.
Select the Interfaces from the drop-down menu and add it to the group.
Complete these steps:
In order to configure mapping of an interface or interface group to the WLAN, use the config wlan interface <wlan id> <Interface/Interface group name> command.
Interface Groups are identified by a postfix (G).
Under WLANs > General > choose the Interface Group.
Complete these steps:
Configure the AP group or AAA override of the WLAN.
Note: When AAA override is not enabled on a WLAN, clients joining the WLAN receive the IP address based on the interface or interface group mapping on the WLAN. When AAA override is enabled on a WLAN, clients joining this WLAN receive the IP address based on the interface returned by AAA server.
Complete these steps:
In order to configure the subnet/address assignment based on a foreign site or location in guest anchor setup:
As part of the VLAN Select feature, the Mobility Announce message carries an additional vendor payload that contains the list of VLAN Interfaces mapped to a WLAN. This helps the Anchor decide on Local > Local type of handoff.
When a client roams from one Controller to another, the Foreign 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.
If the same VLAN is available on the Foreign, then the client context is completely deleted from the Anchor and the Foreign 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 case of Auto Anchor:
Clients joining a foreign WLC, which is exported to an anchor WLC and mapped to a interface group, will receive an IP address in round robin method inside the interface group.
Clients joining a foreign WLC, which is exported to an anchor WLC and mapped to a 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 identical in the Foreign and Anchor controllers.
With interface-groups, multiple VLANs are mapped to a single SSID. When clients in a different VLAN subscribe to a Multicast stream, duplicate entries are created in the WLC for a single SSID. As a result, a single Multicast stream can 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 done where a single VLAN is selected as the representative VLAN for flow of all IGMP and multicast over the air.
Complete these steps:
Note: This configuration is allowed only when IGMP snooping is enabled.
Similar to L3 Multicast optimization, L2 multicast and broadcast optimization is very important with the VLAN select feature. Additional commands were added in the 220.127.116.11 release to optimize L2 multicasts and broadcasts. L2 Multicast/ Broadcast uses L2 MGID to forward the packet to the AP. L2 Multicast/Broadcast from all the VLANs in the group will be sent on WLAN. This causes duplication packets on AIR. In order to limit these duplication L2 Multicast/Broadcasts, enabling or disabling per interface is introduced.
CLI: Enable/Disable L2 Multicast and Broadcast for the interface.
Use the (WLC) >config network multicast l2mcast <enable/disable> <interface-name> command.
Note: This command is applicable only for 5508, 2100, 2500, 7500 and WiSM-2 controllers.
Note: GUI support for enabling or disabling L2 multicast/broadcast per interface is not introduced in this release.