A blog with tips, tricks and tutorials to help you prepare your CCIE Wireless lab exam.

Friday, December 4, 2009

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?
:-)

15 comments:

  1. Thanks for this helpful explanation! The Cisco configuration guide and Cisco Press CCNA Wireless book are unclear on this subject, IMHO.

    ReplyDelete
  2. Thanks for the write up Jerome! Great stuff!

    ReplyDelete
  3. This is by far the best write up of mobility I've seen. Thanks alot for your help.

    ReplyDelete
  4. Very helpful, not only informative but also easy to understand the idea.
    The guide defines terms group/domain a little differently:
    mobility domain A controller can be aware of another controller in a different mobility
    group.
    mobility group A setting that defines the controller as a member of a group.

    ReplyDelete
  5. seems not very accurate

    ReplyDelete
  6. Not very accurate why? Seems pretty much the way 4.2 works...

    ReplyDelete
  7. This makes a ton of sense! The Cisco Press books need to be revamped with this explanation!

    ReplyDelete
  8. Jerome, is it possible to not use the management address for mobility control traffic? That is to say, using a dynamic interface to send/receive mobility messages and even use the dynamic interface to anchor WLAN traffic?

    ReplyDelete
  9. Hey Jlkuehn04,
    Nope, you can't at this point. Mobility is always coming from the management interface (because it is management traffic for all WLANs and all clients tunneled to the anchor, and we want to make sure that there is only one tunnel per controller pair, to keep tight control on tunnel overhead...

    ReplyDelete
    Replies
    1. Why is it then, that the below note is in the "Prerequisites for Configuring Mobility Groups" section of the "Configuring Mobility Groups" chapter of the 7.3 Config Guide? It says it is possible, I just haven't figured out how to do it.

      Note

      Mobility control packets can use any interface address as the source, based on routing table. It is recommended that all controllers in the mobility group should have the management interface in the same subnet. A topology where one controller's management interface and other controller's dynamic interface are on same subnet not recommended for seamless mobility.

      Delete
  10. huhu well, that's not a feature, its "something that may happen but this is not want we want to do" (is there an official term for that? :-)). This is why they use the "can" in there, in the sense "it may happen", not "this is something you can configure".
    I can't go too deep into details, but this may happen when your anchor has a dynamic interface with no WLAN in the same L2 and subnet as the foreign controller management interface, but this is bad design.

    ReplyDelete
  11. Jerome, thanks so much for the explanation. I was getting really confused as to what the difference really was between controllers in the same mobility group vs diff mobility group but in the mobility list. I kept reading that you could roam btwn either controller, so the obvious question was "then what's the difference?!?". Now I get that it's seamless if using PSK / Open, and quasi-seamless if using dot1x. So, roaming to a controller in your mobility list is better than roaming to a controller you don't know about at all (which would require both re-auth and re-IP).

    Thanks!!!

    ReplyDelete
  12. You are most welcome!
    On later codes (now that we have 802.11r), 802.11r fast roaming uses a domain identifier (called Mobility Domain Information Element, MDIE) present in the AP beacons. The MDIE is based on the mobility group... so no seamless roaming with 802.11r between mobility groups either!

    ReplyDelete
  13. best mobility/rf domain explanation I have seen bevor.. and so easy descripted!

    ReplyDelete
  14. Keep up the best work guys, nice posts are here to get more benefits.
    Zero Up 2.0 Review

    ReplyDelete