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 |
When an AP moves from one controller to another controller (when both controllers are mobility peers), a client associated to the first controller before the move may be anchored to it even after the move. To prevent such a scenario, you should remove the mobility peer configuration of the controller. |
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 shown above, each controller is configured with a list of the other members of the mobility group. 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.
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 groups enable you to limit roaming between different floors, buildings, or campuses in the same enterprise by assigning different mobility group names to different controllers within the same wireless network.
You can configure both IPv4 and IPv6 multicast address for a mobility group. When both the address formats are configured:
-
For all IPv4 mobility group members in the mobility group, the IPv4 multicast group is displayed in the mobility summary information.
-
For all IPv6 mobility group members in the mobility group, the IPv6 multicast group is displayed in the mobility summary information.
-
If you have configured IPv4 multicast for a mobility group, the IPv4 multicast address is not displayed in the mobility summary information if there are no IPv4 mobility group members.
-
If you have configured IPv6 multicast for a mobility group, the IPv6 multicast address is not displayed in the mobility summary information if there are no IPv6 mobility group members.
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. 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. In the following example, controller 1 can communicate with either controller 2 or 3, but controller 2 and controller 3 can communicate only with controller 1 and not with each other. Similarly, clients can roam between controller 1 and controller 2 or between controller 1 and controller 3 but not between controller 2 and controller 3.
Controller 1
Mobility group: A Mobility list: Controller 1 (group A) Controller 2 (group A) Controller 3 (group C) ? |
Controller 2
Mobility group: A Mobility list: Controller 1 (group A) Controller 2 (group A) |
Controller 3
Mobility group: C Mobility list: Controller 1 (group A) Controller 3 (group C) |
In a mobility list, the following combinations of mobility groups and members 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 client moves to a non anchored SSID from an anchored sSSID on foreign, there is a stale entry on foreign .This happens when multicast mobile announce does not reach from foreign to guest anchor due to whatsoever reason, due to this the service is not impacted and configuration goes unnoticed but silently leaks MSCB on GA .There is no debug or error message shown nor does the GA runs a timer per client to cleanup. A HandoffEnd needs to be sent from foreign to Anchor since there is no timer. |