topic Re: About Authentication Request Forwarding between WLC Mobility Group Members in Wireless

About Authentication Request Forwarding between WLC Mobility Group Members

ajc — Mon, 05 Jul 2021 19:51:59 GMT

Hi all,

This is a question about Mobility Groups and authentication process. I have 2 WLC's in the same mobility group running Flexconnect. WLC-1 is active and providing services but WLC-2 even though it is part of the same Mobility Group is not in production yet.

I am running Default Flexconnect Group on both WLC's but also WLC-1 has 500 Flex Group configured. Each WLC has configured individual/separate ISE deployments because I am still testing WLC-2 using a 2nd ISE 2.7 version deployment on this WLC-2 controller.

The weird situation that I noticed was, that my testing ISE deployment which is only mapped/linked to WLC-2, displayed authentication information about endusers connected to the production environment on WLC-1/Flexconnect Group ABC + ISE 2.2 version deployment. Once I removed WLC-2 from the same Mobility Group were WLC-BCK and WLC-1 are, those hits on ISE-2 did not happen again.

QUESTION: If we have 2 WLC's in the same Mobility Group, are the Authentication request forwarded from WLC-1 to another WLC-2? . Keep in mind this is NOT a roaming/same location situation.

I am proceeding to investigate in details the Mobility Group behavior because this is NOT about AP's on the same AP Physical location so no L2/L3 roaming is happening at all.

Wondering if when I Mobility Group member cannot handle the amount of transactions/authentications (WLC LOAD) then it uses another Mobility Group member since that both devices have configured the same SSID's/Flexconnect Default Group/Default AP Group/etc.

Re: About Authentication Request Forwarding between WLC Mobility Group Members

Grendizer — Fri, 04 Dec 2020 18:26:40 GMT

What’s happening is that when you have same mobility group between the WLCs, the APs will get that info and may move to that WLC-BCK, when they moved, their clients then will be authenticated against the new ISE 2.7 using the WLC-BCK.

Re: About Authentication Request Forwarding between WLC Mobility Group Members

ajc — Fri, 04 Dec 2020 18:52:57 GMT

Thanks a lot for the reply.

I want to add I am not using AP Failover and I have configured on the AP's 2 High Availability Entries.

The point here is that the AP's are not moving from WLC-1 to WLC-2 (where the AAA connection to ISE 2.7 is configured and already tested). The AP is still on WLC-1 but I saw an enduser connected to a AP on WLC-1 hitting ISE 2.7 for authentication and that does not make sense because ISE 2.7 is only configured on WLC-2. That's why I am wondering if because of the WLC LOAD information exchange between Mobility Group members, the WLC-1 knows that WLC-2 has no load so it decides to forward the authentication to it.

Re: About Authentication Request Forwarding between WLC Mobility Group Members

Grendizer — Fri, 04 Dec 2020 19:40:43 GMT

It's impossible that WLC-1 send the auth to the other WLC-BCK. I saw in the past APs moving between WLCs because they have same mobility group name even if they have HA entries Pri/Sec configured so in your case I'm sure this is what is happening, you can prove me wrong if you test that again while watching the APs from WLC-BCK.

Re: About Authentication Request Forwarding between WLC Mobility Group Members

ajc — Fri, 04 Dec 2020 19:54:12 GMT

Thanks for your reply,

Important to mention, WLC-2 is NOT a High Availability Entry for the AP connected to WLC-1, it is only another WLC in the same Mobility Group. AND I completely agree with you, it does not make sense unless AP on WLC-1 for some reason moved to WLC-2 and then tried the enduser authentication. Let me try again and check if once I see the enduser authentication hitting ISE 2.7, the AP where that enduser is connected actually moved to the WLC-2. I will get back to you.

Re: About Authentication Request Forwarding between WLC Mobility Group Members

Grendizer — Fri, 04 Dec 2020 20:08:08 GMT

Thank you, and if you can, post the code version you're using on both WLCs.

Re: About Authentication Request Forwarding between WLC Mobility Group Members

ajc — Mon, 07 Dec 2020 16:57:25 GMT

Hi Grendizer,

Thanks a lot for your help, I enabled back the Mobility Group on WLC-2 and I could replicate the same behavior. Also I compared the ISE Logs against the WLC logs and I noticed that an AP from WLC-1 (which authenticates against the 2.2 ISE deployment) registered into WLC-2 (which authenticates against ISE 2.7 deployment) and that's why I saw endusers authenticating against the 2.7 ISE deployment.

One important question for you: WHAT is the condition that triggers this behavior of AP's moving from one WLC to another. From what I read on the Cisco documentation, WLC Mobility Group members exchange information in particular WLC LOAD so I am wondering if WLC-1 is getting loaded and therefore AP's from that WLC moving to the WLC-2 that only has 1 AP registered to it.

Important to mention that those AP's on WLC-1 does not have WLC-2 as a secondary entry on the High Availability TAB (I understand that AP HA Tab has nothing to do with mobility just wanted to mention this).

Re: About Authentication Request Forwarding between WLC Mobility Group Members

Scott Fella — Mon, 07 Dec 2020 17:05:29 GMT

I think you need to also look at how ap's discover controllers. DHCP, DNA, and subnet, are ways that ap's can find the other controller. When you also define mobility group, the ap's will also know about the other controller(s). This is fine, but another reason to define the high availability on each ap to ensure you have that set how you want.

If you want ap's to move, then move them using the high availability, they will not move by itself. There is no need to move to another controller unless the controller is unreachable.

Re: About Authentication Request Forwarding between WLC Mobility Group Members

ajc — Mon, 07 Dec 2020 17:23:46 GMT

Hi Scott,

Thanks for replying. I use DHCP Option 43 for AP to WLC registration. But I am still wondering why all of the sudden and curiously at the same time of the day in comparison with last friday, AP's moved from their regular WLC-1 to the new one WLC-2 (still being tested). What is the condition from the mobility group point of view that is triggering that behavior if those AP's were properly registered to WLC-1. Any debugs or logs at the AP level that I should look at? If I am not wrong when I remove WLC-2 from the Mobility Group that situation does not happen (I will confirm tomorrow once I remove today that configuration part).

thanks

Re: About Authentication Request Forwarding between WLC Mobility Group Members

Scott Fella — Mon, 07 Dec 2020 17:24:36 GMT

There can be many things, but typically lost of the primary, so the ap's moved to another available controller. You should look to see the uptime and join time of these access points, you can also look at the join statistics on the primary controller and see what happened. This is something that you typically do see in N+1, if you don't want ap's to move, then remove mobility group or setup aaa for access points on the other controller so that no ap's join that while you are testing. You would only need to define the mac address of the ap's you want to test with.

Re: About Authentication Request Forwarding between WLC Mobility Group Members

ajc — Mon, 07 Dec 2020 17:45:37 GMT

Thanks,

This is a Flexconnect deployment with a 8540 managing 3400+ AP's and 20K+ users at this moment.

What I have found so far on PI/AP CLI for one specific AP when the WLC switch happened is:

-'802.11a/n/ac' interface of AP 'LOCATION-1' associated to controller 'WLC-1 (172.x.x.x)' is down. Reason: Max Retransmission

-IDS 'Disassoc flood' Signature attack cleared on AP 'LOCATION-1' protocol '802.1....

-No valid AP manager found for controller 'WLC-1' (ip: 172.X.X.X), Failed to join controller WLC-1

Re: About Authentication Request Forwarding between WLC Mobility Group Members

Scott Fella — Mon, 07 Dec 2020 17:51:38 GMT

Well, that can now help you try to figure out the issue, but you still need to eliminate more variables. For example, do you see this happen in all sites or a few, do you see this happening to the same access points? Can be a something with the cabling or switchport causing the ap to not find/join the primary, ap going bad, I don't know. Try to find something similar or else you will never figure this one out.