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.

AP Authentication vs. MFP

If you have ever been confused by these two settings, you're not alone.  MFP and AP Authentication are both configured from the same page via the WLC GUI.  This makes one ponder the difference between the two options.

According to Cisco, AP Authentication is used for encrypting the AP to AP RRM traffic whereas MFP is used to protect the 802.11 management frames (hence the name...).  Also, it should be noted that these two options are mutually exclusive.

Sources:
AP Authentication - http://www.cisco.com/en/US/docs/wireless/wcs/4.0/configuration/guide/wcstemp.html
MFP - http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a008080dc8c.shtml

WLC Mobility

Best Practices for Mobility:

1.  Use the same, non-routable virtual IP.  To verify the virtual address, use the show interface summary command.  Also, ping the virtual address to make sure it's not routable.

2.  All controllers must be configured for the same LWAPP transport mode.  Use the show switchconfig command to verify LWAPP transport mode, and the config switchconfig mode to change any of the parameters.

3.  IP connectivity between all WLCs is required (checked by creating the tunnel)

4.  WLCs must have the same mobility group (except for guest tunneling)

5.  WLCs must be running the same version of code.

6.  MACs and IPs are required to build the tunnel.

7.  Do not create overly large mobility groups.

Source
http://www.cisco.com/en/US/customer/tech/tk722/tk809/technologies_tech_note09186a0080810880.shtml

Ensuring that traffic to/from APs arrives on the same controller port

My good friend Leigh is really doing a bang up job on his blog...  Putting me to shame!  It's given me motivation to make the following post though.

Here's something that I just read in the WLC Configuration Best Practices:

"With the Cisco IOS Software Release 12.2(33)SXH6, there is an option for PFC3C mode chassis to exclude VLAN in the Load-distribution . Use the port-channel load-balance src-dst-ip exclude vlan command in order to implement this feature. This feature ensures that traffic that belongs to a LAP that enters on the same port."

The bold is original, I added the italics for emphasis.  On my configs I've always used port-channel load-balance src-dst-ip, but never exclude vlan...  Seems like a good thing to try my next go-round.

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!

AP Fallback

I've been reading the 802.11 Wireless LAN Fundamentals recently, just while traveling. It's not sinking in too well, really, but I'm slowly making some connections with real-world applications. They're few and far between, though. Studying the wireless physical layer isn't high on my priority of learning, but I guess it makes a good cornerstone...

A more pressing wireless question I've come up with is AP fallback mode. I would like all the APs on our network to be setup in Local mode so that they aren't overutilising their resources and creating a lot of heat in the process. However, because of our network configuration, we don't have backup WLCs in each location we have wireless deployed. So in order to get the APs to work properly in fallback mode, I think we're going to have to deploy them all in H-REAP.

Basically, I would like to keep the APs in Local mode unless they need to failover, in which case I'd like them in H-REAP. Since that's not possible, I have 2 options:

1. Keep the APs in Local mode 100% of the time. The drawback here is that when the APs failover, they tunnel all the traffic across our WAN to the closest WLC, but take up a lot of the bandwidth doing so. Also, the clients are forced to get IPs from a site across the WAN, which ultimately disrupts some of the applications they are able to access since they are hitting the firewalls with different IPs.

2. Keep the APs in H-REAP. This forces the APs to do the client authentication, association, etc., and forces them to use more resources thus giving less throughput to the clients. Plus, everything I'm reading says it isn't recommended except for remote sites where it's not cost effective to place a controller.

We had set everything to H-REAP. I think now, though, that we should have all APs deployed in Local mode and just recognize that if a controller fails, the clients won't have connectivity, or might not be able to access all their applications.