controller discovery process

[c.fuller]

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.

[Leo Laohoo]

Forgot to ask you a very silly question: What is the model of your WLC and how many AP's (max) are licensed?

[laxcis]

I am having the exact same problem. Have a case open with Cisco but not recieving much back for response (610557505). I have two AP's that are jumping onto the wrong WLC. I have a 4400 WLC and the AP's are 1242's. It sounds like I just need to do the command on the WLC that you posted earlier.

[Leo Laohoo]

Forgot to ask you a very silly question: What is the model of your WLC and how many AP's (max) are licensed?

[c.fuller]

I am using 4404 WLCs and 1000 Series APs.

I have 16 WLCs, in 8 groups of two serving each building. 560 total 1000 series APs. I don't exceed 100 APs in any controller group/bldg. So I have full redundancy.

I have always configured primary/secondary controller via the GUI and have had pretty good success (98+%) with having APs when rebooted associate back to the primary or secondary.

The problem is when a bunch are rebooted at the same time. When that happens APs end up all over my network (across my entire mobility group) and I have to track them down and manually reboot to get them back to primary. This is what I am trying to specifically alleviate/address.

So far it sounds like AP Fallback may be the best method to address this. This may eliminate the need to manually track them down and reboot.

[laxcis]

Don't mean to highjack the thread, but figured this might help others in here too. I ran the config you mentioned, but the AP's are still going back to the wrong WLC. I had to run the config on the WLC that I don't want the AP's to connect to since that is where they are associated to now. Also, in the config you mentioned, it wouldn't allow me to do the WLC IP Address in the command. Said it was an invalid command. Taking that part out, the command then worked, yet the AP's are still connecting to the wrong WLC.

config ap primary-base

[wesleyterry]

The WLC-IP-Address part of the command is only available in 5.x. Or well I don't think it is available in 4.x... I'm not really sure when that feature got added.

[laxcis]

4.1 seems to take this command, it just didn't do anything for my AP's and finding the right controller..

config ap primary-base

[c.fuller]

So here is my experience with 4404s and 1000 series APs. This has been the same with 3.x, 4.1 and 4.2 WLC code.

When I add an AP to the network and it first associates to a 4404 controller I configure primary/secondary via the GUI.

If the AP is rebooted alone (or even with a handful of others) it almost always reassociates to it's primary. I've never used CLI commands to configure primary/secondary and achieve this functionality.

So are you saying you have configured via the GUI and still can't get the APs to reassociate to the correct controller?

I would try to factory default the APs, use option "43" or whatever other means you use for initial controller discovery

to get the AP back on it's primary. Then I would reconfigure primary/secondary via GUI. See if that helps.

[Leo Laohoo]

What I've seen, in my past experience with the 4.1/4.2, is after I've configured the primary/secondary name/IP Address via the GUI, and I check if this is reflected on the AP via the CLI, I always see that the primary/secondary name is configured and never the IP Address. Even after a reset the AP's still would be joined to the wrong controller. Wierd!

Raised a TAC Case and they didn't know what's going on. I decided to use the CLI and presto! problem fixed. From that time on, whenever I deploy new AP's across the network I use the CLI to configure the primary/secondary controllers.

[Leo Laohoo]

Ok, that's odd because the first time I've stumbled onto this command, the WLC was on the 4.0.x firmware.

[Scott Fella]

Well if your ap's in one building are on a different subnet than other buldings, why not block udp 12222 & 12223 from AP subnet to the other WLC's... this way they will never join. Just a thought.

[Leo Laohoo]

Another method is to configure DHCP Option 43 (In order to facilitate AP discovery of WLAN controllers that use DHCP Option 43, the DHCP server must be programmed in order to return one or more WLAN controller management interface IP addresses based on the VCI of the AP. In order to do this, program the DHCP server in order to recognize the VCI for each access point type, and then define the vendor specific information).

DHCP OPTION 43 for Lightweight Cisco Aironet Access Points Configuration Example

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00808714fe.shtml#backinfo

Does this help?

[l.mourits]

Mmmh, funny, that is what I am trying to use (we have different controllers in different countries, some with local controllers, some H-REAP, sometimes different models of access-points in the same site.

Based on Cisco's design guide, best practive for such environment is the use of option 43 with option 60 vendor class mapping, and they referring to this doc.

Well, all I can say is I am troubleshooting for days now, and about to open a case to ask them if they can verify their documentation on how to set up the Microsoft DHCP server with vendor classes is correct. Cuase all I can see is that with following the doc to the T the LAP is not receiving the controller address via DHCP whatsoever.

[Leo Laohoo]

Try the command line first before contacting TAC.

[l.mourits]

The command line works fine, but in an international environment I would like to be able to simply drop ship LAPs to each site, so that someone without any IT knowledge can connect it, and I can remotely configure it.

Entering the controller list via the command line would result in me having to order everything, touch it, then ship it again.

Thanks,

Leo