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

Overview

Before the advent of WLC code version 7.0.116.0, 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 7.0.116.0, 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 7.0.116.0 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 192.168.50.0/24 and guest users a Building B with a subnet of 192.168.60.0/24. 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-7.0.116.0) 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:

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

Microsoft NPS as a RADIUS Server for WiFi Networks: Dynamic VLAN Assignment