Showing posts with label guest. Show all posts
Showing posts with label guest. Show all posts

Friday, 15 June 2012

Issue: Having to log back in on Apple devices on a Cisco wireless guest network

I'm documenting this for my own reference as much as anything, to avoid having to look this information up (yet again).

(This description assumes that the use-case is for a guest network, but will apply to any layer-3 authenticated wireless network)

It is a common occurrence on Cisco wireless networks (using a WLC of some type) to have complaints from guest users that they have to keep logging back in to the guest network after their device has gone in to sleep mode. They are often put in to sleep when they are enveloped in some type of holder or covering system that has a built-in magnet to make them sleep when they are not in use (this is very typical on iPad holders/covers).

The reason for the annoying issue of having to log back in to the guest network is that the WLC has a user idle timeout setting which expires (by default) after 5 minutes. So, when a device is put in to sleep mode, the WLC will not hear from it for a while and then after  5 minutes will terminate its session.

If you know a little about WLCs, you would expect this behaviour to be dictated by the 'session timeout' setting which is available on the WLC GUI via the Advanced tab of the WLAN definition. But, that timer is the time-out for the entire (continuous) session. If you wish guest sessions to automatically end after a pre-defined period of use (e.g. force guest users to re-authenticate every couple of hours of use), you would use that setting.

To configure the idle time-out setting, you can only configure this via the CLI (in version 7.0 code anyhow) using the command below. Remember, this is the setting that will determine how long a client is idle (e.g. in sleep mode)  before its session is terminated. The command to use is:

config network usertimeout  seconds

The 'seconds' value is obviously the amount of time a device can be idle before its session is terminated. By default, it is 5 minutes (300 seconds), and can be a minimum value of 90 seconds.

The value you choose depends on how long your users may put their device to sleep for. Obviously you need to wind it up above the default of 300 seconds if users are complaining. I'd suggest trying 15 minutes (900 secs) and maybe wind it up  if users still complain (...try 30 minutes(1800 secs) next?).

The only downside to winding this value up is that clients will sit in your client list on the WLC for longer. Normally, they would time-out within 5 minutes. But, if you wind this value up, they won't age-out as quickly.

Right...the next time I need this info, I know exactly where to find it.

(Note: I had a note via Twitter from @revolutionwifi advising that another consideration with this approach is the possible impact this may have on WLC memory, which is a fair point. I guess it depends very much on your environment. This setting is going to affect all clients that attach to the WLC, so if you have large numbers of users, you may need to keep an eye on your memory usage. I suspect this would only be an issue if you had an environment where you have many unique users who come and go during the day, who would effectively hang around in the WLC memory for longer periods than you would like.)

Wednesday, 24 August 2011

Creating Per-site Guest VLANs on a Guest WLC (Cisco Guest Solution)


Before the advent of WLC code version, it was difficult to scale a Cisco guest wireless solution (in terms of IP address space) due to the fact that all foreign controllers (i.e. non-guest controllers) could only map to a single layer 3 interface on the guest (anchor) controller.

This often meant that a very large subnet had to be allocated to guest users to allow for multiple sites which shared a guest controller. The guest controller is usually located on a firewall DMZ interface (perhaps in a data center).

The only way around this was to have multiple guest SSIDs (e.g. one per building), with a separate VLAN for each SSID. This is not a very popular option with customers as there is no consistency of SSIDs between sites/buildings.

Another drawback of the single guest-VLAN restriction is that all guest traffic originates from a single subnet range. From an administrative point of view, it is often desirable for guest traffic from different buildings or sites to be sourced from their own subnet (to assist with traffic identification, filtering etc.)

In, a new feature: ‘VLAN Select’ was introduced which allows an individual dynamic interface (VLAN) to be selected on the anchor (guest) controller for each foreign (non-guest) controller. As an example, if you have a foreign controller at a number of buildings which all use one anchor (guest) controller, each building can now be assigned their own guest VLAN.

I recently had time to test this out in a lab environment and managed to grab a few screenshots of how to set this up. The process is very similar to the traditional method of setting up a guest controller, with a few additions and configuration changes at the anchor (guest) controller end of things.

Test Environment

The diagram below gives you some idea of the test environment I was using. It comprised 3 x 5508 WLCs running code: two acting as foreign controllers and one as an anchor (guest) controller.

The aim of the test configuration is to provide guest users at Building A with a guest subnet of and guest users a Building B with a subnet of All guest users will use the same SSID of ‘guest’.

Mobility Management

As usual, all controllers have their mobility management configured so that they all know about each other. In this example, both non-guest WLCs are in the ‘corp’ group and the guest WLC is in the ‘guest’ group.
All controllers will have their Mobility Group configuration configured as shown below:

Fig1: Mobility configuration (all controllers)

Foreign WLC Configuration

The foreign controllers are configured using the traditional method for configuring guest access. This involves defining the guest WLAN and assigning it to the management interface*. The guest WLAN is also anchored to the guest controller using the ‘Mobility Anchors’ feature:

(*NOTE: In a real-world deployment, it is best practice to assign the guest WLAN to an interface assigned to an unused VLAN. This mitigates the scenario where the anchor controller becomes unavailable and the guest WLAN become attached to the management interface of the foreign controller, which represents a security issue.)

Fig2: Guest WLAN created

Fig3: Guest WLAN anchored to guest WLC

Fig4: Guest WLAN assigned to management interface*

(*NOTE: In a real-world deployment, it is best practice to assign the guest WLAN to an interface assigned to an unused VLAN. This mitigates the scenario where the anchor controller becomes unavailable and the guest WLAN become attached to the management interface of the foreign controller, which represents a security issue.)

This process is repeated on both foreign controllers for the guest WLAN so that they both have a guest WLAN anchored to the guest controller.

Anchor (Guest) WLC Configuration

The difference to the traditional (pre- method of configuring guest access is found on the anchor (guest) controller.
On the anchor controller we have to configure a dynamic (VLAN) interface for each of the foreign controllers.
The activities we have to perform are:
  • Create the dynamic interfaces (2 in our case)
  • Create the guest WLAN (assigning it to the management interface)
  • Assign the dynamic interfaces on the anchor (guest) WLC to the foreign controllers on the guest WLAN
The screen shots below show these steps:

Fig5: Create a dynamic interface for the first site

Fig6: Create a dynamic interface for the second site

Fig7: Dynamic interface summary showing new interfaces

Fig8: Create guest WLAN and assign to management interface

Fig9: Configure the Foreign Maps to map the dynamic interface on to the foreign controllers

Fig10: Select each foreign controller and map it on to a dynamic interface

Additional Steps

There are additional steps that will required such as correctly configuring the guest WLAN or your environment, perhaps creating DHCP scope on the guest WLC etc.  These are all detailed in the Cisco wireless design guide in some depth.

Hopefully, if you are already familiar with configuring guest access on Cisco wireless solutions, this guide will have provided you with enough information to take advantage of this new feature. For further information about configuring guest wireless, please visit the resources shown below: