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]

Even though we have valid contracts to raise TAC Cases, I have not raised one because I have no time to play games with TAC.  

(Read between the lines.)

[Rich R]

Me neither - it's difficult enough to get TAC working on the serious bugs these days - we just don't have the time to spend on a relatively minor one like this.  But you're welcome to do it if you see the problem @eglinsky2012 ...

[eglinsky2012]

We ended up using filters. The latest complication is that I had tag persistency enabled, so after clearing out the locations and adding filters, even after APs rejoin, the filters don't get applied; the tag source stays "AP". I've found that clearing the resolved tag config and then rejoining will then get the APs filtered.

Does anyone know of a way to clear the resolved tag config in mass? Would disabling tag persistency and/or revalidating tag sources on APs work? I haven't tried these options yet due to service disruption of many APs rejoining.

[Rich R]

That's not right - the filter should replace the existing tags!
https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/config-guide/newconfigmodel/b_catalyst-9800-configuration-model/m_considerations-when-configuring-tags-and-profiles.html
Filter has higher priority than AP known (persisted) tags.
The only thing with higher priority is static (AP/location) config - are you sure you didn't still have some of that left in the WLC config?

[eglinsky2012]

Apparently, that's not the case, unless there's a bug. See three APs with the same filtering scheme. The Regex on the filter is ITE-*. Two APs are filtered, one is not - and, the one that's not filtered has the least uptime!

I just tried to double check the clear tag/rejoin routine, and that AP is still filtered at the AP level. It's still at AP even after rebooting.

I think I found part of the issue, however. The AP priority is above the filter priority.

I must have changed that at some point for testing and forgot to change it back. But, shouldn't clearing the resolved tag config make it so there is no AP config and the filter gets applied?

This is 17.9.4 code for what it's worth.

[Leo Laohoo]

I do not have tag persistency enabled so I have never seen this behaviour in 17.9.3. 

After some delay, I just started testing 17.9.4 twelve hours ago.  

[Rich R]

Yes you must have changed the priorities so that explains what you saw.  AP tags should be last resort - lowest priority. Here's how my 17.9.4 without any changes looks:

Agreed - clearing resolved tag config and forcing the AP to re-join should cause the filter to be applied.  Don't forget to re-arrange your tag priorities.

What I'd like is a CLI command to clear that resolved tag config - anybody know that?