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
7.0 and Later: VLAN Select and Multicast Optimization Features Deployment
There are no specific requirements for this document.
This document is not restricted to specific software and hardware
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.
Technical Tips Conventions for more information on document
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
Whenever this client joins the controller, the hashing algorithm
always returns the same index and the client is assigned to the same
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
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
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
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
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
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
DHCP Required is disabled on the WLAN.
Subnet A is included in the VLAN or the AP group is configured on
The client sends some packet sourced with a static IP in subnet A
within the DHCP_REQD interval (~ 2 min default
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
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.
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
This feature is supported on all Lightweight APs with 32MB or more
LAPs supported: 1130, 1140, 1240, 1250, 1260, 3500, 3600, 1260, and
Controllers supported: 7500, 5508, WiSM-2, and
Note: Controllers will support this number of interface
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................................ 126.96.36.199
Complete these steps:
Create a new interface group.
Add the interfaces to the group.
Select the interfaces from the drop-down menu, and add it to the
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
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
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
GUI: A new Foreign Maps option is created under
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
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
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
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.
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
(WLC) >config network multicast l2mcast <enable/disable> <interface-name>
Note: This command is applicable only for 5508, 2500, 7500, and WiSM-2
Note: GUI support for enabling/disabling L2 multicast/broadcast per
interface is not available in this release.