Ideal WLAN Timeout settings 9800CL

[Zimmeh1337]

Hello everyone

We've have been deploying 9800CL since the early releases of 16.1.X through 17.3.4 which is our current build.

We migrated from 2504/5508 WLC local mode to flexconnect which involved new adventures.

Down the road with official bug fixes we made som discoveries, most lately that "best practice" for Session Timeout should be <0, which I believe on AireOS was normal behaviour to set to 0. Currently our Session Timeout is set to 86400, which seems to work fine.

We've not been able to identify the ideal setting for Idle Timeout, which ranges from 0-10.000 (sec) also the Idle Threshold in terms of bytes is uncovered for us, ranges from (0-42.949.672).

What are your experiences with Idle Timeout(sec) & Idle Threshold (bytes)?

[Scott Fella]

Idle settings, I’ve always left that at default. The only thing I would change is the session timer. Changing too many things is more of a risk if things break down the road.

[Scott Fella · Accepted solution]

Also take a look at the recommendation for these settings:

These are the recommended values:
● Depending on the deployment policies, a good value for the session timeout could be 7200 seconds (120 minutes); this is the minimum time before client reauthentication is enforced. Starting with Release 17.4 the default session timeout is set to 86400 seconds (24 hours) and has to be considered the new recommended value to apply to all releases.
Note: In AireOS, a session timeout that is set to 0 (zero) means the maximum possible timeout. In the C9800, it actually means “no session timeout,” so if you use the same setting as in AireOS, every roam will require a full reauthentication.

● Set the per-WLAN user idle timeout to 3600 seconds (60 minutes) to reduce the likelihood of client deletion when moving out of coverage areas or when the client is battery operated and may go to sleep frequently.
● The exclusion timeout should be enabled, normally with exclusion set to 180 seconds (3 minutes).

[Zimmeh1337]

Thanks Scott

I saw your involvement in other related topics so I hoped to see you around here

I'll get to implementing right away.

[Scott Fella]

Just keep in mind that settings and values does change along with recommendations. This is tricky when you stick to something and later isn’t the preferred method. You tend to see this in release notes or when you upgrade and run a diff of previous config and see a change in a value or setting. 

[Avrabie]

Regarding WLAN Session Timeout:

Anybody knows how this mechanism actually works?

I understand what it does or what are its value limitations (depending on the security type), but can't figure out what actually triggers the client to re-auth. I've been monitoring the air for de-auth/disassoc frames but couldn't find any.

So, how does the client know when it's time to re-auth?

Is this value written down in some field of the beacon or probe response? If so, which is it?

Thank you

[Zimmeh1337]

Hello Avrabie

I can confirm this mechanism works.

We changed the value from 0 to 86400 by default, which drastically improved the user experience whilst being on coorporate network.

My understanding of the problem (based on experience from lab)

Whenever your clients roam on a WPA2-PSK or WPA2-802.1X network they have to re-authenticate.

If your client is idle i.e a mobile phone in your pocket, it doesn't neccesary re-authenticate right away as it's idle. Now when you bring up your device it's no longer connected to the WLAN and you either have to roam or toggle WiFi manually. 

[Avrabie]

Great, only I wasn't talking about the IDLE timeout, nor was I wondering if it works or not! I was asking about the Session Timeout!

[Zimmeh1337]

No reason to be rude

DYOR

[parntsen]

Hey,

I think we have the same problem here, where do you change the session timeout value?

[Avrabie]

I beg to differ here: rude is when you don't even carefully read someone's question but still feel the need to give some unrelated answer.

SYOC