cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1828
Views
0
Helpful
31
Replies

controller discovery process

c.fuller
Level 1
Level 1

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.

31 Replies 31

wesleyterry
Level 3
Level 3

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.

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.

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

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.

-Scott
*** Please rate helpful posts ***

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.

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?

-Scott
*** Please rate helpful posts ***

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.

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.

-Scott
*** Please rate helpful posts ***

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

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.

-Scott
*** Please rate helpful posts ***

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?

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.

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.

-Scott
*** Please rate helpful posts ***

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?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: