Mobility Session Termination Message
A Mobility Session termination will be sent only when the controllers need to end an Export Foreign-Export Anchor relationship. The session termination may be initiated by either the foreign or anchor controller and requires only two packets. The termination might be required because of a client disconnect, timeout, or for administrative purposes. The client session will be deleted on both the foreign and anchor controller. Figure 9-15 illustrates Mobility Session termination.
In this example, the WLC2 (foreign) initiated the session termination to the WLC1 (anchor).
Figure 9-15 Mobility Session Termination
Mobility Packet Format
The mobility packet is a User Datagram Protocol (UDP) packet sent and received using port 16666. Because UDP is an unreliable delivery mechanism, any packet that requires a response retries up to four times at one-second intervals.
The mobility packet consists of a mobility packet header, which is required for all packets, followed by one or more Type, Length, Value (TLV) payloads carrying specific client or session data.
Mobility Packet Header
The Mobility Packet Header is part of every mobility packet. It is always the first record in the mobility packet. The header is fixed format and may be followed by one or more payloads, defined next, depending on the packet type and subtype.
Figure 9-16 shows the Mobility Packet Header, the fields for which are explained in the list that follows.
■ Packet Type: 1 octet. This can be thought of as a command code; it defines the overall purpose of the packet. See the previous subsection.
■ Packet Subtype: 1 octet. This is a 1-byte status field that is specific to the packet type. It is typically used as an OK/error code field in ACK messages.
■ Protocol Version: 1 octet.
■ Flags: 1 octet. Reserved, always 0.
■ Length: 2 octets. Length of the header + payloads in octets. The length may include padding.
■ Sequence Number: 2 octets. Monotonically increasing value used to detect retransmissions.
■ Exchange ID: 4 octets. Session ID used to bind request and answer packets. The Exchange ID plus the querying controller IP guarantee a unique session value.
■ Controller UID: 4 octets. UID portion (3 octets) of the controller MAC; leftmost octet is always 0.
■ Controller OUI: 4 octets. OUI portion (3 octets) of the controller MAC; leftmost octet is always 0.
■ Mobility Group Identifier: 16 octets. MD5 hash of the Mobility Group name. Mobility messages from groups other than the assigned Mobility Group name are ignored.
Figure 9-16 Mobility Packet Header
Mobility Packet Payloads
All Mobility Packet payloads follow a Type, Length, Value (TLV) format. The TLV header has the following format:
■ Type: 1 octet. The payload type.
■ Version: 1 octet. The version of the payload format. Currently, all Mobility payloads use Version 1.
■ Length: 2 octets. The length of the entire payload, including the TLV header.
The payloads can occur in any order following the packet header except for the Packet End payload. The Packet End payload, if included in the packet, must be the last payload in the packet.
Seven payload types exist
■ Client: Identifies a client.
■ DHCP: Transfers a client IP address.
■ Authentication: Username for client.
■ PEM policy: All information to restore PEM state.
■ IPSec: Transfers the Internet Key Exchange (IKE) Security Association (SA) and the HiFN Contexts specific to the client VPN session.
■ Anchor: Information to transfer an anchor session.
■ Payload End: The Packet End payload is necessary only if the length in the packet header includes padding beyond the last payload. Payload processing stops when the Packet End payload is encountered.
The packet payloads are hard-coded into the controller code so that when a controller receives a mobility packet, it knows how to decode it.
Error Recovery
In most cases, the mobility protocol is designed to fail in favor of client connectivity. If Layer 3 session information cannot be extracted or if the handoff cannot be completed, generally the response of the mobility group is to delete any existing client session information. This allows the client to start over with a new Local connection. Although the client may lose its existing network sessions and obtain a new IP address, it is not denied connectivity to the network.
Client Collision
Connection to the network in 802.11 is client initiated and, due to lost packets, a client might appear to associate with multiple controllers simultaneously. This condition is detected by the receipt of a Mobile Announce packet from another controller while waiting for a Mobile Handoff. In this case, if a Mobile Handoff is not received, the client is deauthenticated, the client session is deleted, and the client must either try again or complete the connection attempt on the other controller.
In the case of controller failure, no state information is retained among the mobility group or active status updates to allow recovery. Some failure recovery is built into the protocol handling.
Foreign Controller Failure
If a foreign controller fails, any clients associated to that controller attempt to associate elsewhere. If the anchor controller receives a Mobile Announce and does not receive an Anchor Transfer (Xfer) or Anchor Request (Req) within 10 seconds of the last Mobile Announce retry, it deletes the client and attempts to terminate the session with the foreign controller.
Anchor Controller Failure
Before code Release 4.1, there was no mechanism for a foreign controller to know if its anchor controller was down. If an anchor controller failed, you had to manually delete it on the foreign controller; if the clients reassociated with a new controller, the failure of the Anchor Xfer would delete the client session from the old foreign, and the failure of the Anchor Req would cause the client to transition to a Local session on the new controller. With 4.1 and higher code, the controllers regularly exchange mpings and epings to quickly detect a mobility group member failure. Now if an anchor is lost, the foreign controller disassociates all the clients tunneled to that particular anchor so it can reassociate and be tunneled to a working anchor if one exists.
Mobility Messaging Enhancements in 5.0
With code Release 5.0 or later, Cisco has added two mobility messaging improvements.
The first improvement is that a controller sends Mobile Announce messages to all the controllers in its mobility group first; then it sends those announcements to other controllers in the mobility list. Before this enhancement, the controller sent the messages to all controllers in the mobility list regardless of the configured mobility group. If the controller needs to retry the announcement, it includes the other controllers in the list. This reduces the number of messages a controller needs to send and receive.
The second improvement is multicasting the Mobile Announce messages instead of uni-casting them. Most messages, such as Mobile Announce, PMK Updates, AP List Updates, and IDS Shun, are meant for all members in the group. This means that a controller has to replicate a single message for every controller in the group. In code Release 5.0 or later, you can configure the controllers to multicast the Mobile Announce messages. With multicast enabled, the controller has to send only a single copy of the message to the multicast group that contains all the controllers in the mobility group. Using multicast is a much more efficient delivery method. Cisco recommends that it be enabled on all mobility group members to gain the maximum benefits.
Tip If a firewall exists in the network path between controllers, it is important to remember that multicast needs to be allowed on the firewall for the controller multicast group IP.
