WLC4404s with AP1231 APs assigning to a new controller

[drees]

I have two WLC4404-100 controllers where I just installed the secondary unit. I have edited certain APs to make the primary controller be this new unit and the current controller to be the secondary. These APs do not move unless I reset them. These APs are mostly 1220's which have had IOS upgrades and G-Radio upgrades to make them 1231G units and some factory 1231G units. I have had other installations where the AP1000 series (Airespace 1200/1250 series) APs will move fairly quickly after you apply the change. We have about 50 APs that need moved to this new controller but would prefer to see them move on their own rather than rebooting them.

Has anyone seen this type of behavior? It seems like I'm blazing a new path with this installation as we are having authentication problems tied to roaming and reauth.

[mchin345]

This document is written assuming that you have already determined the 802.11 topology. Because the Radio Resource Management (RRM) feature automatically detects and configures the access points as they appear on the network, it is not necessary to have any access points on the network to install and configure a controller.

The controller is 17.5 in. wide x 15.75 in. deep x 1.75 in. high (443 x 400 x 44.5 mm). The chassis can be rack or shelf mounted. Controller Models

The controller comes in 2 variants4402 and 4404.

http://www.cisco.com/en/US/products/ps6366/products_quick_start_chapter09186a008056add1.html

[mnordhoff]

Not sure about your AP movement issue but it clearly seems to be related to the "upgraded" legacy APs.

I've experienced similar problems with disassociations and roaming clients and the problem was exacerbated by the controller frequently disassociating clients because of Mobile Age Timeouts. The workaround turned out to be to enable LAG on the controller. Without LAG the controller ignored the RF traffic for purposes of determining the ARP timeout. When the ARP timeout continually expired it would disassociate the client which would then often make a poor roaming decision. With LAG enabled the controller never timed out the session because it saw the frequent RF probes from the client. Maybe this will help.