Mobility Group / List / Domain RF Group

At the beginning of the world, wireless networks were small: one controller and a few access points. Then, the young Airespace company (some of you may even remember the even older name, Blackstorm Network) started having larger clients, needing several controllers. Some of them wanted to have controllers isolated from one another, some others wanted a "cluster logic" between controllers, to create a larger virtual controller.

So the Airespace team created the Mobility Group concept, also called Mobility Domain (these two terms mean exactly the same thing). If two controllers belong to the same mobility group, they exchange information about clients (namely, when a new client connects to a controller, this controller informs the other controllers. The result is that when the client roams to another controller, the new controller knows if it is a "new" client (no controller reported this client before), or a roaming client (one controller in the group/domain reported this client before). If it is a roaming client, you can even know which controller the client is coming from, which is very handy to transmit the client credentials from one controller to the other. You could have 12, then later on 24 controllers in the same mobility group/domain.

To make two controllers members of the same mobility group, you needed two steps:

1. Input the same string in the Controller > General > Mobility Domain Name field, so that both controllers have the same mobility group/domain value.

2. Inform each controller about the other, in Controller > Mobility Management > Mobility group. Each controller needs to know the other controller's Management IP address and built-in MAC address.

As a side effect of roaming, we also used to say that if you want roaming to occur smoothly, you'd better run the same code on both controllers (so that they speak the exact same language), and also configure the same virtual gateway IP address (this address is used as a "virtual address" to make the client think that it connects to one big virtual controller instead of several physical controllers).

At that time life was simple... :-) Then some clients also asked to segregate RRM... this was their scenario (kind of): I have 3 controllers, 2 in my office building and one in my warehouse. I want roaming between all of them (okay, so same mobility group/domain and controllers know each other) BUT I do not want cooperation for RRM between the office building and the warehouse. Why? Basically because the warehouse is a specific environment, most of the time isolated from the office and it has specific settings, so I do not want a sort of global master of the network that would not be able to distinguish the warehouse environment from the office environment.

Fine! We are going to create another group concept, the RF-Group (defined in Controller > General). You can put one string for the office building controllers, and another string for the warehouse controller. IF the strings are different, the controllers won't work together for RRM management...

Ok, this is how it works: when you add controllers to the local Mobility group/domain, those controllers send an introduction message to each other (hey, I am X, and oh BTW, my RF-Group is Y). All members of the mobility group also having a common RF-Group value elect an RF-Group leader. The RF-Group leader decides of an RF-Group hash (that represents this RF-Group name shared by those controllers) and sends it back to all members of the RF-Group.

Then, each AP sends, every 60 seconds, a RRM neighbor message from its radios, on all serviced channels. This message contains, among other things, the RF-Group hash. Neighboring APs hearing this message forward it to their respective controller. The controller looks carefully at the message and reads the RF-Group hash value. 2 possibilities:

1. The read RF-Group hash value is different from the RF-Group hash known by the local controller (so the other controller is part of another RF-Group, or the controller to which the AP is connected is unknown to the local controller RF-Group leader): the local controller despises and proudly drops the RRM neighbor message (this is from the RRM standpoint, your good controller may send alerts about rogues etc, but it does not see the neighbor as an RRM partner).

2. The read RF-Group hash value is the same as the RF-Group hash known by the local controller. In that case, the local controller thinks "hey, we are part of the same gang! We should work together on this RRM thing." The controller writes downs which of its access points hear which other controllers access points, and forwards this information to the RF-Group leader. Every 600 seconds by default, the RF-Group leader sends its instructions to the members of the RF-Group: you do this, you do that.

So you can clearly see here that the RF-Group is thought as a sub-group of the mobility group/domain. The other controller needs to be known to the local controller in order to be part of the same RF-Group and gets the same hash... and nothing in the RF-Group configuration allows you to tell the local controller about the other controllers, so it has to be done through the Mobility group/domain. So you configure Mobility group members, and among them some have the same RF-Group value and also share RRM information... limitation was 20 controllers part of the same RF-Group (so 24 controllers in the same mobility group, but yes, 20 members of the same RF-Group max).

Then some more complex scenarios (and more demanding clients?) appeared. They said: your stuff is cool, but does not work as it is, for 2 reasons:

- I want to roam across more than 24 controllers (I have a supabig network)

- I want APs in 2 mobility groups to exchange RRM information. For example, I have 2 floors, 1 controller per floor; people are not roaming from one floor to the other (coz they don't fly through ceilings), but the APs hear each other. So I don't want controllers to exchange information about clients (because it wastes bandwidth as these people will never roam from one controller to the other), but I do want them to exchange RRM information, so that they do not stupidly stay on the same channel.

Okay, it was time to extend the system... and the mobility group/domain concept became the mobility list... the idea is that your controller can know guys with the same Mobility group/domain value, and other guys with another Mobility group/domain value. Your list can contain up to 48 names in controller code 5.0, and 72 on 5.1 and later (so in the CCIE exam, we are still for now on code 4.2, with one mobility group of 24 members max). The key concept is that you do not need to have the same mobility group value to roam. As long as controllers know each other (they are on each other mobility list), they exchange information about connecting clients. The mobility list is what where we used to configure mobility group members before, defined in Controller > Mobility Management > Mobility groups (notice the plural form now).

So what is the difference? Do we still need to care about the Mobility group/domain value? Well, yes! There is a huge difference between mobility group (guys having the same mobility group/domain name as yours) and mobility list (other controllers you know, but that have a different mobility group/domain name from yours): CCKM (Cisco Centralized Key Management) and PKC (proactive Key Caching) do NOT work across mobility groups. This means that if you roam to a controller you know but that has another mobility group value, everything is fine is you use pre-shared key (or open or Web authentication). If you use 802.1X with CCKM or WPA2, your key will not get transmitted to the other controller... and the practical result is that you will have to re-authenticate to get a new key. You will keep your IP address though (as part of the roaming process), so the effect is that you will be briefly disconnected, but your IP session will not be broken. So this is fine if you are a data device. If you are a VoWLAN device, you do not want this disconnection, and you will make sure that controllers you roam to belong to the same mobility group.

So there is still roaming across mobility groups: when you get to new controller, it recognizes you as a valid client coming from another controller, and accepts you. It just fails getting your key if your use CCKM or PKC.

The RF-Group remains unchanged: all members of the same mobility list exchange introduction messages. Those that share the same RF-Group value elect a group leader and start working together on RRM... simple, isn't it?

By Jerome Henry