WiFi Drops randomly

[ctm-tech]

We have been dealing with a issue for a few months and Cisco are finding it hard to pinpoint the issue.

We are runing a physical WLAN controller: AIR-CT5508-K9 and our APs are: AIR-CAP1602I-E-K9 & AIR-AP1852I-E-K9

The issue:

We are experiencing random drops across out WLAN that uses 802.11x for authentication back to a RAIDUS server on Server 2012R2. The issue occurs on multiple different laptops models (lenovo and dell). The drops do not happen at the same time, will affect clients at different times in the day and we cannot find a common cause.

When it occurs, we drop about 5 pings, I've noticed that on the network adapter stays connected but i'll loose the mydomain.local suffix. I can appreciate the occasional Ping drop, but this is enough to disconnect our RDP windows, boot users our of Citrix Apps. Skype of Business will logout on occasion aswell and users will need to relogin.

We have noticed that sometimes users will roam between 2 AP's, othertimes the disconnect will happen and they will reassociate with the same AP.

What we have tried:

The APs were already set to Flex Connect to breakout locally. We have moved all of the Wifi AP's that are in our office into an flexconnect group which means that we can then preshare the key for clients between them, this was a Cisco support recommendation.

Drivers: Between myself and some of the other tech guys we have tried different drivers, all that are available at present.

NPS Server: Runs as a VM and the only thing that I can see wrong with it is the fact its using a E1000 NIC insead of the recommended VmxNET3. Bar that its fully patched and No errors in logs. 

OS: Windows 7 and 8 machines do not seem to experience the problem, windows 10 seems be more fragile with WiFi connections.

In the IT area we have moved from the 1602i to 1852i now, and the problem still persists for users.

Network cards in use: Intel(R) Dual Band Wireless-AC 8260 & 8265 - Originally we thought the old AP's may have issues with the newer technology NIC's but as the problem persists it does not look like this is the case.

Cisco Support have said that they can see the disconnects but believe the issue is machine based. We only seem to be able to replicate the issue with Windows 10, with that said when users work from home they do not experience any dropouts (albeit they are not roaming between APs).

[Flavio Miranda]

Hi,

 Considering you dont have any issue with coverage, the next thing you could play with is EAP timers. But, a better option is verify if your WLC version did not hit any related Bug. There are probably more then one that cause client disconnect. If upgrade were an option, I´d try that as well.

-If I helped you somehow, please, rate it as useful.-

[ctm-tech]

Thanks for the reply. 
Could you confirm where the EAP Timers are? I'm looking at Security > Local EAP & Advanced EAP

I've checked the WLAN image is: 8.2.166.0 I'll look a the known issues with it, but I think the Cisco Support already did this.

[Flavio Miranda]

I am using this version as well. There´s a bug on which the client loses connectivity with the gateway but I did not see any case yet, or anyone reported to me. I´m preparing to move to 8.2.170.0.

 Another thing to verify is DHCP lease. I have found a DHCP scope here with 5 minutos which is extremely low.

 You can find the EAP timers on the link below. Must have a newer doc out there but the command must be the same.

https://www.cisco.com/c/en/us/td/docs/wireless/controller/7-4/configuration/guides/consolidated/b_cg74_CONSOLIDATED/b_cg74_CONSOLIDATED_chapter_010101101.html#ID1923

-If I helped you somehow, please, rate it as useful.-

[ctm-tech]

Do you have a bug number for that client drop issue?

I once found a issue with our AP models that stated a similar thing but it turned out that we were patched past it. I'd be very interested to show that bug as a reason to upgrade.

[patoberli]

This could also be a DHCP renegotiation issue.
In any case, you could also upgrade to 8.2.170.0, although 8.2.166.0 is also a very good release.
The EAP timers (for radius users) are under the Advanced EAP tab, which you have found.
My settings are (users must enter their PEAP password by hand):
Identity Request Timeout (in secs)
120
Identity request Max Retries
2
Dynamic WEP Key Index
0
Request Timeout (in secs)
120
Request Max Retries
2
Max-Login Ignore Identity Response
enable
EAPOL-Key Timeout (in milliSeconds)
2000
EAPOL-Key Max Retries
2
EAP-Broadcast Key Interval(in secs)
3600

Do you have 1 WLC or several?
If several, is the mobility management status good (up)? That's under Controller -> Mobility Management -> Mobility Groups

[ctm-tech]

Thanks for the reply.

My EAP settings are as follows:

Identity Request Timeout (in secs)
30
Identity request Max Retries
2
Dynamic WEP Key Index
0
Request Timeout (in secs)
30
Request Max Retries
2
Max-Login Ignore Identity Response
enable
EAPOL-Key Timeout (in milliSeconds)
1000
EAPOL-Key Max Retries
2
EAP-Broadcast Key Interval(in secs)
3600

Seems my timeouts are quite a bit shorter than yours. The DHCP leases are 8 hours. We see dropouts 2-3 hours in from firing up the machine, or does the DHCP reauth when they roam?

[patoberli]

Depends on your roaming setup, but shouldn't if they stay in the same subnet, don't need to re-auth and you are using one WLC.
DHCP will renegotiate after 50% of the lease time used up.

[ctm-tech]

We have a single subnet for our Corp WLAN at this site, Its possible that machines are attempting dhcp renegotiate if its after 50% of lease.

I'll try and check the lease time when it next happens.

Should we look at extending our EAP timers?

[Flavio Miranda]

debug client and debug aaa could help you answer if extend EAP timers could be a good choice. Usually you dont need to change it. But, if you see any timeout on the debug log, this might help. 

Another good please to look is at MONITOR tab, RADIUS Servers and "Authentication Server Statistics".

 You can see "Timeout Requests" and other stats.

-If I helped you somehow, please, rate it as useful.-

[ctm-tech]

Great, I'll see if I can get the debugs run.

In relation to the timeout requests. We are seeing 194. Which doesn't seem like a awful amount but I'll clear the counters and check on it tomorrow to see if there are any increases.

[asafayan1]

Did  you find any resolution to this issue?