Wireless Timeout Settings

It's been over a year since my last blog post...  Not good.

I'm back again, however, listing some of the timeout settings that can cause issues on WLANs.  There are five infrastructure timeout values that may affect users who connect to a WLAN, depending on how and where they are connecting.  These are:

1.       Arp Time to Live

Deletes ARP entries on the WLC for the devices learned from the network.  Increasing this timeout increases the CPU load and distorts statistics for the number of simultaneous users.  The default value is 300 seconds (5 minutes).  The command applies to all WLANs on the WLC.  Configured at Controller > General > ARP Timeout.

2.      Session 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 de-authenticated by the WLC. The client has to re-authenticate and re-associate 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. Increasing the user idle timeout utilizes more RAM on the WLC and will make the WLC client database less accurate.  Default is 300 seconds (5 minutes).  The command is specified per WLAN.  Configure at WLANs > WLAN ID > Advanced > Enable Session Timeout.

3.      User Idle Timeout

This setting 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. Increasing the user idle timeout utilizes more RAM on the WLC and will make the WLC client database less accurate.  Default is 1800 seconds (30 minutes).  The command applies globally to the WLC.  Configured at Controller > General > User Idle Timeout.

4.      Broadcast Key Interval

When a user connects to the WLAN, they receive a broadcast key.  If 802.1x authentication is in place, this key allows for encryption of broadcast/multicast traffic to the client.  Increasing the timer has a slightly detrimental effect on WLAN security, as a nefarious user who manages to decrypt the key would gain access to a larger data set.  Default is 3600 seconds (1 hour).  This setting applies to all WLANs on the WLC.  Configured via CLI: config advanced eap bcast-key-interval x, where x is a value between 120 and 86400.

5.      DHCP Lease Time

The DHCP lease specifies the amount of time a given client may utilize a dynamically assigned IP address.  Increasing the value can create DHCP scope depletion, where all IP addresses in the scope are assigned to clients even though those clients are no longer active on the network.   Default on Cisco routers/switches is 1 day.  This applies to all clients on the scope.

In addition, other timeouts need to be considered:

6.      Device Timeout

All WLAN client devices have their own settings for determining when and how to disassociate from a WLAN or disable their wNIC.  This is normally done to conserve battery power and/or increase device security.  These default values are device-dependent.

7.      Other Timeouts

There are many other timeout values that can affect the wireless user experience.  Among these are VPN timers, RADIUS timeout values (when utilizing 802.1x), and various client application settings (browser timeouts, sleep settings, power settings, etc.).  Determining the exact cause of a timeout for a specific group of users may require consideration of these values.

When APs don't register to a controller and have a static IP

I ran into an interesting problem last Monday (02/01/10) at work - someone had deployed APs at a remote location and configured them as autonomous APs. I performed a quick lightweight upgrade on them, and made the mistake of leaving static IPs on them.

The upgrade tool asks for your WLC address so I thought that would prime the APs with that address for the controller... Wrong. As soon as the APs booted to their lightweight IOS (the standard recovery image) I lost connectivity with them (no DHCP so option 43/60 is not available. APs are on a different domain than the switch - why it kept this but not snmp and passwords is irritating - so controller DNS didn't work). Passwords were of course reset, so telnet/ssh responded with "password required but none set." SNMP was also reset... I thought I had lost connectivity to them and would be required to ship out new APs!

In reviewing some of the Cisco literature, though, I found a cool little workaround. You can set the IP helper-address to the IP address of the controller, and then use the "forward protocol" command to forward all CAPWAP/LWAPP traffic to the IP helper-address, i.e. the controller (protocols 12222, 12223 for LWAPP and 5246, 5247 for CAPWAP)! Once connectivity was re-established to the APs, I set them to DHCP and removed the forward protocol commands and set the IP helper-address back to the DHCP server. Problem solved without sending new APs!