07-08-2022 08:26 AM
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.
Solved! Go to Solution.
09-29-2022 12:12 AM
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.
07-08-2022 10:27 AM
-
- Review the 9800-40 configuration with the CLI command : show tech wireless , have the output analyzed by https://cway.cisco.com/
M.
07-08-2022 10:36 AM - edited 07-08-2022 10:45 AM
Thanks for the fast reply, I did this and got one error:
07-08-2022 11:53 AM
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 ***
09-29-2022 12:12 AM
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.
09-29-2022 05:18 AM
- 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/
M.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide