A mobility group is a collection of controllers that share RF, client, and AP information. Mobility has two categories: mobility domains (or lists) and mobility groups. If controllers are in the same mobility domain, they are present in the mobility configuration lists of the others, and the controllers listed recognize and communicate with one another. Controllers do not recognize or communicate with other controllers unless they are present in the mobility list. The lack of inter-controller communication in this scenario allows you to limit client roaming on the network by using different mobility group names on your controllers. You can assign mobility by floor, buildings, or campus if you choose. This does not, however, stop a client from roaming between APs joined to controllers with different mobility group names in the list.
The group names constrain the distribution of the security context of a client. It also constrains AP failover between controllers. Client security context updates are sent only to controllers with the same mobility group name as the controller sending the update. This behavior changes in the 5.1 code release and is discussed further a little later in this section. The same goes for AP lists. An AP will not move to a controller that is not in the same mobility group as its current controller if that controller fails.
Figure 9-8 shows the GUI output of a controller mobility configuration.
As you can see, this controller has three controllers in its mobility group, wireless-west, and one controller with a mobility group name of dmz in its mobility list.
Figure 9-8 Mobility Configuration
Note Remember that, although the RF Group and the mobility group name on a controller are usually the same, they are completely independent functions and not required to be the same. You can change the RF Group and mobility group name for a controller any time after the initial configuration is complete.
Controller code Release 5.1 or later supports three mobility groups with up to 24 controllers in a single group for a total of 72 controllers in the mobility list. Prior to controller code Release 5.1, only 48 controllers were allowed in the mobility list.
The number of APs in a single mobility group depends on the model of controllers in that mobility group.
For example, a single Wireless Integrated Service Module (WiSM) controller supports up to 150 APs for a total of 300 APs per WiSM blade. Therefore, if you have 12 WiSMs, or 24 controllers total, the maximum number of APs in that mobility group would be 3600.
Note Starting in code Release 4.2, you can configure APs with controllers outside the mobility group of the controller they are joined to. This feature is covered later in the topic under "AP Mobility."
Controller code Release 5.1 or later allows for seamless roaming across multiple mobility groups in the mobility list of the controller. If a client roams to an AP connected to a controller that is not in the mobility list of the original controller, a seamless roam is not possible. During the inter-mobility group roam, the client is fully authenticated and maintains its current IP address. The controllers initiate a foreign/anchor relationship and EtherIP tunnel for the Layer 3 roaming event just like a regular intra-mobility group roam. If, however, you are using Cisco Centralized Key Management (CCKM) and Proactive Key Caching (PKC), only intra-mobility group roaming is supported.
