For some reason all of the APs on a particular controller deregister from it and register with their secondary controller. Both controllers are running version 18.104.22.168 and I cannot see any issues on the LAN that would disrupt comms between the APs and their primary controller.
Any pointers will be greatly appreciated.
Have you tried one of the following:
turn off the secondary WLC for a bit, and then turn it back on and then see where the APs register
reset the APs to factory default and then set the 1st & 2nd controllers
Have you pre-staged the APs?
Are you using ip addresses or names for 1st, 2nd & 3rd controllers?
I haven't tried either of those but I will do as soon as.
I'm using names for the first and second controllers (I'm haven't spec'd a third due to the controllers being geographically distant).
These particular APs had been quite stable until I upgraded the controllers to said s/w version around a month ago, though APs on other upgraded controllers are fine. Also no matter where the APs are registered to they report (via WCS) that they are running vers 22.214.171.124 s/w, however interrogating the relevant controller directly says they are running vers 126.96.36.199.
I was also in the midst of adding some new APs; these were autonomous ones that I converted (at my desk) and specified the suspect controller for them to register with during the conversion, the new APs registered ok with the controller and I set the same controller as their primary and set them aside for installation. After your reply to my initial query I've booted one of the newly converted ones again and they have registered with a random controller elsewhere on our network (I'm using option 43) rather than their primary.
Apologies for the info overload, hopefully you can make some sense out of it.
From WCS| configure controllers, select the controllers & do a refresh from network. Does WCS still show them as 188.8.131.52?
I had this same issue. I had 20 APs as 184.108.40.206 and 72 at 220.127.116.11 which is what the controllers are on. I ran an ap inventory report from WCS & sure enough, all 20 APs that were running 18.104.22.168 were bound to the same controller. A quick bounce of the controller took care of it. I went into WCS, ran the report again and all APs were at the current level. Must have not rebooted the controller after the upgrade.
Regarding the issue of the AP not going to the primary... perhaps the suspect controller is running in master mode; a no-no for a wireless network that is in production
Perhaps I should just upgrade to 22.214.171.124 and see if that resolves the problems.
Also, for the access points that have been upgraded from from Autonomous to LWAP, you may want to make sure that the security certificates/hashes are in each of the controllers that will be managing the LWAPs.
Actually, I've had no problems with the converted APs (touch wood), however, I have tried loading the csv files produced by the upgrade tool into WCS and WCS says they are empty, opening them with Excel confirms it.
Yes - I've downloaded 126.96.36.199 from Cisco - I'll try it on the misbehaving controller and post the result.
What changes are in 4.1.185. I did not find any link for 4.1.185 release notes, 4.1.181 is the latest rel notes available.
I've had similar problems on my blade. It seemed that the primary controller lost it's setting under Master Controller mode. This would happen seemingly random, though often during upgrades.
Reenabling the setting fixed the problem.
If I remember correctly I found a case of this somewhere on the cisco pages.