WLAN Controller Management

[jack.riley1]

Hello,

I am looking to change the IP address range used by the management interfaces of the 7 WLCs in the organisation. 

WLC1's Ip address currently responds to the CISCO-CAPWAP-CONTROLLER DNS Entry.

My questions are, when an access point communicates to CISCO-CAPWAP-CONTROLLER and the request makes its way to WLC1, what does WLC 1 then do with that request to send it on to the other controllers on the network, because not every access point is registered with WLC1. 

The second question is, if i changed the IP address of the interface that responds to CISCO-CAPWAP-CONTROLLER on WLC1, would this cause all my AP's to rediscover the controllers or would it only affect the APs connected to the controller that i am changing at the time and any new registrations until the DNS record is updated. 

Thanks in advance - Jack

[Ric Beeching · Accepted solution]

Hi Jack,

I recommend some reading on the AP discovery process:

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/70333-lap-registration.html

When your APs discover a WLC initially it may be through broadcast/DNS/DHCP (Option 43). If your WLCs are in mobility groups then the AP will also learn about those WLCs and note them for joining if your primary WLC goes down.

One way to control AP behavior is to manually set the primary/secondary/tertiary WLC so you know exactly which one it will prioritise. Via GUI this can be done on the AP under the High Availability tab. Alternatively this can also be set in the CLI or, even better, using a template within Cisco Prime Infrastructure if you have it.

Once an AP has discovered a WLC it will remember it for the next time it reloads and join that WLC again. If you changed your DNS entry, any APs that already know about your WLC(s) will still join it unless you wipe their config or change their High Availability to point at the new address. However, if you are changing the management interface of their known WLC, they will revert back to the original discovery methods as outlined below:

The LAP uses this information to make a controller selection, with use of these precedence rules:

1. If the LAP has previously been configured with a primary, secondary, and/or tertiary controller, the LAP examines the controller sysName field (from the LWAPP discovery responses) in an attempt to find the WLC that is configured as "primary". If the LAP finds a matching sysName for the primary controller, the LAP sends an LWAPP join request to that WLC. If the LAP cannot find its primary controller or if the LWAPP join fails, the LAP tries to match the secondary controller sysName to the LWAPP discovery responses. If the LAP finds a match, it then sends an LWAPP join to the secondary controller. If the secondary WLC cannot be found or the LWAPP join fails, the LAP repeats the process for its tertiary controller.

2. The LAP looks at the Master Controller flag field in the LWAPP discovery responses from the candidate WLCs if one of these items is true:

   • No primary, secondary, and/or tertiary controllers have been configured for an AP.

   • These controllers cannot be found in the candidate list.

   • The LWAPP joins to those controllers have failed.

   If a WLC is configured as a Master Controller, the LAP selects that WLC and sends it an LWAPP join request.

3. If the LAP cannot successfully join a WLC on the basis of the criteria in step 1 and step 2, the LAP attempts to join the WLC that has the greatest excess capacity.

[jack.riley1]

Hi Ric,

First of all, thank you very much for your reply. That was extremely helpful and answered pretty much all of my questions. 

The controllers are configure in mobility groups and the AP's aren't configured for primary/secondary/tertiary controller selection unfortunately. 

The only question i have remaining is how does the controller identify as a Primary? Is there a setting or a priority field that can be configured on the controller?

Currently the CISCO-CAPWAP-CONTROLLER entry points and one of the WLC's, so if that WLC is in a mobility group, will that WLC offload connections at a certain capacity or are there other methods of choosing which WLC in a mobility group will handle the next incoming join request to the primary controller?

Many thanks,

Jack

[Ric Beeching]

There is a small selection process but by assigning 1 WLC via DNS, the APs will join that one. Your APs won't automatically load balance between WLCs in the same mobility group. You can use the 'master controller' flag to set one as the primary at all times but this doesn't quite achieve what you want. If I had this scenario personally I would be setting a primary/secondary WLC per-AP as it is fairly easily 'scriptable' via the CLI for large amounts of APs. In that instance you'll know exactly where the APs should be and where they'll failover to.

Currently, only if the primary fails will they move over to one of the others in the group. The fail-over wording in that link outlines it quite well:

AP Fail-over Between Different Mobility Groups
Consider this scenario. Mobility group MG1 contains two controllers, C1 and C2. These controllers are deployed in one building, with LAPs load-balanced between the two. The branch office of the company deploys a third controller C3, and configures it for mobility group MG2.LAPs from that controller (C3) do not fail over to one of the other two controllers, but one day, when the Controller C3 reboots, the LAPs that were originally registered with C3 now register to C1 in mobility group MG1.

Now, even though the primary of the LAPs is C3, and there is no secondary or tertiary, the LAPs have joined C1; a reboot of the LAP does not bring it back to C3. What is the problem?

The reason behind this is that within the initial deployment, the company created one of two scenarios:

A DNS entry for "CISCO-CAPWAP-CONTROLLER.local-domain" or "CISCO-LWAPP-CONTROLLER.local-domain" to point to C1 or C2.

The addition of a DHCP option 43 to point to C1 or C2 to ease the initial installation. Once the installation of the first building was done, these entries were never removed.

[jack.riley1]

Hi Ric,

Thanks again for coming back to me. I have discussed applying DHCP options, but i think time constraints and future planning may prevent this at this time. However i agree that managing controller access using DHCP options is a good option long term. 

So as i see it, the only thing stopping all controllers registering to the cisco-capwap-controller WLC is that the APs retain their last known controller when they reboot, and because they have been transferred to other controllers in the past, they will go to those controller by design now. 

I think we should be ok re-ip addressing these in this case. Just need to ensure the change is reflected everywhere necessary, I.e prime, ISE, Anchors etc.

Once again Ric thank you for your input.

KR - Jack