Showing results for 
Search instead for 
Did you mean: 

controller discovery process

I am consistently having a problem with APs landing on

the wrong controller after a number of them get rebooted due to building power testing.

I am wondering if anyone has any ideas on how I can make sure that these APs all associate to their primary or secondary controllers? Each AP has a primary and secondary configured for it. Yet, many will end up on some other controller across campus after a bunch go down.

Is there a way to increase the timeout so APs will keep trying their primary and secondary for infinity, rather than giving up and associating to the least loaded/congested?

Any tips are appreciated. This is a big pain for me to manage.


You have to understand the joining process. Option 43 works well initially, but if your ap's have already joined a WLC, it will have that information along with all other wlc's in that mobility group. If I use option 43 or DNS, I only use it for the initially discovery and then disable the feature. You really have to look at the traffic and see what the ap's are doing during a discovery and what is getting sent back or not...

*** Please rate helpful posts ***


I do understand the joining and discovery proces. The key thing is that if DHCP is configured to send the controller address, this adress becomes part of the built list upon LWAPP discovery. When after initial configuration this controller is also set as primary controller, it will select this.

In theory ideal for both deployment as daily operations. However, if the DHCP fails to send the controller, it will not becomne part of the list, so even if the LAP is configured to use the local one as primary, since DHCP does not send it it will not be selected.

That is the real issue I am facing, DHCP is simply not sending it, allthough I configured the DHCP servers following Cisco's doc to the T.

See my other thread for more details around my issue.



Content for Community-Ad