topic Re: controller discovery process in Wireless

controller discovery process

c.fuller — Sun, 04 Jul 2021 00:06:00 GMT

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.

Re: controller discovery process

wesleyterry — Tue, 03 Feb 2009 17:32:38 GMT

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.

Re: controller discovery process

c.fuller — Tue, 03 Feb 2009 17:39:11 GMT

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.

Re: controller discovery process

wesleyterry — Tue, 03 Feb 2009 18:05:17 GMT

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 10.44.44.30 Group1

XX:XX:XX:XX:XX:XX 10.44.44.34 Mesh

XX:XX:XX:XX:XX:XX 192.168.5.30 public

XX:XX:XX:XX:XX:XX 10.44.44.36 Group1

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

Re: controller discovery process

Scott Fella — Tue, 03 Feb 2009 18:41:51 GMT

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.

Re: controller discovery process

c.fuller — Tue, 03 Feb 2009 18:58:02 GMT

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.

Re: controller discovery process

Scott Fella — Tue, 03 Feb 2009 19:08:12 GMT

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?

Re: controller discovery process

c.fuller — Tue, 03 Feb 2009 19:17:55 GMT

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.

Re: controller discovery process

Scott Fella — Tue, 03 Feb 2009 19:23:36 GMT

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.

Re: controller discovery process

c.fuller — Tue, 03 Feb 2009 19:41:00 GMT

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.

Chuck

Re: controller discovery process

Scott Fella — Tue, 03 Feb 2009 19:50:27 GMT

Chuck,

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.

Re: controller discovery process

Leo Laohoo — Tue, 03 Feb 2009 20:48:56 GMT

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?

Re: controller discovery process

c.fuller — Tue, 03 Feb 2009 21:03:13 GMT

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.

Re: controller discovery process

Scott Fella — Tue, 03 Feb 2009 21:08:43 GMT

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.

Re: controller discovery process

Leo Laohoo — Tue, 03 Feb 2009 21:23:12 GMT

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?

Re: controller discovery process

Leo Laohoo — Tue, 03 Feb 2009 21:28:10 GMT

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

Re: controller discovery process

laxcis — Tue, 03 Feb 2009 21:43:02 GMT

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.

Re: controller discovery process

Leo Laohoo — Tue, 03 Feb 2009 22:02:19 GMT

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

Re: controller discovery process

c.fuller — Wed, 04 Feb 2009 15:06:28 GMT

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.

Re: controller discovery process

laxcis — Wed, 04 Feb 2009 15:22:58 GMT

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