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 handoff.
In a static anchor setup using controllers and RADIUS server, 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 controller.
Mobility is not supported for SSIDs with security type configured for web authentication on MAC filter failure.
If the management VLAN of one controller is present as a dynamic VLAN on another controller, 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 controller fail to ping each other’s IPv6 addresses, and they are in the same VLAN, you need to disable snooping to get the controller 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 controller, 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.
Definitions of Mobility-related Terms