Showing results for 
Search instead for 
Did you mean: 

Cisco Wi-Fi - Prevent AP from joining wrong WLC (5508 - 9800-CL)


We have been running a cluster of Cisco 5508 WLCs for many years, and the way that the APs has discovered the WLC is via DNS (

A while back we installed several 9800-CL WLCs, and we found that the best way to add new APs, and (slowly) migrate compatible APs to the new WLC, was to use DHCP Option 43 (for specific VLANs) to direct the APs to the new WLC.

So, currently we are living in a mixed Wi-Fi enviroment.


The problem is, that on the new 9800 WLC we have APs that we want to keep on the new WLC, but are still compatible with the 5508 WLCs. If a situation occurs that makes the APs loose connection to the WLC (reboot, upgrade etc...) they will go to the 5508 WLC since the APs will fail on DHCP Option 43 and fall back to DNS resolution.

Forcing them to be downgraded, which can be a lengthy process. And when we move them back to the 9800 WLC, where are are once again upgraded - which is a lengthy process.


Is there a way to prevent APs, that we want to "lock" to the 9800 WLC, from joining the 5508 WLC?

Leo Laohoo
VIP Community Legend

@kenneth.gregersen wrote:

Is there a way to prevent APs, that we want to "lock" to the 9800 WLC, from joining the 5508 WLC?

Manually configure the Primary WLC/Secondary WLC details.

Jurgens Lombard

As Leo mentioned the best way to do this is assigning the WLC's and their IP's under the high availability options of the AP. The reason for is due to the election process the AP uses to discover WLC's where the static configuration will override DNS or DHCP option 43 if WLC's are available. Reference below explains in greater detail.


Thanks @Leo Laohoo and @Jurgens Lombard 


I was aware of this possibilty, but I was under the impression that the AP would still ignore the configured IP address of intended WLCs in the NVRAM of the APs if the configured WLC was unavailable. Meaning that it would just fall back to either DHCP Option 43 and DNS resolution.

But, if I understand you correctly the AP will only use configured WLC(s)  - and not move on to other methods of discovering the WLC?


@kenneth.gregersen wrote:

I was aware of this possibilty, but I was under the impression that the AP would still ignore the configured IP address of intended WLCs in the NVRAM of the APs if the configured WLC was unavailable.

This uses the Parent-and-Child system:

  • Global configuration is followed if no configuration is present on the AP.
  • If AP-specific configuration is present then this will overrule the global command.  

Thanks @Leo Laohoo for the clarification.

I have one more question about setting the configuration per AP.

In the 9800 WLC there is something called an AP Join Profile.

In the CAPWAP settings one can specify Primary Controller and Secondary Controller, but it doesn't look like this is related to the High Availability setting - that is set per individual AP.

Or am I misunderstanding?




- AP can fallback to other options if unable to find configured primary/secondary

- The global settings should apply to all APs which don't have their own static config applied (if it's like AireOS but I have not checked the docs).

Typically you just want to assign tags as that will have the primary and secondary. This is sort of the same as aireos, but I believe they wanted it to be simple in ios-xe. If you want to define on each access point, then you can do that by configuration on each ap in the Configure > Access Point and choosing the AP or by the cli:

9800HA#ap name test controller primary test
*** Please rate helpful posts ***

Thanks again for all input.

To summarize; it's possible to direct an AP to a specific WLC (as the preferred choice) - but if there exists alternate methods in the network to discover other WLC(s) (DNS/DHCP Option 43) the AP will use it if preferred WLC is unavailable.

Meaning, there is no way (in our current network setup) to prevent the AP from joining the "wrong" WLC if preferred WLC is down.

Look at it this way. You have methods of an ap discovering the controller which everyone mentioned. So if you have for example one of the methods in which the ap can join the wrong controller, then that is where your issues lies. If you want to not allow an ap to join, you would use Mac filter and enter the MAC address of the AP’s.

When you are designing for a migration or brining up a new controller, the first thing you should of looked at was to place the new controllers on a w subnet in which your existing ap can’t discover and join. This is the same for the new environment.
*** Please rate helpful posts ***
Content for Community-Ad