User idle timeout on WLC general setup

[axel.rasmussen]

I can see that there isn't any good description for this so does any have experience in settings this parameter.

My problem is that user need to reauthenticate after timeout.

Clients want to be on full time on smart phones an IPADs even that the don't use it

What is the impact for the controller to set this timeout to 2 hours og more.

[Scott Fella]

On the WLAN SSID in the advanced tab there is a setting for a timout. Default is 1800 and you can disable that or extend that out to 4 hours (14400), 8 hours (28800) or what ever time you wish.

Now will this fix an iPad that goes idle and is in sleep mode? I don't think it will. When the open up their device, it will join the wireless right away and sometimes it will require a manual touch. It mush be an apple thing as that is what I have to do with my iPhone and iPad.

Sent from my iPhone

[jwillie3]

I just ran across this thread and have a slight twist on the timer question.

In our deployment, our Guest SSID is open with just a Web Passthrough that offers up Terms and Conditions. 

So, since this is an open SSID, we see hundreds of clients that come to our facility and their devices pick up the SSID and associate to it, but the client never opens a browser to accept the T&C's.

We see dozens of clients associated to each AP, but the throughput is a few hundred bytes and they are sitting at a WEBAUTH_REQD state.

My understanding of the Client User Idle Threshold is the measure of data that must pass from the client during the Client User Idle timeout window.

So if you have your Timeout set to 1 hour, and your Threshold set to 0 (default), then the system will allow that client to remain associated for the entire hour while passing no traffic.

Am I interpretting those settings correctly?

Our corporate bigwigs want the ease of use of the Open WLAN (most of our clients are not employees, we offer free wi-fi for our guests) but I need to figure out a way to keep the AP load managable and knock these non-authenticated off the system.

Thoughts?

[mohanak]

You can also configure a threshold triggered timeout where if a client has not sent a threshold quota of data within the specified user idle timeout, the client is considered to be inactive and is deauthenticated. If the data sent by the client is more than the threshold quota specified within the user idle timeout, the client is considered to be active and the controller refreshes for another timeout period. If the threshold quota is exhausted within the timeout period, the timeout period is refreshed.

Suppose the user idle timeout is specified as 120 seconds and the user idle threshold is specified as 10 megabytes. After a period of 120 seconds, if the client has not sent 10 megabytes of data, the client is considered to be inactive and is deauthenticated. If the client has exhausted 10 megabytes within 120 seconds, the timeout period is refreshed.

http://www.cisco.com/c/en/us/td/docs/wireless/controller/7-4/configuration/guides/consolidated/b_cg74_CONSOLIDATED/b_cg74_CONSOLIDATED_chapter_01001101.html#d56625e215a1635

[gestionereti]

Hello all.

I don't want to deauthenticate idle users if they authenticated themselves at least one time.

I just want to kill all the devices that connect to the SSID, get an ip address from the dhcp server and never (web) authenticate,  because this runs the DHCP out of scope consuming all the ip addresses....

So in my case the User Idle Timeout is not useful.

Do you have any suggestion for me?

Thanks in advance to everyone.

Stefano Chiesa

[Scott Fella]

Use the sleeping client feature. You need to remember that only webauth WLAN can use sleeping clients. This is the thing with guest and portal pages. You need to have a large subnet to accommodate all devices that will associate to open SSID's.  There is no feature that will do what you want  just try the sleeping client feature.

-Scott

*** Please rate helpful post ***

[George Stefanick]

There are 2 important timers when it comes to Apple devices. The idle user timeout and the session timeout. Specific to the idle user timeout. Apple devices are very clean and as such they dont chat a lot when not in use and if they dont pass any traffic in 300 seconds (5 minutes) the WLC will delete the client record.

This will cause the user (guest) to get the guest page again.

Ive seen some hospitals change this to 4 hours and they haven't reported any issues.

[pcroak]

Just to chime in here:

The downside to bumping out your idle timeout is that your WLC client database will not be as accurate. In other words, your # of clients and client details could potentially be delayed for the idle timeout period. If you account for this delay when performing any statistical usage analysis, then it's really not a big deal.

Functionally, no problem with using a longer idle-timeout, other than slightly higher memory usage due to potentially old client entries in the database.

-Pat

[George Stefanick]

Pat, great info. I didnt thnk about the impact other than perhaps the "client table" getting a bit larger ..

[amr.momtaz]

WLC Timers Explained.

Q.   What are the explanations for these timeout settings on the controller:   Address Resolution Protocol (ARP) Timeout, User Idle Timeout, and Session   Timeout?

A. The ARP Timeout is used to delete ARP entries on the       WLC for the devices learned from the network.

The User Idle Timeout: When a user is idle without any       communication with the LAP for the amount of time set as User Idle Timeout, the       client is deauthenticated by the WLC. The client has to reauthenticate and       reassociate to the WLC. It is used in situations where a client can drop out       from its associated LAP without notifying the LAP. This can occur if the       battery goes dead on the client or the client associates move away.

Note: In order to access ARP and User Idle Timeout on the WLC GUI , go to           the Controller menu. Choose General from the           left-hand side to find the ARP and User Idle Timeout fields.

The Session Timeout is the maximum time for a client       session with the WLC. After this time, WLC de-authenticates the client, and the       client goes through the whole authentication (re-authentication) process again.       This is a part of a security precaution to rotate the encryption keys. If you       use an Extensible Authentication Protocol (EAP) method with key management, the       rekeying occurs at every regular interval in order to derive a new encryption       key. Without key management, this timeout value is the time that wireless       clients need to do a full reauthentication. The session timeout is specific to       the WLAN. This parameter can be accessed from the WLANs >       Edit menu.

http://www.cisco.com/en/US/products/ps6366/products_qanda_item09186a00808b4c61.shtml

[Jim Thomas]

Followup to people using ISE and manipulating these timers. Extending the timeout to a longer duration will also cause your ISE licenses to still be consumed, even if the endpoint is no longer on the network.