How to clear AP's candidate WLC list?

[derek_tracey]

Experts, does anyone know if there is a way to clear the candidate WLC list without using the factory defaults reset? I have found the list of "remembered" WLCs to be troublesome, and would like to clear the list if possible. 

[Ric Beeching]

Are you trying to delete all learned WLCs or the primary/secondary/tertiary settings?

On the AP itself you can logon and do the following commands but this will effectively return the AP to default so it might not be what you want.

debug capwap console cli
clear capwap private-config

Bear in mind that when an AP joins a WLC it will learn about other WLCs in the same mobility group so it doesn't matter if you cleared them now, it would re-learn those.

Hope that helps.. if not, outline specifically what you are trying to achieve and what setup you currently have.

Ric

[derek_tracey]

That command might, work. I will have to give it a try. 

Specificially, we "stage" APs on a local WLC to give it a name, label it, get the firmware downloaded, make sure it is not DOA, etc.. Then, we ship the AP to the final site location. Everything works great until it is time to perform a firmware update to the onsite WLC. At times, when updating the WLC firmware and rebooting the WLC, the APs will decide to join the WLC that was previously used to stage the APs. If you have a console cable connected to the AP while it boots, you can clearly see the staging WLC is in the "remembered" list of WLCs that the AP has ever connected too. Meanwhile, the upgraded WLC finshes its reboot, comes online, and now the site does not have any APs because they are connected to the staging WLC. Without manual intervention, it will take a few minutes before the APs rejoin the upgraded WLC. 

I would like to add some kind of "clearing" step to our staging process so that the AP will forget that it ever connected to our staging WLC. Staging the APs this way might not seem worth it, but when rolling out hundreds of APs, its efficient to pay a low-level guy to perform all these steps as well as dealing with the logistics of adding assets to our inventory system. 

[patoberli]

If you do this after the software upgrade (while staging it):
debug capwap console cli
clear capwap private-config
It will lose the name again and also the WLC. My suggestion is that you configure the correct WLC in the DHCP option 43 on each site, that way the AP will always find its correct WLC when booting, even if it's not staged.

[Peter Paulik]

Hi, we have the same problem. 
When we move the APs from site to site with different subnets the APs always remember the last joined WLC even if option 43 points it to the WLC on the site. The option 43 kicks in after the list of previously joined WLCs and if the AP has previously joined then the WLC the it will joined that one. The only way to move them from WLC to WLC is to prime them with primary/secondary/tertiary name/IP but again you have to change it when the APs are moved from site to site.
Any ideas how to get around this? Thank you.

[marce1000]

       @Peter Paulik >...The only way to move them from WLC to WLC is to prime them with primary/secondary/tertiary name/IP 
                                  That is incorrect DHCP option 43 is 'authoritative' ; however to make sure that the mechanism is in place
                                  check the used DHCP server's logs when the AP boots, look for the MAC address allocated , check the IP , 
                                  ping to the IP , connect to the IP and see that it is for the particular AP.
                                  Also check the complete output of the AP boot process (-> after a full reboot)

 M.

[marce1000]

 - @Peter Paulik Adding to my earlier remarks ; when the AP boots amongst all the other stuff you should then see
                         something like :
                         >...%CAPWAP-5-DHCP_OPTION_43: Controller address <ip-address-of-controller> obtained through DHCP

  If it's not there then the provisioning mechanism with option 43 'has not been correctly installed'

   Now there is one quirk you could be hit by ; if the APs are used in an N+1 high availability controller based environment 
   then the AP's may be redirected to the primary controller configured for it (when it has connected to the controller used in DHCP option 43!)

  M.

[Leo Laohoo]

If the AP runs on "classic" IOS, try the following: 

debug capwap console cli
clear capwap ap controller ip address