Mobility Messaging (Cisco Wireless LAN Controllers) Part 1

Controllers use mobility messages to hand off client state and set up a mobility tunnel session among group members for a mobile client. The Mobility Protocol is the protocol that controllers use for this message exchange. The Mobility Protocol employs a series of announcements, handoffs, and session termination messages as clients roam between controllers in the mobility group. The following sections discuss the different types of mobility messages, the mobility role of the controller in relation to the roaming client, Mobility Handoff types, mobility packet format, error recovery, and mobility messaging enhancements.

Mobility Message Types

Controllers in the same mobility group exchange a multitude of different messages to allow a wireless client to roam properly between them.

The 11 different mobility messages are as follows:

■ Controller Announce: Sent every 20 seconds as long as the controller is operational and carries no status information.

■ Mobile Announce: Sent when a client first associates with a controller. The controller sends up to four mobile announce messages. The message can be sent as either a unicast to each controller in the group or a multicast (multicast messaging is covered later under the "Mobility Messaging Enhancements in 5.0" section) to the mobility group multicast IP. As long as no Mobile Handoff message is received, the controller creates a Local client session. If the client was previously associated with another controller in the mobility group, that controller sends a Mobile Handoff to the new controller. Only a controller with a Local or Foreign client session can send a Mobile Handoff. A controller with an Anchor client session never answers the Mobile Announce message.


The Mobile Announce contains sufficient information to allow a local or foreign controller receiving the packet to determine the type of connection to which the client will transition on the new controller and the type of mobility transfer that will be necessary.

■ Mobile Handoff: Sent when a mobile client session is either transferred or a new foreign client session is established. It is always sent in response to a Mobile Announce and is always a unicast message.

■ Mobile Anchor Request: Sent by the new foreign controller to the anchor controller when it receives a handoff from another foreign controller. It notifies the anchor that the new foreign controller is ready to take over from the old foreign controller.

■ Mobile Anchor Grant: Sent by the anchor controller to the new foreign controller in response to a Mobile Anchor Request. It is only sent in response to an Anchor Request.

■ Mobile Anchor Transfer Request: Sent by the old foreign controller to the anchor controller when it sends a handoff to the new foreign or local controller. It notifies the anchor that the new controller is ready to take over.

■ Mobile Anchor Transfer ACK: Sent by the anchor controller to the old foreign controller in response to a Mobile Anchor Transfer Request. It is only sent in response to an Anchor Transfer Request. It closes the client session on the old foreign controller.

■ Mobile Handoff End: Sent by either the anchor or foreign controller to its respective peer to inform the peer that the client session is being terminated.

■ Mobile Handoff End ACK: Sent in response to a Mobile Handoff End.

■ Anchor Export Request: Sent when a mobile client first associates with a controller, the controller has not received a handoff in response to the mobile announcement, and the WLAN is configured for Auto-Anchor. It is sent as a unicast message to a single controller configured as an Export Anchor for that WLAN.

■ Anchor Export ACK: Sent in response to an Anchor Export Request. It is always a unicast message sent to the controller that sent the Anchor Export Request.

Mobility Role of the Controller to the Client

Any device on an IP network has an IP point of presence. The IP point of presence for a device is its IP and MAC address. Knowing the IP point of presence for a device is the way the network knows where to send traffic destined for that particular device. When using WLAN Controllers (WLC), the controller provides the client IP point of presence. Depending on the mobility role of a controller for a particular client, the controller with the AP that the client is actually joined to might not provide the IP point of presence for the client.

Controllers can play one of the following five roles to the client during client mobility session:

■ Local: The controller provides both AP association and IP point of presence.

■ Anchor: The controller provides the IP point of presence only and is always paired with a foreign controller. This is seen with asymmetric tunneling. Packets for the client are forwarded via an EtherIP encapsulated tunnel to the foreign controller for delivery to the client. The anchor controller provides proxy Address Resolution Protocol (ARP) for the client and is the relay to the Dynamic Host Configuration Protocol (DHCP) server for the client. DHCP reply is relayed back to the foreign controller outside the mobility tunnel.

■ Foreign: The controller provides the AP association only and is always paired with an anchor controller. This is seen with asymmetrical tunneling. Packets from the client are forwarded directly to the network except for ARP and DHCP requests. ARP requests are forwarded to the anchor controller via a mobility tunnel (EtherIP). DHCP requests are proxied by the foreign controller to the anchor (outside mobility tunnel) and then proxied by the anchor to the DHCP server.

■ Export Anchor: The controller provides the IP point of presence only and is always paired with an export foreign controller. This is seen with symmetric mobility tunneling and auto-anchoring. Packets for the client are forwarded via a mobility tunnel (EtherIP) to the foreign controller for delivery to the client. The anchor controller provides proxy ARP for the client and is the relay to the DHCP server for the client. DHCP packets for the client are forwarded directly to the client via mobility tunnel (EtherIP) to the Export Foreign controller rather than by relay outside mobility tunnel.

■ Export Foreign: The controller provides the AP association only and is always paired with an export anchor controller. This is seen with symmetric mobility tunneling and auto-anchoring. Packets from the client are forwarded via mobility tunnel (EtherIP) to the anchor controller, where they are de-encapsulated and delivered directly to the network. All packets, including ARP and DHCP packets, are sent within the mobility tunnel.

As you can see, there is a distinct difference between an anchor/foreign and an export anchor/foreign scenario. The anchor/foreign session uses asymmetric tunneling. Because the traffic path for the client is asymmetrical in an anchor-foreign connection, any Layer 3 service provided to the client, such as IPsec virtual private network (VPN), Layer 2 Tunneling Protocol (L2TP) VPN, and DHCP, cannot be processed on the anchor controller. The service session information must be extracted from the local or foreign controller and included as part of the handoff. As mentioned before, asymmetric tunneling is inefficient, can cause network routing problems, and is deprecated in code Release 5.2. The sections that follow assume that symmetric mobility tunneling is configured.

Mobility Handoff Types

Handoffs occur only between controllers in the same mobility group. A Mobile Handoff is sent when a mobile client session is either transferred or a new foreign client session is established. It is always sent in response to a Mobile Announce.

The mobile client connection to the network can take two forms:

■ A Local connection, where the client IP point of presence on the wired LAN (the subnet containing the client IP address) and the AP to which the client is associated are both directly accessible through a single controller.

■ An Export Anchor-Export Foreign (symmetric mobility) connection, where the client IP point of presence is accessible through one controller (the Anchor) and the AP to which the client is associated is accessible through another controller.

Mobility Handoffs come in six types:

■ Local to Local

■ Local to Foreign

■ Foreign to Local (1)

■ Foreign to Local (2)

■ Foreign to Foreign

■ Auto-Anchor

The sections that follow describe each handoff type in greater detail.

Local to Local

Local-to-Local Handoff occurs when the client performs a Layer 2 roam between two controllers and requires only two packets. Figure 9-9 illustrates a Local-to-Local Handoff.

As shown in Figure 9-9, when the client roams to an AP on WLC1, WLC1 sends a Mobile Announce to the mobility group members. WLC1 responds with a Mobile Handoff, and the client database entry is moved from WLC1 to WLC2. WLC1 no longer has the client database entry. WLC2 becomes the IP point of presence for the client.

Local to Foreign

A Local-to-Foreign Handoff occurs when the client performs a Layer 3 (inter-controller inter-subnet) roam and requires only two packets. Figure 9-10 illustrates a Local-to-Foreign Handoff.

As seen in Figure 9-10, in a Local-to-Foreign Handoff, when the client roams from WLC1 to WLC2, WLC2 sends a Mobile Announce, and WLC1 responds with a Mobile Handoff. The client database entry is copied from WLC1 to WLC2. WLC1 marks the client entry as Export Anchor, and WLC2 marks the client entry as Export Foreign. The IP point of presence for the client remains WLC1.

Local-to-Local Handoff

Figure 9-9 Local-to-Local Handoff

Local-to-Foreign Handoff

Figure 9-10 Local-to-Foreign Handoff

Foreign to Local (1)

A Foreign-to-Local (1) Handoff is the opposite of the Local-to-Foreign Handoff and again requires only two packets. The client is roaming from the foreign controller back to the anchor controller it came from. Figure 9-11 illustrates a Foreign-to-Local (1) Handoff.

Foreign to Local (1)

Figure 9-11 Foreign to Local (1)

Figure 9-11 shows that when the client roams back to WLC1, WLC1 sends out a Mobile Announce, and WLC2 responds with a Mobile Handoff. WLC1 knows it used to have a Local entry for that client and removes the Export Anchor designation from the client entry and once again marks it as Local. WLC2 deletes the database entry for the client. WLC1 remains the IP point of presence for the client.

Foreign to Local (2)

With a Foreign-to-Local (2) Handoff, three controllers are involved and four packets are needed. The client roams from the foreign controller to a third controller whose WLAN is in the same subnet as the anchor controller. Figure 9-12 illustrates a Foreign-to-Local (2) Handoff.

As shown in Figure 9-12, when the client roams to WLC3, WLC3 sends out a Mobile Announce, and WLC2 responds with a Mobile Handoff. The client database information is extracted from WLC2 by WLC3. WLC2 sends a Mobility Handoff End, and WLC1 responds with a Mobility Handoff End ACK. WLC1 and WLC2 delete the client database entry, and WLC3 marks the client entry as Local because its WLAN is in the same subnet as the client IP and becomes the IP point of presence for the client.

Foreign-to-Local (2) Handoff Foreign to Foreign

Figure 9-12 Foreign-to-Local (2) Handoff Foreign to Foreign

Foreign-to-Foreign Handoffs involve three controllers and require six packets to complete the transaction. The client data path is set up after the first three packets are processed. This is the most complicated handoff transaction. A Foreign-to-Foreign Handoff occurs whenever the client has already established an Export Anchor-Export Foreign connection and the new controller to which the client has associated does not share a common subnet assignment with the anchor controller for the WLAN in which the client is roaming, as seen in Figure 9-13. 

As shown in Figure 9-13, when the client roams to WLC3, WLC3 sends out a Mobile Announce to the mobility members. WLC2 responds with a Mobile Handoff, and all client entry information is extracted from WLC2 and transferred to WLC3. After sending the Mobile Handoff, WLC2 sends an Anchor Xfer message to the WLC1, at which time WLC1 responds with an Anchor Xfer ACK and sets up the new client forwarding path. WLC2 then deletes the client session. WLC3 sends an Anchor Req message to WLC1, and WLC1 responds with an Anchor Grant message. The IP point of presence for the client remains with WLC1.

Foreign-to-Foreign Handoff

Figure 9-13 Foreign-to-Foreign Handoff

Auto-Anchor Transfer

If a WLAN is configured for auto-anchoring, the setup of the client upon entering the network is different from normal. When the client associates, the controller sends out Mobile Announce messages (as seen in Figure 9-14) to the mobility members like normal just in case the client is roaming from another controller. A mobility auto-anchor controller never responds to a Mobile Announce message.

After WLC2 sends the fourth Mobile Announce and does not receive a Mobile Handoff from any other controllers in the mobility group, instead of creating a Local entry for the client, WLC2 sends an Export Anchor Request to WLC1, which is configured as the auto-anchor for the client WLAN. The anchor controller responds with an Export Anchor ACK. The client database entry is copied to the anchor controller. WLC1 marks the client entry with Export Foreign, and WLC1 marks the entry as Export Anchor. WLC1 is the IP point of presence for the client. With the auto-anchoring scenario, you have a fixed anchor controller for the client WLAN that will never change. The client will have an IP address in the same VLAN as the anchored WLAN interface on WLC1.

Auto-Anchor Transfer

Figure 9-14 Auto-Anchor Transfer

Next post:

Previous post: