cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6217
Views
5
Helpful
7
Replies

AP discovery process WLC vs Catalyst 9800

Martin Jelinek
Level 1
Level 1

Dear all,

 

What are you using for an APs to discover their controllers? I suppose quite often is being used DNS based discovery CISCO-CAPWAP-CONTROLLER.localdomain.

 

However how you deal with fact if you have two separate wireless controller environment running in parallel?

Older APs are managed by WLC controllers while new APs would be managed by Catalyst 9800 controllers.

 

Is there any recommended way how to force AP to join the right controllers? Nice would be that new AP models will support second DNS entry which would match Catalyst controllers, but doubt this is something in place.

 

1. We can use DHCP option, but then it means for each and every AP model we need to define exactly what controller AP should associate with. And managing DHCP options for thousand of locations is not an easy. Also might be that each location will have to have all APs supported by Catalyst controller so no mixed environment is in place to prevent roaming issues etc.

 

2. We can just keep DNS discovery in place, always point to WLC environment and once AP joins, to manually distribute (configure controller IP manually) it to correct controller whether it would be WLC or Catalyst one. Then config is stored in NVRAM and after reload it joins the correct/intended controller.

 

Any other thoughts or you already deal with?

 

Thanks

/Martinwlc

 

1 Accepted Solution

Accepted Solutions


@Martin Jelinek wrote:

Problem is that we have houndreds of APs which are NOT supported by C9800


This is not difficult to "sort": 

So with DHCP Option 43, configure two WLC:  first is the 9800 and the 2nd is the old controller. 

This is how it goes: 

1.  NEW model AP boots up;

2.  NEW model AP gets an IP address; 

3.  NEW model AP gets presented with the IP details of 9800 and the old controller; and 

4.  NEW model AP picks the FIRST WLC. 

 

OLD AP goes like this: 

1.  OLD model AP boots up; 

2.  OLD model AP gets an IP address; 

3.  OLD model AP gets presented with the IP details of 9800 and the old controller; and 

4.  OLD model AP cannot join the 9800 so it joins the old controller.

View solution in original post

7 Replies 7

Leo Laohoo
Hall of Fame
Hall of Fame
DHCP Option 43

jturner2720
Level 1
Level 1

We have multiple clusters of WLCs discovered by DNS. Different locations will have different localdomains in their DHCP options, so we just alias the cisco-capwap record to the appropriate cluster for that domain.

Does mean you can only have one cluster per location, but as you say you wouldn't want to split it or the roaming gets nasty.

 

Kind of, yes.

Plan is to migrate from WLC to C9800 series, which means bring new controllers into existing data centers/location/region.

 

Problem is that we have houndreds of APs which are NOT supported by C9800 (sad to say, just Cisco has not covered support for also older series of APs like 1600,2600,3600 series which have valid EoL till 12/2021 :-( ). Therefore we need to run wireless controllers in parallel together it means WLC and C9800 eventually for some time. 

 

And I'm trying to figure out that best possible way how to achieve that without big overhead from operation point of view to migrate all the time over and over AP from A to B to join correct controllers.

Of course noted DHCP option is a valid point, just with amount of DHCP servers to configure/maintain it is not something one would want to do :-)

 

Thanks

Martin

 


@Martin Jelinek wrote:

Problem is that we have houndreds of APs which are NOT supported by C9800


This is not difficult to "sort": 

So with DHCP Option 43, configure two WLC:  first is the 9800 and the 2nd is the old controller. 

This is how it goes: 

1.  NEW model AP boots up;

2.  NEW model AP gets an IP address; 

3.  NEW model AP gets presented with the IP details of 9800 and the old controller; and 

4.  NEW model AP picks the FIRST WLC. 

 

OLD AP goes like this: 

1.  OLD model AP boots up; 

2.  OLD model AP gets an IP address; 

3.  OLD model AP gets presented with the IP details of 9800 and the old controller; and 

4.  OLD model AP cannot join the 9800 so it joins the old controller.

It seems there is no better way that to utilize DHCP option....

 

I've hoped there is something more I wasn't able to think of.

 

Thank you :-)

 

Martin

I know this is quite an old thread but if you had a central DHCP / DDI (DHCP, DNS, IPAM) solution, you could adjust each local segment's local DHCP Option 43 as you migrate them over. Example, you're upgrading Site A this weekend to new AP's, just move that location's DHCP option to new controller and replace AP's. Site B and C wouldn't have to know of the change.  There a lot of assumptions in this scenario but just an idea for anyone who's still curious about this.


@Minnesotakid wrote:

I know this is quite an old thread but if you had a central DHCP / DDI (DHCP, DNS, IPAM) solution, you could adjust each local segment's local DHCP Option 43 as you migrate them over. Example, you're upgrading Site A this weekend to new AP's, just move that location's DHCP option to new controller and replace AP's. Site B and C wouldn't have to know of the change.  There a lot of assumptions in this scenario but just an idea for anyone who's still curious about this.


There is another way of doing this and it going "old skool" using a WLC primarily for "staging" purposes. 

Put the AP and the WLC in VLAN and the AP will not need DHCP Option 43 to join the staging WLC.  Once the AP joins this controller, it will upgrade the AP firmware.  After the AP returns with the correct firmware configure each individual AP with the primary/secondary/tertiary controller details.  
This method could be done by hand, by GUI/CLI or can be done using customized script.  We have been using customized script (way before PI, APIC-EM, and DNAC had theirs) for 10 years now.  Our script looks at the serial number of the AP and compares the entry to an SQL DB.  The script then configures the AP name, Location, AP Group (without the need to reboot the AP) and throws it to the correct WLC.  

In "advanced mode", we can bulk configure APs a lot of the other settings like channels and power each radio must on, etc.  

The script runs every 20 minutes and we can bring the timer down to 60 seconds.  It does not matter if we configure one or 1000 APs.  It works.  And yes, we used it to bulk configure 750 APs multiple times.  

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: