When you create a WLAN on the controller, you have to assign an interface to that WLAN for the client traffic to use. Imagine that you have a 4404 series controller with 100 registered APs and 25 clients per AP on the same WLAN. You now have 2500 clients on the same subnet. The initial goal of AP Groups was to separate the clients for a single WLAN into different subnets to decrease the size of the broadcast domain for that WLAN. The AP Group feature on the controllers allows you to use the same SSID but override the interface configured on the WLAN. In addition to decreasing the size of the broadcast domain for a single WLAN, there are many reasons why you might want to use the same SSID but have the clients on different subnets. There could be geographical reasons or a lack of enough IP addresses for a given subnet. Clients that are roaming between APs in different AP Groups on the same controller are not required to change VLANs because of intra-controller roaming.
A perfect example of when to use AP Groups would be a campus with three separate buildings, each on their own subnet, VLAN 10, 20, and 30 respectively, and a single controller. You would not want to have three separate SSIDs for each building because the clients would have to have three separate profiles to connect to the wireless network depending on which building they happened to be in. With AP Groups configured, the clients would need to have only a single wireless profile set up. The controller could have three AP Groups configured, each one using the correct dynamic interface for the subnet for the particular building, and the APs in those buildings would be members of their respective AP Group. So when a client in building Two, for example, connects to the SSID Corporate just like a user in building One, because the AP Group overrides the interface configured on the WLAN; the client in building Two is on VLAN 20, whereas the client in building One is on VLAN 10. The same goes for a client in building Three. That client would be on VLAN 30.
When a client first associates to an AP on a controller, the controller applies the AP Group VLAN override policy as configured for that WLAN. When the client roams to another AP on the same controller, the AP Group policy for that AP is reapplied. During a single session, a client does not change VLANs when it roams among APs on a single controller. This allows for seamless roaming. When a client roams across APs associated to different controllers, however, the process follows the normal roaming process.
In the 5.2 release of code, the AP Group feature has changed dramatically. The new AP Group feature not only allows you to override the interface for a WLAN, it also allows you to determine what WLANs the APs in a particular AP Group will service. In previous versions of code, a separate feature known as WLAN override allowed you to configure what WLANs an AP would service. By default, an AP will service all the WLANs configured on the controller. For more information on WLAN override and the new AP Group feature, visit Cisco.com.
Troubleshooting AP Groups
To troubleshoot client mobility, you use the same debugs covered under "Troubleshooting Mobility," later in this topic. The most common mistake, however, when trying to use AP Groups is not enabling the feature. On the AP Groups configuration page, there is a small check box to enable the feature. Figure 9-7 shows the AP Groups check box on a 4.2 controller. This must be selected and applied. You can configure all the AP Groups you like and assign APs to those groups, but if this check box is overlooked, nothing works as expected.
You can also verify that AP Groups is enabled via the command-line interface (CLI) using the following commands:
In code prior to the 4.1.181.0 release, the command is show location summary
In code after the 4.1.181.0 release, the command is show wlan apgroups
In Example 9-1, you can see the output of show wlan apgroups from a 4.2 controller.
Figure 9-7 Enabling AP Groups
Example 9-1 show wlan apgroups Command Output
In this output you can see that an AP Group is configured, but the actual AP Group feature is disabled. With this configuration, AP Groups will fail.
You will also want to make sure that your APs are in the correct AP Group. You assign APs to an AP Group under the AP Configuration Advanced tab. You can verify the configuration with show ap config general ap-name. Example 9-2 shows the output of this command.
Example 9-2 show ap config general Command Output
Example 9-2 show ap config general Command Output
Here you can see that the AP is indeed a member of the vlan20 AP Group.
