Assigning APs to location

[eglinsky2012]

We're in the process of installing new 9166s that join our 9800 running 17.9.3. We're using the provisioning method where a CSV is uploaded to the location, so upon joining the WLC, the AP gets assigned the location and inherits the location's tags. We like this method because there is no interruption after the AP initially joins the WLC; everything is set immediately.

Now, I'm starting to move existing APs from our 8540 to our 9800. I used Prime to set the "Location" field in the AP prior to changing the primary controller in HA configuration to the 9800. The AP is now joined to the 9800, and it shows the right "Location" in its location field, but the WLC doesn't actually add it to the corresponding location or assign the tags. I made sure the "Location" is identical in the 9800 location and the location field in the AP settings.

Is there something I'm doing wrong, or might this be a bug in the 9800 controller? Is there a better way to accomplish both tasks (provisioning new APs and migrating existing ones)? I started looking at Prime, but it it's not getting the tags, locations, and filters from the WLCs automatically, so I think I'd have to add those all to Prime as well. We don't have DNA.

[Leo Laohoo]

We use the AP Filter method to assign tags to the APs.  

Regardless what version the WLC is, we have found a bug where the AP Filter process gets "blown" and stops to process.  This is how the bug works: 

1.  Get an AP with the wrong AP name and let it join the controller. 

2.  Rename the AP to the correct AP name and watch the controller not applying the tags. 

3.  Kick the APs off the controller "ap name <AP NAME> reset capwap" and when the AP returns to the controller, the AP will receive the tags.

[Tob]

Ap filter is a nice method indeed, but its not perfect. If you have a site which have different RF requirements for example you would have to design your naming-standard to include an exact location which complicates a whole bunch of stuff.

I use filter as a standard and location when there are deviations to standard configuration. Since I think that designing a naming-standard just to put configuration on a device is generally a bad idea, the name should only indicate what type of device it is a unique identifier, and perhaps a site-ID, this simplifies many things when you design for automation.

I don't however really like how location works, but its the best option I've got without designing some kind of API-based function I think.

You could also work with onboarding via DHCP (I think), but that puts how the AP is configured indirectly in the hands of DHCP, which I think is a generally bad idea.

For our purposes, having the configuration determined by the IP address would be a good solution.

A perfect solution for this is however hard to come up with since deviations from the standard puts us in a weird spot when it comes to automation. It would be really awesome if this could be done via API and match against a CMDB in which the configuration is determined. I've only got Prime to work with so that's out of the question I believe, but maybe this could be done properly in Cata-C?

[Leo Laohoo]

AP filter is nice indeed.  If it works 100% of the time.

What we've witnessed are two different scenarios: 

1.  If an AP reboots and joins the controller, AP Filter will work 100% of the time all the time. 
2.  If the AP is renamed in the same controller, AP Filter will stop working and I always have to kick the AP out of the controller to get the AP Filter to apply.

[Rich R]

Agreed AP filter is the overall best method but as Leo says sometimes it doesn't take effect until the AP re-joins so just be aware of that.  For me match on AP name works best because my site code is in the AP name so if your AP already has the correct name when it joins it will get the correct tags right away which will work perfectly for your migrating APs as long as they have the correct name set before you move them.
You can easily see what's applied with "sh ap tag summ"

[Rasika Nayanajith]

I think you have to configure AP ethernet mac-address on 9800 itself to assign those APs to particular tag location. If you configure an location on AP, it is for mgt (ex SNMP ) and not for tag assignment.

Device(config)# ap location name location1
Device(config-ap-location)# tag policy policy_tag
Device(config-ap-location)# tag rf rf_tag
Device(config-ap-location)# tag site site_tag
Device(config-ap-location)# ap-eth-mac 188b.9dbe.6eac

HTH
Rasika
*** Pls rate all useful responses ***

[Rich R]

I personally prefer to avoid using any method which requires adding individual AP MAC addresses to the config - it doesn't scale well and requires constant maintenance with moves/adds/deletes.
The advantage of using filters with regex match on name is that it's effectively automatic as long as the AP name is correct for matching the regex.

[eglinsky2012]

@Rasika Nayanajith- I see what you're saying. But what I've noticed is, once an AP is part of a location (provisioned by MAC address), the name of the AP location is added to the AP's "Location" field by the WLC. So, if that name gets put in the AP's location field just by the AP being in the location on the WLC, I assumed an AP that joined with a name in the location field that corresponds to a location defined in the WLC would get assigned to that location (and therefore get the right tags assigned), but it doesn't. I hope I'm explaining this clearly. Also, if locations aren't for assigning tags, why are the tags specified in the location?

@Rich R  - I agree, I don't want the MAC addresses in the locations for any longer then they have to be. At this point, I've thinking of using the MACs to get them in the location so the site tags are assigned, then deleting the MACs from the location. But when APs are removed from a location or from a filter, the CAPWAP tunnel resets. I also like the filter option, but it doesn't work for APs brand new out of the box. As @Leo Laohoo mentioned, if an AP is renamed after joining, it doesn't get filtered and the right tag assigned. Maybe I could just use the filter method, then schedule the APs to reboot after they're named so they get filtered.

Basically I'm trying to employ the location method to get new, unnamed APs, as well as existing named APs with a location already specified in the AP, in the right site tag as soon as they associate, to avoid a CAPWAP reset later on. I guess I can't have it all. Either it's easy or it's nondisruptive.

[Leo Laohoo]

---

@eglinsky2012 wrote:
 As @Leo Laohoo mentioned, if an AP is renamed after joining, it doesn't get filtered and the right tag assigned. Maybe I could just use the filter method, then schedule the APs to reboot after they're named so they get filtered.

---

Reboot the AP?  Why? 
If I manually kick out the AP, it will take 30 seconds for the AP to come back to the WLC and the tags would be applied correctly. 

If the AP gets rebooted, the AP is offline for, approximately, 4 minutes and 50 seconds.

[eglinsky2012]

@Leo LaohooFor simplicity. I can schedule a mass reboot of selected APs with Prime (we don't have DNA), but not a mass CAPWAP reset that I'm aware of. If there's a way to do that with Prime or with the WLC, I'm all ears.

For more context, we have 11,000 APs in 300 buildings across several sites. This summer, I'm migrating half of them off the 8540s to the 9800s. Of the ones that are migrating, some are existing 2800s, the rest are out-of-the-box, unconfigured 9166s that are replacing 2700s. So, we have two scenarios: already-named, already-configured APs joining, and brand-new, unconfigured APs joining.

For the new APs, we're preprovisioning them by location. That way we know which ones didn't come online, and they get the right site tag as soon as they join, no reboots or resets needed after. Alternatively, using the filter instead of location, I can get the APs installed during the day, name them, and schedule a reboot so they get the right tags. Or name the new APs ahead of time, so when they boot up after installation, they get filtered, but that's a lot more time we don't have the manpower for.

For migrating existing APs, the filter method seems fine. But if the location thing worked in reverse, I wouldn't have to use the filter and could go by location for new or migrated APs. Or I could add the APs to the location after they've joined (but again that would have to be done in mass and off hours).

I tested and if I remove an AP from the AP Provisioning tab of the location and do a CAPWAP reset on that AP, it stays in that location and keeps the same tags (tag source is still Location). I do have tag persistency enabled.

I'm just thinking out loud/summarizing what I'm doing and what think my options are, based off what I've experienced and learned here. Still open to ideas.

[Leo Laohoo]

---

@eglinsky2012 wrote:

@Leo LaohooFor simplicity. I can schedule a mass reboot of selected APs with Prime (we don't have DNA), but not a mass CAPWAP reset that I'm aware of. If there's a way to do that with Prime or with the WLC, I'm all ears.

---

Whao.  You're way over-thinking this.   There is even no guarantee that using PI (or DNAC) to reboot the APs is even going to work because PI/DNAC will have to know where the APs are joined.  And even this is a weakness of PI/DNAC.  

I moved about 3k APs from 8540 to 9800 and I only had an outage time of 4 minutes and 45 seconds and nothing more.  I did not use PI/DNAC nor any "automation" process.  All in all, I only had 4 APs that needed to be RMAed.  

[eglinsky2012]

---

@Leo Laohoo wrote:

---

Whao.  You're way over-thinking this.   There is even no guarantee that using PI (or DNAC) to reboot the APs is even going to work because PI/DNAC will have to know where the APs are joined.  And even this is a weakness of PI/DNAC.  

I moved about 3k APs from 8540 to 9800 and I only had an outage time of 4 minutes and 45 seconds and nothing more.  I did not use PI/DNAC nor any "automation" process.  All in all, I only had 4 APs that needed to be RMAed.  

---

I do tend to do that. My apologies. I'm glad it went so well for you with the filters. But I think you're missing my point, which I buried in a too-long reply. I'm dealing with unnamed APs joining. If an AP gets named after it's joined, the filter doesn't work, and the solution is to make the AP rejoin the controller, as you've said. How do you go about rejoining dozens/hundreds of APs at a time? That’s why I brought up rebooting the APs with Prime. Or do you do bounce every single one of them manually?

[Leo Laohoo]

The filters "not working" will depend entirely upon the uptime of the controller.  The longer the uptime, the higher the chances the filters have stopped working. 

Two things what can be done: 

If the 8540 can support these APs, get the un-nammed APs to the 8540 and rename them.  Once they are done, move them to the 9800.

If the 8540 do not support the APs, then let them go to the 9800 and rename them.  Use the command "sh ap tag summary | i default".  Any APs found in the output means the tags are not applied.  

For the APs that do not have tags applied to them, use the command "ap name <AP NAME> reset capwap".  The contoller will kick the APs out and should return in about 20 seconds and the filters should apply the tags automatically.

[Rich R]

That's pretty much exactly what we do - name the AP, then do capwap reset.  You can use Excel with the list of AP names to easily make yourself a list of reset commands for hundreds of APs and paste in to CLI.

[eglinsky2012]

Thanks, Leo. Is there a bug ID for this? Or do you have a case number I could reference and open my own case?