Ap wont join WLC due to SITE TAG

[Tob]

I have 2 WLC (standalone) 9800-40 which runs 17.3.5a. They are part of a mobility-group. I currently use the default ap-join profile with no config regarding CAPWAP/HA on either.

The AP which I'm having issues with is: AIR-CAP1702I-E-K9

When I try and move an AP from one WLC, lets call it WLC#2. I get this when the AP has a specific SITE-TAG attached:

[errmsg] [22877]: (note): %LOADBALANCE_TRACE_MESSAGE-5-LB_LOG_MSG: Loadbalancer Log : AP ( %AP-IP% ) : Loadbalancer algorithm assigned Instance (0) for site tag (%SITE-TAG%)

I'm unsure what this message is indicating but I found a syslog description for this particular output via a Cisco list and it states the following:

Facility-Severity-Mnemonic - LOADBALANCE_TRACE_MESSAGE-5-AP_SW_UPDATE_LOG_MSG

Severity-Meaning - 5-Notice

Message - Loadbalancer Log : %s

Message Explanation - Generic loadbalancer message

Component - ewlc-ap

Recommended Action  -

Ill attach the debug files, command(s) used to gather the logs:

AP radio MAC: debug wireless mac e4aa.5d6f.eb00 monitor-time 300
AP ethernet MAC: debug wireless mac 0462.73b3.e2cc monitor-time 300

We have setup DNS for the WLC discovery, incidentally this points to WLC#1 which the AP in question cannot join (with the specific SITE-TAG). The AP is also configure to use WLC#1 as primary WLC.

Another interesting point is that the AP in question doesn't show up in ap join statistics at all in the WLC#1 after failing to join.

I've tried to reset the AP to factory default where all tags are cleared, in which case the AP can join WLC#1.

In his instance the load balance msg is not present in debug output. However when configuring the AP with the correct name, which results in it using the SITE-TAG it is supposed to have (filter application of tags as per regex). After the AP reboots it cannot join WLC#1 again and registers with WLC#2 as per HA-config on the AP. Note that the join request for WLC#1 after reset of the AP doesn't look normal to me.

[marce1000]

 - 

-  Review the 9800-40  configuration with the CLI command : show  tech wireless , have the output analyzed by  https://cway.cisco.com/tools/WirelessAnalyzer/  , please note do not use classical show tech-support (short version) , use the command denoted in green for Wireless Analyzer

 M.

[Tob]

Thanks for the fast reply, I did this and got one error:

VRF: VRF have been configured, this is not a supported feature in 9800 controllers, and it will lead to severe functionality impact

Action: Disable the feature, use the command 'no vrf definition NAMEOFVRF'

I plan on removing this VRF in the future, its in use for a specific WLAN at the moment (I did not set this up, it was the prior contractor of the network who did).

Other than that I got several warnings of which this one might be interesting:

LAG: LAG was detected in use, and port channel load balancing is not set to src-dst-mixed-ip-port. Per best practices, please change both the controller and the switch for optimal port balancing

Action: Best practices recommend to use command port-channel load-balance src-dst-mixed-ip-port, for best port balancing. This must be configured as well on the switch side

I had a discussion with a colleague about this and we have a theory that its the mobility group in tandem with how wncd works on the platform which directs AP:s with the specific SITE-TAG to the WLC which hosts all the AP:s with that SITE-TAG. I intend on testing this theory next week if time is given.

[Rasika Nayanajith]

Do you have the same site tag configured for the AP in both WLCs? Ideally, you should have the same configured.

Then enable tag persistency using CLI "ap tag persistency enable". In that way even AP failover, it remembers the site-tag it belongs to. As long as both WLC got same site-tag configured, it should work.

Here is a post about how site tags are being used for distribution among WNCs available in WLCs

https://mrncciew.com/2022/06/30/9800-tags/ 

HTH

Rasika

*** Pls rate all useful responses ***

[Tob · Accepted solution]

There was no difference in the configuration of tags, but I did manage to find out what was happening. It was quite simple really, and not sure how I did not catch on to it sooner.

It was in the name field for primary/secondary controller where the error was made.

I configured something along these lines:

WLC01    x.x.x.x
WLC02    x.x.x.x

The hostname of wlc01 was not "WLC01", it was "WLC". When I removed the 01 from the name of the primary controller, it started working as I expected. I tried a few combination of names:

Does not work as per my expectation:
WLC01    x.x.x.x
WLC02    x.x.x.x

Does work as per my expectation:
wlc01      x.x.x.x
wlc02      x.x.x.x

Does work as per my expectation:
WLC        x.x.x.x
WLC02    x.x.x.x

I have not confirmed this via documentation but this tells me that if the name of a controller matches the hostname correctly it will take precedence regardless if the controller is specified as secondary, so long as the controller specified as primary has the incorrect name specified. If both primary/secondary controller names are incorrect it defaults to the IP field which then follows the order of: Primary > Secondary > Tertiary.

[marce1000]

 - Good to know , it is always useful after configuration changes to validate it again with the CLI command : show  tech wireless , have the output analyzed by  https://cway.cisco.com/tools/WirelessAnalyzer/  , please note do not use classical show tech-support (short version) , use the command denoted in green for Wireless Analyzer

 M.