06-29-2024 08:02 AM
Hi
We're running a Cisco 9800-CL (17.12.3), and we offer a guest Wi-Fi.
We're using the built-in "guest system" and captive portal.
This is working as expected.
During planned maintenance the WLC did a failover from active to standby unit.
After the failover, the captive portal no longer shows up for the guest user.
I had to do a "redundancy force-failover" to promote the standby unit to active to get it back online.
Any explanation why the captive portal doesn't kick in when we're running of the standby WLC?
Solved! Go to Solution.
07-05-2024 05:06 AM
I wanted to provide an update on the recent captive portal issue.
I added the "wireless mobility MAC address" to the WLC cluster and performed a redundancy force-switchover. Following this, the user was able to access the captive portal, which suggested that the issue had been resolved.
To verify the solution, I removed the wireless mobility MAC address and repeated the entire procedure. Surprisingly, the captive portal continued to function correctly even without the "wireless mobility MAC address" configured.
While the exact cause of the issue remains unclear, I will keep the wireless mobility MAC address configured as a precautionary measure.
06-29-2024 08:52 AM
>...After the failover, the captive portal no longer shows up for the guest user.
I had to do a "redundancy force-failover" to promote the standby unit to active to get it back online.
That's a little bit contradictory , without actions -> was the former standby able to play the role as active
completely without interventions (initially)?
Or else : if "redundancy force-failover" was not used initially how was that particular failover realized then ?
M.
06-29-2024 11:58 PM
Maybe I explained it poorly.
Initial setup - Captive portal working:
WLC-A - ACTIVE
WLC-B - STANDBY
Maintenance in data center caused an automatic fail-over, and a non-working captive portal situation:
WLC-A - STANDBY
WLC-B - ACTIVE
To get the captive portal back online, I did "redundancy force-failover":
WLC-A - ACTIVE
WLC-B - STANDBY
06-30-2024 12:12 AM
- Ok , for starters have a checkup of the primary controller's configuration (WLC-A) with the CLI command
show tech wireless and feed the output from that into Wireless Config Analyzer
Review all advisories , in all tabs in the Excell , red errors in Wlc-checkresults should always be corrected.
In the problem situation you may use https://logadvisor.cisco.com/logadvisor/wireless/9800/9800CWA
for analysis , if time permits in such a situation...
M.
06-30-2024 12:34 AM
Is this Wireless Config Analyzer even working anymore?
I have tried using multiple browser to upload this file.
Says loading for some time, and then nothing is happening.
06-30-2024 01:51 AM
>...Is this Wireless Config Analyzer even working anymore?
- This might be a common mistake ; note that the Config Analyzer needs the input from :
show tech wireless
neither show tech or show tech-support ,
M.
06-30-2024 02:57 AM
It turned out I was uploading the incorrect file.
The only related message that appears is a WARNING (not error):
High Availability: Redundancy mac address is not set. This is mandatory configuration value if using redundancy feature |
But the WLAN/SSID is available for the users when a failover to standby-WLC has occured and users get IP.
It just that the captive portal doesn't kick in. It's almost like the standby-WLC doesn't have the config for re-directing to the captive portal.
06-30-2024 03:10 AM
- Any important message from WirelessAnalyzer should be corrected first. It could even be related to your issue or seems a bit plausible,
M.
07-01-2024 12:34 AM
- Also note that (also) in the case of the 9800-CL platforms , both peers need to be deployed for the same template (small , medium or large) with the same resources (vCPU ,memory hard disk , vNICs). Before pairing you can for instance verify those parameters with : show inventory
show platform software system all
Below you will find a number of other useful commands related to HA SSO
show chassis
show chassis detail
show chassis ha-status local
show chassis ha-status active
show chassis ha-status standby
show chassis rmi
show redundancy
show redundancy history
show redundancy switchover history
show tech wireless redundancy
show redundancy states
show logging process stack_mgr internal to-file bootflash:
show redundancy | i ptime|Location|Current Software state|Switchovers
M,
06-30-2024 05:47 AM
- Added reply : ref https://www.cisco.com/c/dam/en/us/td/docs/wireless/controller/9800/17-1/deployment-guide/c9800-ha-sso-deployment-guide-rel-17-1.pdf
>...SSO on Cisco Catalyst C9800-CL running on ESXi, KVM, Hyper-V
>...
>...Mobility MAC configuration
Ensure that you configure the mobility MAC address using the wireless mobility mac-address command for
High-Availability to work.
WLC (config)#wireless mobility mac-address ?
H.H.H Enter Mac Address for the mobility messages
Then proceed with the rest of the HA SSO setup as seen in the document
M.
06-30-2024 06:43 AM
Like @marce1000 says if the config is mandatory then failing to configure it means your config is unsupported by TAC, so instead of trying to argue about why you should not fix a config error just fix it. That doesn't guarantee it will resolve your issue but you won't know till you try and at least then you won't waste time being told to fix it if you open a TAC case for the issue. Normally the first thing TAC will do is run your output against the config analyzer for such errors.
06-30-2024 09:57 AM
I will try to set this, but I'm really struggling to understand what MAC address this is referring to. Also, I see there is a Mobility MAC address listed.
06-30-2024 11:02 AM
This is documented in https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/technical-reference/c9800-best-practices.html#MobilityMAC
"In an SSO scenario, ensure that you explicitly configure the wireless mobility MAC address; otherwise, the mobility tunnel will go down after SSO."
You should have "wireless mobility mac-address xxxx.xxxx.xxxx" in your config which is what the tool is looking at for those results.
If you still can't solve it then open a TAC case but they will likely want to reproduce the issue before they can diagnose the fault unless they already have a bug open for it.
07-01-2024 04:47 AM
- Added reply on 7/1 : As I have been working on this on a 9800-CL pair in a lab (EVE-NG based test environment) ; it seems
that setting the mobility mac address is only needed if this HA-SSO pair is being used in context with another
foreign anchor controller (to get a 'fixed mobility mac address' when there is a failover , or to
not confuse the remote foreign/anchor controller)
- As @Rich R you may want to work with TAC for faster insights.
- Is the HA-SSO pair running on the same hardware host (provisioning virtualization) ?
- Remember to use the Wireless Config Analyzer again when configuration changes
are done , to check for validation , (upon request from TAC or not)
M.
07-01-2024 05:07 AM
@marce1000 - it's also my impression that this mobility mac address is only important when dealing with a remote anchored WLC.
As mentioned earlier, it only came up as a warning - and not an error.
For good measueres I have configured it, and I will find a time to test the standby WLC as active WLC again.
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