WLC Discovery Process & Selection

Wireless
1

Hello, everyone.

I haven’t found a corresponding NW lesson to this, so I am creating a new forum thread.

3.3.c Describe access point discovery and join process (discovery algorithms, WLC selection process)

I have some questions regarding the WLC discovery process that the OCG mentions:

An AP can be “primed” with up to three controllers—a primary, a second-
ary, and a tertiary. These are stored in nonvolatile memory so that the AP can
remember them after a reboot or power failure. Otherwise, if an AP has previ-
ously joined with a controller, it should have stored up to 8 out of a list of
32 WLC addresses that it received from the last controller it joined. The AP
attempts to contact as many controllers as possible to build a list of candidates.

From what I understand, regardless of what we configure, the AP will attempt to discover as many WLCs as possible?

Is this primary/second/ter configuration done on the AP or the WLC? If these 3 controllers are configured and an AP reboots and discovers all the WLCs, are these the first 3 controllers that it will attempt to join? Also, what is “tertiary”? :smiley:

So does the WLC selection process work the following way?

  1. Try to join the primary WLC. If that fails, try the secondary one, and so on.
  2. If none of these 3 are configured, join the controller that you joined previously
  3. If you didn’t join any controller previously, join the least-loaded one.

Then again, this seems a bit different than what, for example Kevin Wallace says

obrázok
obrázok399×240 13.7 KB

He mentions something called a master controller?

My next question is

Otherwise, if an AP has previ-ously joined with a controller, it should have stored up to 8 out of a list of 32 WLC addresses that it received from the last controller it joined.

The controller tells the AP what other WLCs exist? A cisco doc says

Also, the LAP remembers the management IP address of its controller and the controllers present as mobility peers even across reboot. However, as soon as the AP joins another WLC, it only remembers the IP of that new WLC and its mobility peers and not the previous ones.

So if it does associate with a WLC, does the WLC also tell it what other WLCs there are?

It’s all getting randomly mixed up together and I unfortunately don’t get what happens when in which order.

Thank you.
David

2

Hello David

There are several mechanisms in place that aid an AP in finding and using available WLCs. First of all, we have the “primed” WLCs. These are the primary/secondary/tertiary WLCs. These are manually configured in the AP, and can be configured either using the CLI or he GUI from the active WLC. The term “primed” simply means that these configured WLCs will be used by the AP immediately, and if one of those fails, it switches over to the next WLC. More detailed info can be found here:

Yes, that is exactly correct. And the word “tertiary” simply means “third”, it’s the third WLC that it will attempt to connect to.

Other than the primary/secondary/tertiary WLCs which are manually configured, here is how an AP learns about the various other WLC addresses:

  • When an AP joins a WLC, the controller sends it a list of 32 WLCs (its own mobility peers).
  • The AP stores up to 8 of these WLCs (prioritizing primed controllers first), replacing older entries.
  • If the AP later joins a new WLC, it overwrites its stored list with the new controller’s mobility peers.
    • This explains why an AP “forgets” older WLC lists after joining a new controller.

Now the use of the term “master controller” likely pertains to mobility groups. In a mobility group, a Master Controller manages AP failovers and RF coordination. However, APs do not prioritize the Master Controller during initial discovery unless it is explicitly configured as their primary/secondary/tertiary WLC or appears in their cached list.

Yes. It is a bit confusing as there is different information found in different documents, but each one talks about a different stage in the process. The whole process is what I have listed above.

I hope this has been helpful!

Laz

3

Hello Laz.

That makes a lot of sense, thank you.

To verify, the AP finds as many WLCs as possible. Then, it will try them in the following order?

  1. Try the primary controller, then the secondary and then the third one.
  2. What happens here? Does the AP join the least-loaded controller or does it join a previously joined one first?

Also, please, when it comes to discovering the controller, is there any preference in what comes first? For ex: does a L2 broadcast come first, then DHCP, etc? This cisco doc says that it doesn’t:

obrázok
obrázok1347×410 66.7 KB

And then my CBT Nuggets course is asking for its order.

obrázok
obrázok766×367 13.8 KB

The CBT Nuggets order is L2 broadcast, DHCP, DNS, and manual config. The OCG order is L2 broadcast, manual config, DHCP, DNS… it’s completely different in all 3 sources :smiley:

And the final question

After an AP has discovered, selected, and joined a controller, it must stay joined to that
controller to remain functional. Consider that a single controller might support as many as
1000 or even 6000 APs—enough to cover a very large building or an entire enterprise. If
something ever causes the controller to fail, a large number of APs will also fail. In the worst case, where a single controller carries the enterprise, the entire wireless network will become unavailable, which might be catastrophic.

Fortunately, a Cisco AP can discover multiple controllers—not just the one that it chooses
to join. If the joined controller becomes unavailable, the AP can simply select the next least- loaded controller and request to join it. That sounds simple, but it is not very deterministic. If a controller full of 1000 APs fails, all 1000 APs must detect the failure, discover other candidate controllers, and then select the least-loaded one to join. During that time, wireless clients can be left stranded with no connectivity. You might envision the controller failure as a commercial airline flight that has just been canceled; everyone who purchased a ticket suddenly joins a mad rush to find another flight out.

The most deterministic approach is to leverage the primary, secondary, and tertiary controller fields that every AP stores. If any of these fields are configured with a controller name or address, the AP knows which three controllers to try in sequence before resorting to a more generic search.

Technically, if the joined controller becomes unavailable, what exactly is the problem if the primary/sec/ter controllers aren’t configured? The APs still maintain a list of WLCs, up to 8 since the joined controller provides a list of WLCs in the same mobility group. So what’s wrong with just joining the least-loaded one? Or is the discovery processes reset for these controllers, or?

That’s all, thank you :slight_smile:
David