07-21-2010 09:12 AM - edited 11-18-2020 02:50 AM
On the WLC, we have a couple of EAP timers that we can manipulate to help with client authentication, they are listed below:
EAP-Identity-Request Timeout
EAP-Identity-Request Max Retries
EAP-Request Timeout (seconds)
EAP-Request Max Retries
EAPOL-Key Timeout
EAPOL-Key Max Retries
Before we can manipulate these values, we need to understand what they do, and how changing them will affect the network
EAP-Identity-Request Timeout:
This timer affects how long we wait between EAP Identity Requests. By default this is one second (4.1 and lower) and 30 seconds (4.2 and greater. The reason for this change was, we found that some clients, hand helds, phones, scanners etc, had a hard time responding fast enough. Devices like laptops, usually do not require a manipulation of these values. Available value is from 1 to 120.
So, what happens with this attribute set to a value of 30? When the client first connects, it sends and EAPOL Start to the network, the WLC sends down an EAP packet, requesting the user or machines Identity. If the WLC does not receive the Identity Response, it sends another Identity Request 30 seconds after the first. This happens on initial connection, and when the client roams.
What happens when we increase this timer? If everything is good, there is no impact. However, if there is an issue in the network (including client issues, AP issues, RF issues), this can cause delays in network connectivity. For example, if you set the timer to the maximum value of 120 seconds, the WLC waits 2 minutes between Identity Requests. If the client is roaming, and the Response is not received by the WLC, we have created, at minimum, a two minute outage for this client.
Recommendations for this timer is to set it at 5. There is no current reason, to place this timer at it's maximum value.
EAP-Identity-Request Max Retries
So, for max retries, what does this value do? In short, this is the number of times the WLC will send the Identity Request to the client, before removing it's entry from the MSCB. Once the Max Retries is reached, the WLC sends a de-authentication frame to the client, forcing them to restart the EAP process. Available value is 1 to 20. So let's look at this for a moment.
The Max Retries is going to work with the Identity Timeout. If you have your Identity Timeout set to 120, and your Max Retries to 20 how long does it take for the client to be removed? 120 * 20 = 2400. So it would take 40 minutes for the client to be removed, and to start the EAP process over again. If instead you set the Identity timeout to 5, with the Max Retires of 12, 5 * 12 = 60. So there is one minute until the client is removed, and it has to start EAP over.
Recommendations for the Max Retries is 12.
EAPOL-Key Timeout
For the EAPOL-Key Timeout value, the default is 1 second or 1000 milliseconds. What this means is when it comes time to exchange the EAPOL keys between the AP and client, the AP will send the key and wait up to 1 second by default for the client to respond. After waiting the defined time value, the AP will re-transmit the key again. You can use the command "config advanced eap eapol-key-timeout <time>" to alter this setting. The available values in 6.0 are between 200 and 5000 milliseconds, while codes prior to 6.0 allow for values between 1 and 5 seconds. Keep in mind that if you have a client which isn't responding to a key attempt, extending the timers out can give them a little more time to respond....however, this could also prolong the time it takes for the WLC/AP to deauthenticate the client in order for the whole 802.1x process to start fresh.
EAPOL-Key Max Retries
For the EAPOL-Key Max Retries value, the default is 2. What this means is that we will retry the original key attempt to the client 2 times. This setting can be altered using the command "config advanced eap eapol-key-retries <retries>". The available values are between 0 and 4 retries. Using the default value for the eapol key timeout (1 sec) and the default value for the eapol key retry (2) the process would go as follows if a client doesn't respond to the initial key attempt:
1 - AP sends key attempt to the client
2 - Wait 1 second for a reply
3 - If no reply, then send eapol key retry attempt #1
4 - Wait 1 second for a reply
5 - If no reply, then send eapol key retry attempt #2
6 - If there is still not a response from the client and the retry value is met, then deauthenticate the client.
Again, as with the EAPOL-Key Timeout, extending the EAPOL-Key retry value could in some circumstances be beneficial, however setting it to the max may again be harmful as the deauthenticate message would be prolonged.
Thanks for this Stephen.
I have changed these timers over the years trying to work around client problems.
Can I verify the defaults/best setting these should be?
(Cisco Controller) >show advanced eap
EAP-Identity-Request Timeout (seconds)........... 60 should be 30?
EAP-Identity-Request Max Retries................. 10 should be 12?
EAP Key-Index for Dynamic WEP.................... 0
EAP Max-Login Ignore Identity Response........... enable
EAP-Request Timeout (seconds).................... 60 should be ?
EAP-Request Max Retries.......................... 15 should be ?
EAPOL-Key Timeout (milliseconds)................. 5000 should be 1000?
EAPOL-Key Max Retries............................ 4 should be 2?
thanks again!
jim
I too have questions on whether the current Cisco defaults should be modified it appears that in 7.3.101.0 the current defaults are:
EAP-Identity-Request Timeout (seconds)........... 30
EAP-Identity-Request Max Retries................. 2
EAP Key-Index for Dynamic WEP.................... 0
EAP Max-Login Ignore Identity Response........... enable
EAP-Request Timeout (seconds).................... 30
EAP-Request Max Retries.......................... 2
EAPOL-Key Timeout (milliseconds)................. 1000
EAPOL-Key Max Retries............................ 2
EAP-Broadcast Key Interval....................... 3600
For Windows clients sometimes initially they are prompted repeatedly to enter there password even when the password is entered quickly I believe. Would changing any of these timers help that issue? I found some references saying to adjust these but nothing I trust and this article is the first that I have seen to recommend lowering EAP-Identity-Request Timeout to 5!
Thanks,
Andrew
Sorry to wake this thread from the dead, but I have a question regarding
EAP-Identity-Request Timeout (seconds)........... 120
I currently have set it to 120 (since the beginning with release 4.2) seconds. Our clients have to enter their username and password the first time that they connect their laptop to the WPA2-Enterprise with PEAP protected wifi. At that old release they had to enter their username and password and accept the certificate within this EAP-Identity-Request Timeout to get a connection. Is this with code 7.0 still the case?
yes that is still the case. if they don't enter it in that time frame, they will be prompted again
And just to confirm, what is this one here exactly for?
EAP-Request Timeout
Because I have also increased this one to 120 seconds and lowered the EAP-Request Max Retries to 2.
I assume this is for the actual radius request (which transports the EAP frames) towards the radius server, e.g. ISE or ACS. The Request-Timeout being the timeframe in which a response from the radius server is expected and Max-Retries the times to send a new ACCESS_REQUEST.
I seriously doubt that this will help with your problem.
This sounds like a driver issue, because the operating system of that machine should always make a DHCP renew and if that fails a DHCP IP lease request where it should get the new IP address by the DHCP server.
Do you use local DHCP pools (on the WLC) or an external DHCP server?
Actually, I would prefer if you open a new thread for your question, as I'm pretty sure the authentication timers won't help here.
Hi,
Thank you very much for your reply
I use an external DHCP server (Infoblox), and I think that SSIDs using a local DHCP on the WLC are not affected.
Me too I doubt that the problem is related to the network card of the machine, but how will I convince the customer?
Is there a way or a tool to test the driver of the network card?
That depends on the producer of the device (Dell, Lenovo, ...). Also the version of the operating system plays a big role. Lastly, if there is some wireless management tool of the producer installed (Lenovo ThinkPad have a horrible one, for example) they might also mess around.
that is a different issue. This document is around the timers and what values should work to keep authentication happening quickly.
From what you're saying, it sounds like you would want to enable the Fast SSID change.
Controller > General > Fast SSID Change - set to enable.
If your client changes from "SSID-A" to "SSID-B", the client must do a DHCP discovery and receive a new address (in the correct subnet) from the DHCP server. If it doesn't do one (you could use Wireshark to sniff the packets on the client), it's the clients fault and you need to check with the Wi-Fi driver or operating system.
If it indeed does send a discovery, but not gets a reply, then we need to further check the WLC settings.
Thanks for your helpful information Stephne Rodriguez, I am just wondering if we have any impact in the wireless users and we need to program a maintenance window when we change this parameters or these changes are transparent for users? I was looking for this information but I could not find anything concerning this.
Thanks in advance,
Omar Tarcisio Cruz
@patoberli@Stephan on cisco 9800 wlc, where we can tweak EAP timers ? is this setting universal or can we tweak it per AP basis ?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: