Cisco/Airespace Mobility Group Details (Confusion)

[laaustin]

The following text represents my perspective. I now face a complicated situation about the implications of design issues using features dependent on Mobility Groups. If someone can provide an experienced-based explanation please chime in.

PLEASE DON'T RESPOND WITH DOCUMENTATION REFERENCES UNLESS YOU'VE USED THEM AND THEY WORK RELIABLY ACCORDING TO YOUR DIRECT EXPERIENCE

Mobility groups initially began as a relatively simple concept - provide mobility of clients across APs. The concept also addressed grouping APs into a domain to provide AP resiliency when primary controller failure occurs. Then a split occurred that allowed RF mobility groups to exist separately from data/traffic/client mobility groups. Finally we now can define interface/WLAN proxies that implement ethernet-over-ip tunnels (the Guest WLAN concept) - that also uses mobility components - 'anchors'.

What side effects occur when using different mobility groups (set the RF groups aside - that appears easily understood compared to this stuff)? I defined a unique mobility group for each remote site (wlc + APs), a mobility group for the 'CISCO-LWAPP-CONTROLLER' cluster ('staging' controllers to catch any APs in the network that lose their controller), and a mobility group for EoIP tunnel termination.

I find that getting AP fallback to work a huge problem. APs defined with their primary/secondary controller just seem to hang onto the staging controller. The behavior of the remote APs prove the exception - they do reattach to their local controller once they get rebooted (but it does require a reboot). The local APs just stay on the staging controller.

Does anyone possess an explanation based on genuine knowledge about the nuances and gotchas about this stuff? It seems that Cisco needs to rethink the concept of mobility entities... It appears that we now have a number of tactical hacks that represent an operational nightmare in networks that carry any sizeable number of controllers, APs, locations, and services (requiring EoIP tunnels)...

If you've not had to consider this kind of environment, please save your speculative answer for some other query - I seek some experienced insight here...

Thanks...

[wififofum]

No answers for you - just a thanks for asking the tough questions about how reliable, scalable and technically under-exposed these nuances are. All I have received thusfar is similar confusion from TAC. I plan on meeting with an Airespace engineer next week. I'll be glad to forward you anything I find out.

[Dmitry Halavin]

For AP failover to work, you must have the controllers in the same mobility group. The only time you add controllers to the mobility group members page that are NOT in the same mobility is for guest tunneling.

If you have a building with 3 controllers, 2 for corporate access, and 1 for DMZ, the 2 controllers will share 1 mobility group, and the 3rd will be in a separate group. Then you add them all to each other's mobility group lists, with the correct name defined. APs will be able to fail over from 1 to 2 and vice versa, but NO APs will go to #3.

In addition, for the future, if you deploy a new building with 2 more controllers, and want them to be in a separate mobility group (don't want APs going to the first 2 controllers in case of failover), that's fine, and you can add the 3rd controller from scenario #1 (the one in the DMZ) to the mobility group members page. Since it's in its own mobility group, APs will still not fail over to it, but it can act as the anchor for guest WLANs.

[laaustin]

Thanks! Now, I wish Cisco told me this when I pleaded for information about controller location... I originally wanted to deploy building controllers, however everyone (and we're talking Airespace folk) gave pretty vague responses - but without any overriding physical and logical design considerations. I now have something to ponder - where/how to deal with the staging controller. And I'll consider whether or not to go fight with our network architects - that imposed the physically central controller implementation, rather than my recommendation of employing building controllers...

Finally, in your first paragraph - can you tell me if the 'guest' tunnel controller entries count against the mobility group member limit of 24 entries (or controllers)? I hope it doesn't, but I think it does...

I appreciate your response - Thanks...

[Dmitry Halavin]

The list can actually hold 40 entries. Each mobility name can hold 24 (for ap failover, roaming, etc), so that leaves you with 16 extra for guest tunneling.

[laaustin]

Wow... I really appreciate your answers... your replies really help...

So, the 'mobility list' appears to be a controller association or relationship table with a size of 40 entries.

The mobility group - a namespace with a capacity of 24 members. I presume the MG relationships result from inter-controller communication within the shared namespace, that populate the mobility lists on each controller...

I'm spouting out what I understand based on your replies...

Thanks again - very much...

-l