Understanding Roaming

It’s probably safe to say that most people understand the concept of roaming at a high level. You want to move from your desk to the conference room. The conference room is on the other side of the building, but you are in the middle of a large upload. You don’t sweat it because you are on a wireless network and wireless is...“everywhere”!

That sounds nice, and that’s what wireless networks have to offer, but how does wireless get “everywhere”? From what you have learned so far, you know that a wireless signal can’t travel “everywhere” because of absorption, refraction, scattering, and more. You’ve also learned a little about roaming and how an AP needs some overlap to facilitate the process. But there is still more to it. If you step back and look at the big picture, you start to see that the controller has to be involved in this lightweight AP deployment. How is the controller involved? To understand that, you need to understand mobility groups.


Understanding Mobility Groups

In simple terms, a mobility group is a setting on a controller that defines the controller as a member of a group. Other controllers would also be members of that group. These controllers share information about the clients that are roaming. In Figure 12-1, two controllers are in the same mobility group. They can exchange information about the client that is roaming. Figure 12-2 shows a network with three controllers. Controller1 and Controller2 are in the same mobility group, and Controller3 is in a different one. When this scenario occurs, the three controllers are considered to be in the same mobility domain. A controller can be aware of another controller in a different mobility group as long as they are in the same mobility domain. This allows them to exchange information regarding their clients. This allows clients in different mobility groups to roam between the different mobility domains. If the controllers were in different mobility groups and did not have knowledge of each other, roaming could not occur. To provide this knowledge, you as an administrator need to enter the MAC address and management IP address of the other controller in the first controller, and vice versa. In other words, Controller2 needs to be configured with Controller3’s MAC and management IP addresses, and Controller3 needs to be configured with Controller2’s MAC and IP addresses.

To set this up in the controller, first you need to configure the controller’s mobility domain. Remember that multiple controllers share the same mobility group, and controllers in different mobility groups can communicate with each other if they are part of the same mobility domain. To configure the mobility domain using the controller web interface, choose CONTROLLER > General.

A controller can be in only one mobility group and one mobility domain. To configure the mobility group, choose CONTROLLER > Mobility Management. Controllers that are in the same mobility group have the same virtual gateway IP address. You can add these controllers by clicking New and then adding the IP address, MAC address, and mobility group of the other controller, as shown in Figure 12-3. In Figure 12-3, Controller2 is added to Controller1. If you have more than one controller to add, you can do it all at once.

How an LWAPP AP Discovers a Controller

When an AP discovers and joins a controller, the AP proceeds through several states. In Figure 11-2, you can see these states and when they happen.


The process begins with the discovery of a controller. Because the lightweight APs are by definition “zero-touch” when deployed, you should only need to plug them in and let them do the rest. On the back end, the part you do not see is a little more complex. The steps in this process, beginning with discovery, are as follows:

Step 1. The APs send LWAPP discovery request messages to WLCs. This is broadcast at Layer 2. Because Layer 3 mode is what you want to use, this should fail.

Step 2. Upon failing, the AP proceeds to Layer 3 by checking its configuration for an IP address. If no IP address exists, the client uses DHCP to obtain one.

Step 3. The AP uses information obtained in the DHCP response to contact a con- troller.

Step 4. Any WLC receiving the LWAPP discovery request message responds with an LWAPP discovery response message. If no controller responds, the AP reverts to Layer 2 broadcasts and starts the process again.

The Cisco implementation uses the hunting process and discovery algorithm to find as many controllers as possible. The AP builds a list of WLCs using the search and discovery process, and then it selects a controller to join from the list. The controller search process repeats continuously until at least one WLC is found and joined. IOS-based APs only do a Layer 3 discovery.

The Layer 3 discovery process follows a certain order:

Step 1. The AP does a subnet broadcast to see if a controller is operating in Layer 3 mode on the local subnet.

Step 2. The AP does an over-the-air provisioning (OTAP).

Step 3. When other APs exist and are in a joined state with a controller, they send messages that are used for resource management. These messages have the IP address of the controller in it. The AP can listen to these messages and get the controller IP address. The AP can then send a directed discovery message to the controller.

Step 4. The next process is called AP priming.


How an LWAPP AP Chooses a Controller and Joins It

Now that the AP potentially has numerous controllers to join, it must choose one and send it a join request message. Figure 11-3 illustrates this portion of communication.

A join request message contains the following information:

• Type of controller

• MAC of controller

• AP hardware version

• AP software version

• AP name

• Number and type of radios

• Certificate payload (x.509)

• Session payload to set up the session values

• Test payload to see if jumbo frames can be used

How an LWAPP AP Receives Its Configuration

After joining, the AP moves to an image data phase, as shown in Figure 11-6, but only if the image on the AP is not the same as the image on the controller. If they are the same, this step is skipped and the image is used.


The controller upgrades or downgrades the AP at this point, and then it resets the AP. Af- ter a reset, the process begins again. The code is downloaded in LWAPP messages.

After the process of discovery and join happen and the image is the same on the controller and the AP, the AP gets its configuration from the controller. This happens during the con- fig data stage, as illustrated in Figure 11-7.


The AP then prompts the controller for a config by sending an LWAPP configure request message that contains parameters that can be configured as well as any values that are currently set; however, most of these values are empty.

When the controller gets the request, it sends a configure response message, which has the configuration values.

The AP then applies the configuration values in RAM. It is important to understand that these values are not stored in flash. If the AP reboots, the process begins again.

After applying the configuration, the AP is up and running.