03-29-2018 04:55 AM - edited 07-05-2021 08:26 AM
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
Solved! Go to Solution.
03-29-2018 05:30 AM
Hi Jack,
I recommend some reading on the AP discovery process:
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:
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.
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.
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.
03-29-2018 05:30 AM
Hi Jack,
I recommend some reading on the AP discovery process:
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:
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.
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.
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.
03-29-2018 06:12 AM
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
03-29-2018 07:31 PM
04-03-2018 12:03 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide