Cisco Wireless Control System Configuration Guide, Release 3.2 - Chapter 8 - Configuring Mobility Groups [Cisco Wireless Control System]

Table Of Contents

Configuring Mobility Groups

Overview of Mobility

Overview of Mobility Groups

When to Include Controllers in a Mobility Group

Configuring Mobility Groups

Prerequisites

Mobility Anchors

Configuring Mobility Anchors

Configuring Mobility Groups

This chapter describes mobility groups and explains how to configure them on WCS. It contains these sections:

•Overview of Mobility

•Configuring Mobility Groups

•Mobility Anchors

Overview of Mobility

Mobility, or roaming, is a wireless LAN client's ability to maintain its association seamlessly from one access point to another securely and with as little latency as possible. This section explains how mobility works when controllers are included in a wireless network.

When a wireless client associates and authenticates to an access point, the access point's controller places an entry for that client in its client database. This entry includes the client's MAC and IP addresses, security context and associations, quality of service (QoS) contexts, the WLAN, and the associated access point. The controller uses this information to forward frames and manage traffic to and from the wireless client. Figure 8-1 illustrates a wireless client roaming from one access point to another when both access points are joined to the same controller.

Figure 8-1 Intra-Controller Roaming

When the wireless client moves its association from one access point to another, the controller simply updates the client database with the newly associated access point. If necessary, new security context and associations are established as well.

The process becomes more complicated, however, when a client roams from an access point joined to one controller to an access point joined to a different controller. The process also varies based on whether the controllers are operating on the same subnet. Figure 8-2 illustrates inter-controller roaming, which occurs when the controllers' wireless LAN interfaces are on the same IP subnet.

Figure 8-2 Inter-Controller Roaming

When the client associates to an access point joined to a new controller, the new controller exchanges mobility messages with the original controller, and the client database entry is moved to the new controller. New security context and associations are established if necessary, and the client database entry is updated for the new access point. This process remains invisible to the user.

Note All clients configured with 802.1x/Wi-Fi Protected Access (WPA) security complete a full authentication in order to comply with the IEEE standard.

Figure 8-3 illustrates inter-subnet roaming, which occurs when the controllers' wireless LAN interfaces are on different IP subnets.

Figure 8-3 Inter-Subnet Roaming

Inter-subnet roaming is similar to inter-controller roaming in that the controllers exchange mobility messages on how the client roams. However, instead of moving the client database entry to the new controller, the original controller marks the client with an "Anchor" entry in its own client database. The database entry is copied to the new controller client database and marked with a "Foreign" entry in the new controller. The roam remains invisible to the wireless client, and the client maintains its original IP address.

After an inter-subnet roam, data flows in an asymmetric traffic path to and from the wireless client. Traffic from the client to the network is forwarded directly into the network by the foreign controller. Traffic to the client arrives at the anchor controller, which forwards the traffic to the foreign controller in an EtherIP tunnel. The foreign controller then forwards the data to the client. If a wireless client roams to a new foreign controller, the client database entry is moved from the original foreign controller to the new foreign controller, but the original anchor controller is always maintained. If the client moves back to the original controller, it becomes local again.

In inter-subnet roaming, WLANs on both anchor and foreign controllers need to have the same network access privileges and no source-based routing or source-based firewalls in place. Otherwise, the clients may have network connectivity problems after the handoff.

Note Currently, multicast traffic cannot be passed during inter-subnet roaming. In other words, avoid designing an inter-subnet network for Spectralink phones that need to send multicast traffic while using push to talk.

Note Both inter-controller roaming and inter-subnet roaming require the controllers to be in the same mobility group. See the next two sections for a description of mobility groups and instructions for configuring them.

Overview of Mobility Groups

A set of controllers can be configured as a mobility group to allow seamless client roaming within a group of controllers. By creating a mobility group, you can enable multiple controllers in a network to dynamically share information and forward data traffic when inter-controller or inter-subnet roaming occurs. Controllers can share the context and state of client devices and controller loading information. With this information, the network can support inter-controller wireless LAN roaming and controller redundancy.

Note Clients do not roam across mobility groups.

Figure 8-4 shows an example of a mobility group.

Figure 8-4 A Single Mobility Group

As shown above, each controller is configured with a list of the other members of the mobility group. Whenever a new client joins a controller, the controller sends out a unicast message to all of the controllers in the mobility group. The controller to which the client was previously connected passes on the status of the client. All mobility exchange traffic between controllers is carried over an LWAPP tunnel. IPSec encryption can also be configured for the inter-controller mobility messages.

Examples:

1. A 4404-100 controller supports up to 100 access points. Therefore, a mobility group consisting of 24 4404-100 controllers supports up to 2400 access points (24 * 100 = 2400 access points).

2. A 4402-25 controller supports up to 25 access points, and a 4402-50 controller supports up to 50 access points. Therefore, a mobility group consisting of 12 4402-25 controllers and 12 4402-50 controllers supports up to 900 access points (12 * 25 + 12 * 50 = 300 + 600 = 900 access points).

Mobility groups enable you to limit roaming between different floors, buildings, or campuses in the same enterprise by assigning different mobility group names to different controllers within the same wireless network. Figure 8-5 shows the results of creating distinct mobility group names for two groups of controllers.

Figure 8-5 Two Mobility Groups

The controllers in the ABC mobility group recognize and communicate with each other through their access points and through their shared subnets. The controllers in the ABC mobility group do not recognize or communicate with the XYZ controllers, which are in a different mobility group. Likewise, the controllers in the XYZ mobility group do not recognize or communicate with the controllers in the ABC mobility group. This feature ensures mobility group isolation across the network.

Note Clients may roam between access points in different mobility groups, provided they can detect them. However, their session information is not carried between controllers in different mobility groups.

When to Include Controllers in a Mobility Group

If it is possible for a wireless client in your network to roam from an access point joined to one controller to an access point joined to another controller, both controllers should be in the same mobility group.

Configuring Mobility Groups

This section provides instructions for configuring mobility groups.

Note You can also configure mobility groups using the controller. Refer to the Cisco Wireless LAN Controller Configuration Guide for instructions.

Prerequisites

Before you add controllers to a mobility group, you must verify that the following requirements have been met for all controllers that are to be included in the group:

•All controllers must be configured for the same LWAPP transport mode (Layer 2 or Layer 3).

Note You can verify and, if necessary, change the LWAPP transport mode on the System > General page.

•IP connectivity must exist between the management interfaces of all devices.

Note You can verify IP connectivity by pinging the controllers.

•All controllers must be configured with the same mobility group name.

Note For the Cisco WiSM, both controllers should be configured with the same mobility group name for seamless routing among 300 access points.

•All devices must be configured with the same virtual interface IP address.

Note If all the controllers within a mobility group are not using the same virtual interface, inter-controller roaming may appear to work, but the hand-off does not complete, and the client loses connectivity for a period of time.

•You must have gathered the MAC address and IP address of every controller that is to be included in the mobility group. This information is necessary because you will be configuring all controllers with the MAC address and IP address of all the other mobility group members.

Note You can find the MAC and IP addresses of the other controllers to be included in the mobility group on the Configure > Controllers page.

Follow these steps to add each WLC controller into mobility groups and configure them.

Step 1 Navigate to Configure > Controllers (see Figure 8-6).

Figure 8-6 Configure > Controllers

This page shows the list of all the controllers you added in Step 1. The mobility group names and the IP address of each controller that is currently a member of the mobility group is listed.

Step 2 Choose the first controller by clicking on the WLC IP address. You will then access the controller templates interface for the controller you are managing.

Step 3 Select System > Mobility Groups on the left-hand side. The existing Mobility Group members are listed in the window (see Figure 8-7).

Figure 8-7 Existing Mobility Groups

Step 4 From the Select a command drop-down menu in the upper right-hand corner, choose Add Group Members and then click Go.

Step 5 You will see a list of available controllers (see Figure 8-8). Choose the desired WLCs and then click Save.

Figure 8-8 Saving the Mobility Group Configuration

Step 6 Repeat Steps 2 through 6 for the remaining WLC devices.

Mobility Anchors

Mobility anchors are a subset of a mobility group specified as the anchor controllers for a WLAN. This feature can be used to restrict a WLAN to a single subnet, regardless of the client's entry point into the network. In this way, users can access a public or guest WLAN throughout an enterprise but still be restricted to a specific subnet. Guest WLAN can also be used to provide geographic load balancing because WLANs can represent a particular section of a building (such as, a lobby, a restaurant, and so on).

When a client first associates to a controller of a mobility group that has been preconfigured as a mobility anchor for a WLAN, the client associates to the controller locally, and a local session is created for the client. Clients can be anchored only to preconfigured anchor controllers of the WLAN. For a given WLAN, you should configure the same set of anchor controllers on all controllers in the mobility group.

When a client first associates to a controller of a mobility group that has not been configured as a mobility anchor for a WLAN, the client associates to the controller locally, a local session is created for the client, and the controller is announced to the other controllers in the same mobility group. If the announcement is not answered, the controller contacts one of the anchor controllers configured for the WLAN and creates a foreign session for the client on the local switch. Packets from the client are encapsulated through a mobility tunnel using EtherIP and sent to the anchor controller, where they are decapsulated and delivered to the wired network. Packets to the client are received by the anchor controller and forwarded to the foreign controller through a mobility tunnel using EtherIP. The foreign controller decapsulates the packets and forwards them to the client.

Note A 2000 series controller cannot be designated as an anchor for a WLAN. However, a WLAN created on a 2000 series controller can have a 4100 series controller or a 4400 series controller as its anchor.

Note The IPSec and L2TP Layer 3 security policies are unavailable for WLANs configured with a mobility anchor.

Configuring Mobility Anchors

Follow these steps to create a new mobility anchor for a WLAN.

Step 1 Click Configure > Controllers > IP address of specific controller > WLANs to access the WLANs page.

Step 2 Click the desired WLAN ID URL.

Step 3 Click the Mobility Anchors link for the desired WLAN. The Mobility Anchors page for that WLAN appears.

Step 4 Check the IP address checkbox of the controller to be designated a mobility anchor and click Save.

Step 5 Repeat Step 4 and Step 5 to set any other controllers as anchors for this WLAN.

Step 6 Configure the same set of anchor controllers on every controller in the mobility group.

	Cisco Wireless Control System Configuration Guide, Release 3.2
	Chapter 8 - Configuring Mobility Groups
Cisco Wireless Control System Configuration Guide, Release 3.2 Preface Chapter 1 - Overview Chapter 2 - Getting Started Chapter 3 - Configuring Security Solutions Chapter 4 - Performing System Tasks Chapter 5 - Adding and Using Maps Chapter 6 - Monitoring Wireless LANs Chapter 7 - Managing WCS User Accounts Chapter 8 - Configuring Mobility Groups Chapter 9 - Maintaining WCS Appendix A - End User License and Warranty Appendix B - Supported Country Codes Index: Cisco Wireless Control System Configuration Guide	Download this chapter Chapter 8 - Configuring Mobility Groups Download the complete book pdf of Cisco Wireless Control System Configuration Guide (PDF - 2 MB) Table Of Contents Configuring Mobility Groups Overview of Mobility Overview of Mobility Groups When to Include Controllers in a Mobility Group Configuring Mobility Groups Prerequisites Mobility Anchors Configuring Mobility Anchors Configuring Mobility Groups This chapter describes mobility groups and explains how to configure them on WCS. It contains these sections: •Overview of Mobility •Configuring Mobility Groups •Mobility Anchors Overview of Mobility Mobility, or roaming, is a wireless LAN client's ability to maintain its association seamlessly from one access point to another securely and with as little latency as possible. This section explains how mobility works when controllers are included in a wireless network. When a wireless client associates and authenticates to an access point, the access point's controller places an entry for that client in its client database. This entry includes the client's MAC and IP addresses, security context and associations, quality of service (QoS) contexts, the WLAN, and the associated access point. The controller uses this information to forward frames and manage traffic to and from the wireless client. Figure 8-1 illustrates a wireless client roaming from one access point to another when both access points are joined to the same controller. Figure 8-1 Intra-Controller Roaming When the wireless client moves its association from one access point to another, the controller simply updates the client database with the newly associated access point. If necessary, new security context and associations are established as well. The process becomes more complicated, however, when a client roams from an access point joined to one controller to an access point joined to a different controller. The process also varies based on whether the controllers are operating on the same subnet. Figure 8-2 illustrates inter-controller roaming, which occurs when the controllers' wireless LAN interfaces are on the same IP subnet. Figure 8-2 Inter-Controller Roaming When the client associates to an access point joined to a new controller, the new controller exchanges mobility messages with the original controller, and the client database entry is moved to the new controller. New security context and associations are established if necessary, and the client database entry is updated for the new access point. This process remains invisible to the user. Note All clients configured with 802.1x/Wi-Fi Protected Access (WPA) security complete a full authentication in order to comply with the IEEE standard. Figure 8-3 illustrates inter-subnet roaming, which occurs when the controllers' wireless LAN interfaces are on different IP subnets. Figure 8-3 Inter-Subnet Roaming Inter-subnet roaming is similar to inter-controller roaming in that the controllers exchange mobility messages on how the client roams. However, instead of moving the client database entry to the new controller, the original controller marks the client with an "Anchor" entry in its own client database. The database entry is copied to the new controller client database and marked with a "Foreign" entry in the new controller. The roam remains invisible to the wireless client, and the client maintains its original IP address. After an inter-subnet roam, data flows in an asymmetric traffic path to and from the wireless client. Traffic from the client to the network is forwarded directly into the network by the foreign controller. Traffic to the client arrives at the anchor controller, which forwards the traffic to the foreign controller in an EtherIP tunnel. The foreign controller then forwards the data to the client. If a wireless client roams to a new foreign controller, the client database entry is moved from the original foreign controller to the new foreign controller, but the original anchor controller is always maintained. If the client moves back to the original controller, it becomes local again. In inter-subnet roaming, WLANs on both anchor and foreign controllers need to have the same network access privileges and no source-based routing or source-based firewalls in place. Otherwise, the clients may have network connectivity problems after the handoff. Note Currently, multicast traffic cannot be passed during inter-subnet roaming. In other words, avoid designing an inter-subnet network for Spectralink phones that need to send multicast traffic while using push to talk. Note Both inter-controller roaming and inter-subnet roaming require the controllers to be in the same mobility group. See the next two sections for a description of mobility groups and instructions for configuring them. Overview of Mobility Groups A set of controllers can be configured as a mobility group to allow seamless client roaming within a group of controllers. By creating a mobility group, you can enable multiple controllers in a network to dynamically share information and forward data traffic when inter-controller or inter-subnet roaming occurs. Controllers can share the context and state of client devices and controller loading information. With this information, the network can support inter-controller wireless LAN roaming and controller redundancy. Note Clients do not roam across mobility groups. Figure 8-4 shows an example of a mobility group. Figure 8-4 A Single Mobility Group As shown above, each controller is configured with a list of the other members of the mobility group. Whenever a new client joins a controller, the controller sends out a unicast message to all of the controllers in the mobility group. The controller to which the client was previously connected passes on the status of the client. All mobility exchange traffic between controllers is carried over an LWAPP tunnel. IPSec encryption can also be configured for the inter-controller mobility messages. Examples: 1. A 4404-100 controller supports up to 100 access points. Therefore, a mobility group consisting of 24 4404-100 controllers supports up to 2400 access points (24 * 100 = 2400 access points). 2. A 4402-25 controller supports up to 25 access points, and a 4402-50 controller supports up to 50 access points. Therefore, a mobility group consisting of 12 4402-25 controllers and 12 4402-50 controllers supports up to 900 access points (12 * 25 + 12 * 50 = 300 + 600 = 900 access points). Mobility groups enable you to limit roaming between different floors, buildings, or campuses in the same enterprise by assigning different mobility group names to different controllers within the same wireless network. Figure 8-5 shows the results of creating distinct mobility group names for two groups of controllers. Figure 8-5 Two Mobility Groups The controllers in the ABC mobility group recognize and communicate with each other through their access points and through their shared subnets. The controllers in the ABC mobility group do not recognize or communicate with the XYZ controllers, which are in a different mobility group. Likewise, the controllers in the XYZ mobility group do not recognize or communicate with the controllers in the ABC mobility group. This feature ensures mobility group isolation across the network. Note Clients may roam between access points in different mobility groups, provided they can detect them. However, their session information is not carried between controllers in different mobility groups. When to Include Controllers in a Mobility Group If it is possible for a wireless client in your network to roam from an access point joined to one controller to an access point joined to another controller, both controllers should be in the same mobility group. Configuring Mobility Groups This section provides instructions for configuring mobility groups. Note You can also configure mobility groups using the controller. Refer to the Cisco Wireless LAN Controller Configuration Guide for instructions. Prerequisites Before you add controllers to a mobility group, you must verify that the following requirements have been met for all controllers that are to be included in the group: •All controllers must be configured for the same LWAPP transport mode (Layer 2 or Layer 3). Note You can verify and, if necessary, change the LWAPP transport mode on the System > General page. •IP connectivity must exist between the management interfaces of all devices. Note You can verify IP connectivity by pinging the controllers. •All controllers must be configured with the same mobility group name. Note For the Cisco WiSM, both controllers should be configured with the same mobility group name for seamless routing among 300 access points. •All devices must be configured with the same virtual interface IP address. Note If all the controllers within a mobility group are not using the same virtual interface, inter-controller roaming may appear to work, but the hand-off does not complete, and the client loses connectivity for a period of time. •You must have gathered the MAC address and IP address of every controller that is to be included in the mobility group. This information is necessary because you will be configuring all controllers with the MAC address and IP address of all the other mobility group members. Note You can find the MAC and IP addresses of the other controllers to be included in the mobility group on the Configure > Controllers page. Follow these steps to add each WLC controller into mobility groups and configure them. Step 1 Navigate to Configure > Controllers (see Figure 8-6). Figure 8-6 Configure > Controllers This page shows the list of all the controllers you added in Step 1. The mobility group names and the IP address of each controller that is currently a member of the mobility group is listed. Step 2 Choose the first controller by clicking on the WLC IP address. You will then access the controller templates interface for the controller you are managing. Step 3 Select System > Mobility Groups on the left-hand side. The existing Mobility Group members are listed in the window (see Figure 8-7). Figure 8-7 Existing Mobility Groups Step 4 From the Select a command drop-down menu in the upper right-hand corner, choose Add Group Members and then click Go. Step 5 You will see a list of available controllers (see Figure 8-8). Choose the desired WLCs and then click Save. Figure 8-8 Saving the Mobility Group Configuration Step 6 Repeat Steps 2 through 6 for the remaining WLC devices. Mobility Anchors Mobility anchors are a subset of a mobility group specified as the anchor controllers for a WLAN. This feature can be used to restrict a WLAN to a single subnet, regardless of the client's entry point into the network. In this way, users can access a public or guest WLAN throughout an enterprise but still be restricted to a specific subnet. Guest WLAN can also be used to provide geographic load balancing because WLANs can represent a particular section of a building (such as, a lobby, a restaurant, and so on). When a client first associates to a controller of a mobility group that has been preconfigured as a mobility anchor for a WLAN, the client associates to the controller locally, and a local session is created for the client. Clients can be anchored only to preconfigured anchor controllers of the WLAN. For a given WLAN, you should configure the same set of anchor controllers on all controllers in the mobility group. When a client first associates to a controller of a mobility group that has not been configured as a mobility anchor for a WLAN, the client associates to the controller locally, a local session is created for the client, and the controller is announced to the other controllers in the same mobility group. If the announcement is not answered, the controller contacts one of the anchor controllers configured for the WLAN and creates a foreign session for the client on the local switch. Packets from the client are encapsulated through a mobility tunnel using EtherIP and sent to the anchor controller, where they are decapsulated and delivered to the wired network. Packets to the client are received by the anchor controller and forwarded to the foreign controller through a mobility tunnel using EtherIP. The foreign controller decapsulates the packets and forwards them to the client. Note A 2000 series controller cannot be designated as an anchor for a WLAN. However, a WLAN created on a 2000 series controller can have a 4100 series controller or a 4400 series controller as its anchor. Note The IPSec and L2TP Layer 3 security policies are unavailable for WLANs configured with a mobility anchor. Configuring Mobility Anchors Follow these steps to create a new mobility anchor for a WLAN. Step 1 Click Configure > Controllers > IP address of specific controller > WLANs to access the WLANs page. Step 2 Click the desired WLAN ID URL. Step 3 Click the Mobility Anchors link for the desired WLAN. The Mobility Anchors page for that WLAN appears. Step 4 Check the IP address checkbox of the controller to be designated a mobility anchor and click Save. Step 5 Repeat Step 4 and Step 5 to set any other controllers as anchors for this WLAN. Step 6 Configure the same set of anchor controllers on every controller in the mobility group.
	© 1992-2009 Cisco Systems, Inc. All rights reserved. Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks of Cisco Systems, Inc.