Revalidate Tag Source on APs

[Charlie Grey]

what is the purpose to revalidate Tag Source on AP??

i am confused.

i always thought an AP joining a controller will follow the priority order set on the controller?

U mean there is priority order on the AP also?

like tat if the controller and the AP order are different, which one will take precedence? 

[Haydn Andrews]

If you change the TAG prorities this tick box will re-run against APs already assigned tags to update to the new order if ticked when hitting apply

https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/config-guide/newconfigmodel/b_catalyst-9800-configuration-model/m_configuring-tags.html

When you change the priority for the AP and filter, run the ap tag-sources revalidate command to evaluate the priority.

[Charlie Grey]

sorry, i read that from cisco doc also, but did not answer my Question.

so you revalidate the priority to all the AP on controller A.

when AP from controller A join controller B, the tag source order on AP is different, what will happen? 

[Haydn Andrews]

You should set them the same on both WLCs. If you dont then it will revert to the tag order on that WLC.

Post APs joining you can use tag persistent to have the AP keep the tags assigned.
This pority order is mainly used if your doing dynamic tags like if AP name contains value assign this

[Charlie Grey]

i was moving a 2800 AP from C9800 controller A (write tag to AP done) to controller B.

Both controller tag source priority >> 3-AP 4-Filter.

controller A tags are not defined on controller B.

by behavoir, since controller B got no controller A tags defined, tag source priority 3-AP will failed.

i expect the AP to take up tag source priority 4-Fitler using the AP hostname which i already define the tags to be assigned on controller B which it nv happend.

the AP end up getting all the default tags which i am v confused. 

so the tag source priority defined on controller B don't work which i do not know the reason why?!

[Rich R]

What version of IOS-XE are you running on?

Check out https://www.cisco.com/c/en/us/products/collateral/wireless/catalyst-9800-series-wireless-controllers/guide-c07-743627.html#CiscoCatalyst9800Seriesprofileandtagconsiderations

Make sure your software is up to date as per TAC recommended link below.

Use "show ap tag summ" to understand the tag assigment.  Note that filter should normally be higher priority than AP unless you've changed priorities.  Are you sure your filter is active?  If you didn't set a filter priority then the filter is just a zombie.
"show ap filters active" and "show ap filters all"

[Charlie Grey]

i was moving a 2800 AP from C9800 controller A (write tag to AP done) to controller B.

controller A - 17.3.6

controller B - 17.9.4a

i purposely change the tag source "AP" higher priority than "filter" on the controller becos i wanted the failover AP to retain their saved tags rather then to take over the tags assigned on the target controller.

i tested the filter is working becos a fresh out of the box AP is able to get the predefined tags configured on the controller after configure the AP hostname.

So... if the same tags are not defined on the target controller, as accord to the tag source priority order, the failover AP should  be assign the Filter which is not happening. instead, the wireless AP got all the default tags.

i hope you understand what i am talking abt. 

[Rich R]

> controller A - 17.3.6, controller B - 17.9.4a
That straight away is a recipe for trouble!  17.3.6 is almost end of life.  Forcing APs to switch between 17.3.6 and 17.9.4a means they're going to have to switch between code versions (and download if they don't have 17.9.4a already)!

> i wanted the failover AP to retain their saved tags rather then to take over the tags assigned on the target controller.
> if the same tags are not defined on the target controller, as accord to the tag source priority order, the failover AP should  be assign the Filter which is not happening
Those 2 statements contradict each other don't they?  First you're saying you want it to keep and use WLC A tags.  Then you're saying you want it to use WLC B filter tags! So why not leave the default tag priorities to do exactly that?

I don't think it works as a fallback mechanism like you expect it to.  I think by changing AP to higher priority it will keep the AP tags (as you've told it to) and report the AP as MISCONFIGURED (in show ap tag summ) and will simply use default tags because the selected AP tags are unknown.
If you want to be sure what's happening enable radioactive trace for the AP MAC address before it moves and then check the trace logs after it's joined.  Also check the logs on the AP itself.

I suggest if you're going to use N+1 WLCs like this reliably:
1. The WLCs must run the exact same software version
2. They must have the same tag configuration.
3. 17.3 is past the "use by" date and getting smelly - update as per the TAC recommended link below so both WLCs are on 17.9.4a with APSP8.

[JPavonM]

AP Tag persistency was introduced in 17.6.1, so if you are not manually saving tags to APs on WLC A running 17.3.6, then APs are not going to carry the tags to WLC B with them, so there they will receive the static config assigned (if any), the filter ones, or the default.

Best if you standardise the IOS-XE code to TAC recommended 17.9.4a with APSP8 (or next to be recommended 17.9.5), set tag persistency in both WLCs, and this way you don't need to create static AP config in WLC B as APs will carry the tags with them by default, and you would have to configure the profiles and tag definitions only.

[Charlie Grey]

2 Q still unanswered in my mind.

1/ so, the priority order on the wlc doesnt fallback to the next one?? eg if "AP" assign fail, it will go to the "Filter" before assigning all the default tags to the wireless AP???

2/ what is the reasons/ scenario/ benefits to move the AP above Filter in priority order?? 

thanks u for all your time.

[Rich R · Accepted solution]

I answered 1/ before: "I don't think it works as a fallback mechanism like you expect it to.  I think by changing AP to higher priority it will keep the AP tags (as you've told it to) and report the AP as MISCONFIGURED (in show ap tag summ) and will simply use default tags because the selected AP tags are unknown.
If you want to be sure what's happening enable radioactive trace for the AP MAC address before it moves and then check the trace logs after it's joined.  Also check the logs on the AP itself."

2/ If you wanted to use a static override for a single AP while using regex to apply to all others.   But the AP assigned tags would still have to exist on the WLC.  If they don't exist it won't revert to filter - it will just treat it as misconfigured and use defaults.  There's no "if the tags I have forced it to use don't exist then go to the next possibility" logic.  The logic is "I have forced it to use these tags, which don't exist, therefore the AP is misconfigured, use defaults as last resort"