Information About Mobility Groups
A mobility group is a set of controllers, identified by the same mobility group name, that defines the realm of seamless roaming for wireless clients. By creating a mobility group, you can enable multiple controllers in a network to dynamically share information and forward data traffic when inter-controller or inter-subnet roaming occurs. Controllers in the same mobility group can share the context and state of client devices as well as their list of access points so that they do not consider each other’s access points as rogue devices. With this information, the network can support inter-controller wireless LAN roaming and controller redundancy.
Note |
If migrating APs from one controller to another controller to decommission the old controller, clients that were associated with the first controller before the move might be anchored to the old controller after the move. As a workaround, you must disable the WLANs on the old controller before decommissioning it. |
Note |
Controllers do not have to be of the same model to be a member of a mobility group. Mobility groups can be comprised of any combination of controller platforms as long as the controllers are running compatible AireOS versions. For more information, see the "IRCM Compatibility Matrix for AireOS Releases" section in the Cisco Wireless Solutions Software Compatibility Matrix document. |
As shown above, each controller is configured with a list of the other members of the mobility group. In this example, client data traffic is tunneled between controllers in Ethernet-over-IP as mobility encryption is not configured. Whenever a new client joins a controller, the controller sends out a unicast message (or multicast message if mobility multicast is configured) to all of the controllers in the mobility group. The controller to which the client was previously connected passes on the status of the client. You can configure the controller to use multicast to send the Mobile Announce messages. This functionality enables the controller to send only one copy of the message to the network, which destines it to the multicast group that contains all the mobility members. To derive the maximum benefit from multicast messaging, we recommend that you enable multicast messaging for all group members.
For example, if a controller supports 6000 access points, a mobility group that consists of 24 such controllers supports up to 144,000 access points (24 * 6000 = 144,000 access points).
Mobility messages among mobility group members can be transmitted in IPv4 or IPv6, as unicast or multicast. We recommend multicast messaging for large mobility groups.
The controllers in the ABC mobility group share access point and client information with each other. The controllers in the ABC mobility group do not share the access point or client information with the XYZ controllers, which are in a different mobility group, unless each mobility group member is configured with mobility list entries for the other mobility group members. Likewise, the controllers in the XYZ mobility group do not share access point or client information with the controllers in the ABC mobility group. This feature ensures mobility group isolation across the network.
Every controller maintains information about its peer controllers in a mobility list. Controllers can communicate across mobility groups and clients may roam between access points in different mobility groups if the controllers are included in each other’s mobility lists.
A mobility group can have up to 24 members and a mobility list can have up to 72 members. For example, the following combinations are allowed:
-
3 mobility groups with 24 members in each group
-
12 mobility groups with 6 members in each group
-
24 mobility groups with 3 members in each group
-
72 mobility groups with 1 member in each group
The controller supports seamless roaming across multiple mobility groups. During seamless roaming, the client maintains its IP address across all mobility groups; however, Cisco Centralized Key Management (CCKM) and proactive key caching (PKC) are supported only for inter-mobility-group roaming. When a client crosses a mobility group boundary during a roam, the client is fully authenticated, but the IP address is maintained, and mobility tunneling is initiated for Layer 3 roaming.
Note |
When a controller is added to a mobility group, some of the APs (which are running in local mode) do not get the complete controllers list updated, those APs are connected to controllers that are in the same mobility group. You can view the controller list in the APs using the command show capwap client config ap-name command. For example, if the mobility group is for 19 controllers and then you add two more controllers to the mobility group, the AP shows 19 controllers instead of 21 in its list. To address this issue, you must reboot the AP or move the AP to another controller that is part of the same mobility group to get the controller list updated. This issue is observed in AP1242 connected to different Cisco 5508 WLCs running code 7.6.120.0. |