controller discovery process

Unanswered Question
Feb 3rd, 2009

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
wesleyterry Tue, 02/03/2009 - 09:32

If you absolutely do not want them on the other controller, you could change the default mobility domain name of one of the controllers. Just make sure you update the mobility anchor values if you have anything anchored.

This will cause your AP's to stay within the two controllers and should never cross mobility domains unless it can not find either controller and the discovery process (DNS/DHCP/etc...) points it to the other controller in the other domain.

c.fuller Tue, 02/03/2009 - 09:39

Yes, that is one way, thank you. Thinking this through though I can't change the mobility group because I have guest tunneling configured for our guest wireless service. If I change the mobility group, then the guest tunneling will break. So I need to see if there is a way to do this with controllers in the same mobility group.

wesleyterry Tue, 02/03/2009 - 10:05

Hold up, guest tunneling shouldn't break with the mobility domain change. My DMZ controller (for guest anchor) is in a different mobility domain for this very reason you have above. I used to have AP's one my LAN controllers for some reason actually try to register to the DMZ Controller (but since ports were blocked, the AP never fully registered, but was stuck in some process that prevented it from failing back).

Anyhow.... You just have to configure the mobility domain correctly on each controller. So in Controller > Mobility Management > Mobility Groups make sure the MAC,IP, and correct Mobility Domain are defined for the controllers and it should work fine.

For example, my mobility group list looks similar to this:



XX:XX:XX:XX:XX:XX public


With this setup, my MESH Controller AP's don't go to other controllers, my Group1 AP's can be either controller and the public group is for the DMZ Controller which anchors the guests from all 3 LAN controllers...

Scott Fella Tue, 02/03/2009 - 10:41

Wesley is right about not breaking the mobility.... just make sure you verify your mobility groups and that mobility is up. One thing too is make sure that in each mobility group you have different VIP address.

c.fuller Tue, 02/03/2009 - 10:58

So controllers can be in different mobility groups/domains and still form EoIP and guest tunnels between each other? What about roaming capability? What if a client roams across mobility domains won't roaming fail since controllers are in different mobility domains? This seems to go against everything I have learned about mobility groups, roaming, tunneling, etc.

Scott Fella Tue, 02/03/2009 - 11:08

Yes... roaming will fail. If your buildings are all connected and you want seamless roaming, then you do need to keep the wlc's all in the same mobility group. Are you using dhcp option 43 or dns?

c.fuller Tue, 02/03/2009 - 11:17

I use udp port 12223 and ip helper-address on the routers to direct new APs to correct controller. All APs are rolled out now, so I don't have the config in place anymore.

This is a hospital and we have many connected buildings so seamless roaming is required.

So short of changing mobility groups is there a way to get APs to always associate to the same controllers? I am thinking there may be a timeout parameter (perhaps configurable) that when it expires APs look elsewhere for a controller. If that can be increased maybe APs will keep trying their configured primary/secondary controller until all are reassociated.

Scott Fella Tue, 02/03/2009 - 11:23

Well the issues is when you have power test and all the ap's go down.... Problem one is that if the wlc is busy joining ap's, some ap's will join the wrong wlc. You can always put all the wl'c in the same mobility group and enable ap fallback. This way eventually the ap's will go back to the confiugred primary and secondary. How is your setup by the way.... all ap's in one building go to 1-2 wlc's and the same with other buildings.... layer 2 between the buildings. Just trying to grasp how you have it setup.

c.fuller Tue, 02/03/2009 - 11:41

I do have all the WLCs in the same mobility group. AP fallback is not enabled because I decided it would be best to manually do it off-hours so APs were not bouncing all over the place during business hours. But I may have to reconsider that. I'll need to test the fallback feature and learn more about it's behavior. The good thing is most power hits on APs are off-hours.

For each building I have two controllers (ctrl-a/ctrl-b). The APs in the buidings are split evenly between these. Even floors have ctrl-a as primary/ctrl-b as secondary. Vice versa for odd floors. Between buildings is L3 IP connectivity. There are EoIP tunnels between all controllers to support roaming etc. Plus the guest tunnel between each local controller and the guest anchor controller.

The fallback feature may be something I look into now because this is becoming a pain in the butt. Facilities is constantly performing power testing.

Thanks for the information.


Scott Fella Tue, 02/03/2009 - 11:50


You should split the floors by not even and odd.... example... floors 1-4 wlc1, floors 5-8 wlc2. This way you can avoid intercontroller roaming especially if you pick up ap's from floors above or below. You can alway enable AP Fallback and disable it when you don't require it. Just create a template in WCS to enable and disable AP Fallback.

Leo Laohoo Tue, 02/03/2009 - 12:48

Q: Is there a way to get APs to always associate to the same controllers?

A: There are two ways: CLI or GUI (based on the firmware).

CLI on the WLC

config ap primary-base

GUI (If you are using v5.x and higher)

1. Wireless -> Access Points -> All AP's

2. Click on the AP you want

3. Click on High Availability Tab

4. Enter the primary and/or secondary IP Address and machine name of the WLC.

NOTE: If your WLC firmware is 3.x or 4.x, I recommend you use the CLI.

Does this information help?

c.fuller Tue, 02/03/2009 - 13:03

So if I do this are you saying that no matter what, even if a controller is overwhelmed with a bunch of APs trying to reassociate to it, an AP will only associate to the controller configured in above command? This will definitely keep an AP from associating to a random controller somewhere else in network?

Just want to make sure this is not the same thing as configuring the primary/secondary on the controller GUI once an AP first associates. My goal goes further and that is to elimate the AP from associating to random controllers under any circumstance.

Scott Fella Tue, 02/03/2009 - 13:08

You can give it a shot, but configuring the primary and secondary works the same as when you configure it in the GUI. I have done this in the past and still had ap's go to another wlc. The issue is that when they do a power test and shut down a lot of ap's at a given time is that the wlc reject the so from joining. Since the so knows of all wlc' in the mobility group, it will try each one until it gets a join response.

Leo Laohoo Tue, 02/03/2009 - 13:23

Hi fella5,

In the past, we've noticed that if your WLC is running the 3.x/4.x firmware and you configure the primary & secondary controllers via GUI, you will get the same result as NOT configuring it at all. Thus I recommend using the CLI. But with the newer (and more mature 5.x) firmware, the GUI will work just as well.

In my past experience, I've used the CLI very successfully (when running v4.x firmware) and the GUI (when running the 5.2 firmware). I guess it's a question of "whatever floats your boat". :)

There's also an additional CLI command on the 5.2 firmware that will be applicable to ALL the AP's associate to the WLC where you will use the CLI:

config advanced backup-controller primary

config advanced backup-controller secondary

Will this help?

Leo Laohoo Tue, 02/03/2009 - 13:28

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

laxcis Tue, 02/03/2009 - 13:43

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 Tue, 02/03/2009 - 14:02

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 Wed, 02/04/2009 - 07:06

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 Wed, 02/04/2009 - 07:22

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 Wed, 02/04/2009 - 07:51

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 Wed, 02/04/2009 - 08:58

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 Wed, 02/04/2009 - 07:56

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 Wed, 02/04/2009 - 19:30

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 Wed, 02/04/2009 - 12:42

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 Wed, 02/04/2009 - 18:22

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 Thu, 02/05/2009 - 12:46

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

Does this help?

l.mourits Fri, 02/06/2009 - 06:35

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.

l.mourits Mon, 02/09/2009 - 00:11

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.



Scott Fella Sun, 02/08/2009 - 17:58

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...

l.mourits Mon, 02/09/2009 - 00:08


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.




This Discussion



Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode