Mobility, or roaming, is a
wireless LAN client’s ability to maintain its association seamlessly from one
access point to another securely and with as little latency as possible. This
section explains how mobility works when controllers are included in a wireless
When a wireless client
associates and authenticates to an access point, the access point’s controller
places an entry for that client in its client database. This entry includes the
client’s MAC and IP addresses, security context and associations, quality of
service (QoS) contexts, the WLAN, and the associated access point. The
controller uses this information to forward frames and manage traffic to and
from the wireless client.
Figure 1. Intracontroller
Roaming. This figure shows
a wireless client that roams from one access point to another when both access
points are joined to the same controller.
When the wireless client
moves its association from one access point to another, the controller simply
updates the client database with the newly associated access point. If
necessary, new security context and associations are established as well.
The process becomes more
complicated, however, when a client roams from an access point joined to one
controller to an access point joined to a different controller. It also varies
based on whether the controllers are operating on the same subnet.
Figure 2. Intercontroller
Roaming. This figure shows
intercontroller roaming, which occurs when the wireless LAN interfaces of the
controllers are on the same IP subnet.
When the client associates to
an access point joined to a new controller, the new controller exchanges
mobility messages with the original controller, and the client database entry
is moved to the new controller. New security context and associations are
established if necessary, and the client database entry is updated for the new
access point. This process remains transparent to the user.
Figure 3. Intersubnet Roaming. This figure shows
intersubnet roaming, which occurs when the wireless LAN interfaces of the
controllers are on different IP subnets.
All clients configured with
802.1X/Wi-Fi Protected Access (WPA) security complete a full authentication in
order to comply with the IEEE standard.
Inter-subnet roaming is
similar to inter-controller roaming in that the controllers exchange mobility
messages on the client roam. However, instead of moving the client database
entry to the new controller, the original controller marks the client with an
“Anchor” entry in its own client database. The database entry is copied to the
new controller client database and marked with a “Foreign” entry in the new
controller. The roam remains transparent to the wireless client, and the client
maintains its original IP address.
In inter-subnet roaming,
WLANs on both anchor and foreign controllers need to have the same network
access privileges and no source-based routing or source-based firewalls in
place. Otherwise, the clients may have network connectivity issues after the
In a static anchor
setup using controllers and ACS, if AAA override is enabled to dynamically
assign VLAN and QoS, the foreign controller updates the anchor controller with
the right VLAN after a Layer 2 authentication (802.1x). For Layer 3 RADIUS
authentication, the RADIUS requests for authentication are sent by the anchor
Mobility is not
supported for SSIDs with security type configured for Webauth on MAC filter
If the management VLAN
of one Cisco WLC is present as a dynamic VLAN on another Cisco WLC, the
mobility feature is not supported.
If a client roams in web
authentication state, the client is considered as a new client on another
controller instead of considering it as a mobile client.
When the primary and secondary WLCs fail to ping each other’s IPv6 addresses, and they are in the same VLAN, you need to disable snooping to get the WLCs to ping each other successfully.
New Mobility with WebAuth and MAC filter is not supported. For a
client, if L2 authentication fails and it falls back to L3 authentication and
then tries to roam to a different Cisco WLC, the roaming will fail. The same
behavior is applicable to FlexConnect central switching and local mode as well.
Cisco Wireless Controllers (that are mobility peers) must use the same
DHCP server to have an updated client mobility move count on intra-VLAN.