Mobility Groups and RF Domains: Any Upper Limits?

Unanswered Question
Aug 24th, 2007

Are there any upper limits as to the number of Mobility Groups and RF domains that can be configured on a given set of controllers?

We are looking for guidance for an implementation that has 250 remote offices and numerous campus locations.

We are prepared to do all the work needed to add all the Mobility Groups and RF domains to all the controllers in the roll-out if this is feasable.

The thinking behind the question is one of ease of management in the long term. If an office was closed all that would need to be done would be to delete the Mobility Group and RF domain associated with it.

Any thoughts? All responses will be rated.


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
chris-marshall Fri, 08/24/2007 - 05:46

Hey pmccubbin!

(I learned this rule back in 3.x code, but I believe it still holds true in 4.1.x code) You can have a max of 24 controllers in a Mobility Group, but usually it isn't recommended to have more than 12.

But, I guess I'm not sure I understand what management advantage having each controller in the same RF domain and mobility group provides... outside of having the headache of managing all those MACs and IPs in each controller.

A question you should ask yourself is "Why do all 250 sites need to be a member of the same Mobility Group and RF Domain?" The only times this is required is when you have physically adjacent locations that need to share RF data or will have users roaming between APs that have different controllers (and you want the user to maintain the same IP).

I'm looking at a larger, but similar deployment, and only in a very small handful do I expect to need to have two or more controllers in the same RF Group and/or Mobility domain.

No matter how you design your RF Domains and Mobility Groups, I will offer that for such a rollout, you should take a long hard look at WCS, as it will likely make your life a lot easier. For example, the process to configure all of your 250 sites with the same mobility group would be to simply go to the "system" configuration page for each controller (within WCS) and check the boxes next to each controller you want to be a member of the same group. No manually typing mac and IP addresses (and therefore no typos). I expect, however, you'd more likely take advantage of the template based nature of WCS... ie. - Create one WLAN template, and push it out to all sites. WCS was made for a deployment like yours. =]

In any case, good luck, and keep us posted!

pmccubbin Fri, 08/24/2007 - 07:47

Hi Chris!

Thanks for your response. Let me clarify:

We want to know how many different Mobility Groups and different RF domains we can create.

We would want all 250 sites in each of the controllers for redundancy and disaster recovery failover.

We would go to the trouble of adding all the Mobility groups and RF domains we create for each site to all the controllers to possibly achieve ease of management in the long term. Specifically, if a site was closed we would simply delete the Mobility group and RF domain for that site.

You are spot on regarding the WCS. No way we could do any of this without a WCS. Right now we are in the Proof-of-concept phase. We had a 30 day evaluation license for the WCS and it demonstrated its worth. Now we have to get the money and put it back into the mix.

I hope that clarifies my original question. Thanks.

chris-marshall Fri, 08/24/2007 - 08:06

Aha... I think I understand now. So, the idea is if one of the 250 sites has a dead controller, you want to make sure that your users at that location still have access to RF, right? If that's the case, you're better bet would be to set each location up with an unique RF domain and Mobility Group, and specify the primary, secondary, and tertiary controller for each AP at each location. In that way, if a given location's controller dies, that location's APs will then join the next available controller in their list, and adopt the RF Domain and Mobility Group settings of their Secondary Controller.

There will be two important considerations to keep in mind with this setup:

1) you need to make sure that the primary, secondary, and tertiary controllers specified in each AP are sufficiently distributed for load. You don't want the worst case situation where multiple controllers die, and their APs flood a single or small handful of controllers looking for a parent.

2) You need to make sure that the bandwidth between sites is sufficient to support the traffic load of passing user's wireless traffic encapsulated within LWAPP across the WAN to the remote office and back.

You might want to look into H-REAP as an alternative. You could centralize your controllers at your HQ (say, a huge fleet of highly redundant WiSMs) and LWAPs in H-REAP mode at each site. In that way, if you loose your controller *OR* your WAN link, your RF would stay up.

pmccubbin Fri, 08/24/2007 - 12:11


Thanks for the response. Further clarification is necessary.

We are using WiSM blades. The answer from Cisco is that only one Mobility group per set of controllers. It would have to support multiple Virtual Interfaces for our scenario to work.

We will instead adopt a naming convention for each site's APs and use the sort feature on the WCS.


Sahil Mengi Wed, 01/09/2013 - 09:23

A Wlc can be a part of only one RF group/domain at any time.

Starting in the release, the RF group members are added based on the following criteria:

Maximum number of APs Supported: The maximum limit for the number of access points in an RF group is 1000. The number of access points supported is determined by the number of APs licensed to operate on the controller.

Twenty controllers: Only 20 controllers (including the leader) can be part of an RF group if the sum of the access points of all controllers combined is less than or equal to the upper access point limit




This Discussion



Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode