Wireless options on Cisco WLCs

Summary

A few years experience has led to certain wireless options being set on our Cisco Wireless Controllers due to different reasons. Here is a summary of what we have set at the University of Leicester, and why we set them. They are generally valid for other wireless systems as well. Of course, there are likely things we've got wrong or missed out, so feedback is welcome.

EAP Timers

Problems logging in, especially when manually typing in credentials rather than using cached credentials, can be caused by the EAP timers being too short. Windows especially sees this issue when cached credentials is disabled, as it doesn't remember the credentials even long enough to send them in the second EAP session.

The issue is something like

• EAP Start
• Windows pops up login box for wireless network
• EAP Identity Requests in the background waiting for user to type in username and password.
• EAP times out, new EAP Start, new EAP Identity Request
• User finishes typing and hits OK.
• Original EAP session has expired, so Windows pops up another login box for the new session.

If your user is having a really bad day, they type the credentials in too slowly a few times, and then get locked out on the WLC for repeated authentication failures. Lockout is up to a minute or so, after which they get locked out again.

This can affect roaming from other sites. Even if you permit cached credentials, if another site does not and their users visit your site, they suddenly only have login problems if they don't type their credentials in within ~20 seconds. This has affected less abled typists.

Default is retry 20 times, each timeout is 1 second, so maximum 20 seconds. We increase to retry 12 times, timeout 5 seconds, for a maximum of one minute.

It should not be too long, because if the client gets into trouble they may be unable to disconnect until the controller has removed the broken EAP session and started a new one.

config advanced eap identity-request-retries 12

config advanced eap identity-request-timeout 5

See the Manipulating EAP Timers section of this Cisco page for more information.

These options cannot be manipulated using the controller GUI.

RADIUS server timeout

The default RADIUS server timeout on the wireless controllers is two seconds. This would likely be fine if all authentications were happening on-site to a local RADIUS server. However, when proxying auth requests off-site, it is quite possible that packets can take longer. Increasing this option helps with authentication, especially during busy times or with remote users.

Edit "Server Timeout" on the Security / AAA / RADIUS / Authentication (and Accounting) / RADIUS Server pages, or use the following at the CLI:

config radius auth disable <index>

config radius auth retransmit-timeout <index> <seconds>

config radius auth enable <index>

We are using ten seconds, which seems to be OK.

Adjusting this option also helps with the RADIUS failover, below.

RADIUS aggressive failover

If the controller doesn't see a response from a RADIUS server, it will consider that the RADIUS server has gone away, and will initiate a jump to the next available RADIUS server. This causes all current in-flight RADIUS requests to start to be sent to a different RADIUS server, which likely won't have any EAP state about them and will therefore fail.

This can cause an avalanche effect because there will then be lots of sudden authenications that may overload the new RADIUS server, causing the controller to again jump after a few seconds.

(It seems that in WLC 8.0+ this problem is compounded in that an accounting response failure will also cause the associated authentication server with the same index number to also be considered failed, it seems because of bugs in Cisco's ISE RADIUS server. See Cisco bug ID CSCum63243.)

To help with this, disable the RADIUS "aggressive failover" option, which is enabled by default. This will mean that the controller should now wait for three consecutive missing responses before jumping.

Use the CLI command:

config radius aggressive-failover disable

To see the current state, use:

show radius summary

and look for the line "Aggressive Failover" near the top of the output. There is no GUI option for this setting.

Client exclusion

Linked with the above, we found that the default of excluding clients due to authentication failures was just causing too many problems, so we disabled it.

config wps client-exclusion 802.1x-auth disable

This option is on the Security / Wireless Protection Policies / Client Exclusion Policies page of the GUI (Excessive 802.1X Authentication Failures).

Data rates

Clients further away from APs will have more RF noise, and therefore the speed will drop. This will mean that they talk slower, and therefore take up more of the available airtime. As wireless is a broadcast medium, this means other clients on the same channel (who may even be right next to the AP) have less time to communicate. Several clients that roam away from their original AP and do not hop on to nearer APs can cause very high radio utilisation and degredation of service unless they are forced to move onto nearer APs. This is a large problem in high density environments.

The solution is to disable the lower bandwidths. Note also that BSSID broadcasts happen every 100ms at the slowest rate, so they can use up a large amount of airtime. Cisco WLCs use the lowest "mandatory" speed for the beacons. We have used the following settings, which vastly improved wireless performance.

The downside is that you need more APs, because clients can't connect from further away. A partial solution can be to use AP groups to separate high density APs from other APs in less used areas.

You also lose 802.11b support, which is no bad thing as it's so slow it causes performance degradation for other clients. The following configuration will beacon at a high enough speed that 802.11b clients won't even see the network.

config 802.11a disable network
config 802.11a 11nSupport enable

config 802.11a rate disabled 6
config 802.11a rate disabled 9
config 802.11a rate disabled 12
config 802.11a rate disabled 18
config 802.11a rate mandatory 24
config 802.11a rate supported 36
config 802.11a rate supported 48
config 802.11a rate supported 54

config 802.11a enable network

config 802.11b disable network
config 802.11b 11gSupport enable
config 802.11b 11nSupport enable

config 802.11b rate disabled 1
config 802.11b rate disabled 2
config 802.11b rate disabled 5.5
config 802.11b rate disabled 6
config 802.11b rate disabled 9
config 802.11b rate disabled 11
config 802.11b rate supported 12
config 802.11b rate supported 18
config 802.11b rate mandatory 24
config 802.11b rate supported 36
config 802.11b rate supported 48
config 802.11b rate supported 54

config 802.11b enable network

These options are on the Wireless / 802.11a/n/ac / Network and Wireless / 802.11b/g/n / Network pages of the GUI.

Fast SSID change

When a setup network is used, clients will rapidly jump from the setup network to the 802.1X network at the end of configuration. The WLC stops clients from jumping SSID that fast, and enforces a pause before joining the new network. This causes the setup experience to not be seamless. The following option allows the clients to jump between networks without delay.

config network fast-ssid-change enable

This option is on the Controller / General page of the GUI.

Idle Timeout

When clients go quiet on the network (for example, go to sleep), the controller will remove their session. This can then cause them to wake up and reassociate onto the network.

To stop this happening every 5 minutes, we increased the idle timeout so that it is longer than half the DHCP lease time, so the DHCP renew packets of clients that are still around will keep the session alive.

config network usertimeout 900

The only real downside to doing this (apart from slightly increased memory usage on the controllers if you have a lot of clients) is that usage statistics may be slightly skewed, as clients that have legitimately wandered off will keep a session around for longer.

This option is on the Controller / General page of the GUI, or on the WLAN Advanced tab in later WLC software revisions (Client user idle timeout).

WLAN Session Timeout

Once authenticated, a client may keep the same session for up to the Session Timeout, after which they must reauthenticate. When this option is longer, clients will be able to connect for longer without reauthentication, thereby reducing load on the RADIUS servers, at the expense of possibly more ability for someone to hijack their session.

We found that some clients (such as Android) really don't like having to reauthenticate and will lose their connection, whereas some (such as Windows) will quite happily reauth without so much as a missed ping. To help the clients that struggle we increased the session timeout from 30 minutes to 12 hours.

config wlan session-timeout 1 43200

where 1 is the WLAN number.

We actually did it by setting the default to infinite with the following command, and then we send back a Session-Timeout attribute from the RADIUS server per user, which makes it easier to configure on the fly if we need to.

config wlan session-timeout 1 0

This option is on the WLANs / (your WLAN) / Advanced page in the GUI (Enable Session Timeout).