A mobility event occurs if a client roams between access points (AP) or between controllers. If the wireless LAN (WLAN) is secured, 802.1x or Wi-Fi Protected Access (WPA), the client must reauthenticate to comply with the 802.11i IEEE standard. You want this process to have low latency and appear as transparent to the user as possible while still maintaining security. If this process happens fast enough, it is considered a seamless roaming event.
Controller mobility addresses two key issues:
■ After the introduction of 802.1x-key-handshakes and 802.1x/ EAP authentication on top of the legacy 802.11 protocol, it is mandatory to recheck the client credentials when the client changes its basic service set identifier (BSSID)—roaming from one AP to another with the same WLAN/service set identifier (SSID). This might cause long traffic interruptions while roaming when using secure authentication methods such as Extensible Authentication Protocol Transport Layer Security (EAP-TLS), which exchanges up to 20 packets during an authentication.
■ 802.11 is a link-layer protocol; therefore, it does not address roaming between two broadcast domains (Layer 3 networks/subnets).
Cisco Unified Mobility addresses both these issues in single controller and multiple controller scenarios. The controller acts as central "authenticator" and handles all the 802.1x frames. After the authentication has completed, the controller forwards the needed encryption material to the AP. Based on the Lightweight Access Point Protocol (LWAPP)/Control and Provisioning of Wireless Access Points (CAPWAP) architecture, all client traffic is centrally tunneled to the controller. This fundamental feature allows all registered APs to service every client VLAN even if the APs are in different subnets/VLANs (intra-controller roaming). This is something that is not possible in a standalone solution. In addition to tunneling client traffic between the AP and the controller, mobility allows for tunneling client traffic between controllers. This is necessary if the management interfaces of the controller happen to be in a separate subnet/Layer 3 network (inter-controller roaming) from one another.
When the client associates with an AP, the controller creates a client entry in its database. This entry includes the WLAN, security context, quality of service (QoS), IP, and MAC address of the client, the associated AP, and the LWAPP/CAPWAP tunnel where the client traffic is sourced and destined.
As wireless clients move between APs on the same controller and APs join to different controllers within the network, four different types of roaming events can take place:
■ Intra-controller
■ Inter-controller
■ Inter-subnet/Layer 3 mobility event
■ Auto-anchor mobility
Each type of roam results in a different behavior on the controller(s). The following sections describe the different roaming and mobility types in detail.
Intra-Controller Roaming
If a client roams between APs on the same controller, it is called an intra-controller mobility event. Intra-controller roaming is the most simplistic in that all the controller needs to do is update the database with the AP association and establish new security contexts if necessary. Basically, the Layer 3-related mobility is handled by the controller, and the link layer mobility is handled by the AP. As the client roams, the controller updates the client state. The client traffic then flows through the new AP LWAPP/ CAPWAP tunnel to the controller and out on the network. Figure 9-1 illustrates an intra-controller roam.
Inter-Controller Roaming
Inter-controller roaming occurs when a client roams between two APs registered to two different controllers, where each controller has an interface in the client subnet. When a client roams between controllers on the same subnet, the controllers exchange mobility messages, and the client database entry is transferred from the original controller to the new controller. Client traffic then flows through the new controller on to the network just like it did on the original controller. Figure 9-2 illustrates an inter-controller roam on the same subnet.
Inter-Subnet Roaming/Layer 3 Mobility Events
If the client roams between APs registered to different controllers and the client WLAN on the two controllers is on different subnets, then an inter-subnet roam, or Layer 3 mobility event, takes place. For example, if a client is on WLAN-X on Controller-1 using VLANx and the client roams to WLAN-X on Controller-2, but WLAN-X on controller-2 is using VLANy, then an inter-subnet roam for that client occurs.
Figure 9-1 Intra-Controller Roam
Figure 9-2 Inter-Controller Roam
Note It is important to remember that a Layer 3 mobility event occurs only when the interface assigned to the WLAN between the controllers is not the same. Whether or not the management interfaces of each controller are in the same subnet has no bearing on a client Layer 3 roaming event.
When the client roams between them, the controllers still exchange mobility messages, but they handle the client database entry in a completely different manner. The original controller marks the client entry as Anchor, whereas the new controller marks the client entry as Foreign. The two controllers are now referred to as anchor and foreign, respectively. The client has no knowledge of this and retains its original IP address on the new controller. Traffic flow to and from the client on the network becomes asymmetrical. Traffic from the client is bridged directly to the wired network by the foreign controller. The foreign controller spoofs the IP and MAC address of the client. Traffic from the wired network to the client, however, is received by the original controller and sent to the new controller through an Ethernet over IP (EtherIP) tunnel to the new controller. The new controller then passes that traffic to the client. Figure 9-3 illustrates asymmetrical mobility tunneling.
Figure 9-3 Inter-Subnet Roam/Asymmetric Tunneling
If the client roams back to the original controller, the Anchor and Foreign markings are removed and the client database entry is deleted from the foreign controller. If the client should roam to a different foreign controller, the original anchor controller is maintained, and the foreign client entry is transferred to the new foreign controller.
Asymmetrical tunneling can cause client issues if firewalls or an upstream router has reverse path filtering (RPF) enabled. RPF prevents multicast forwarding loops and prevents IP address spoofing in unicast routing. Because the client maintains its IP address from the WLAN subnet on the anchor controller, the downstream (to the client) network path is not the same as the upstream (from the client) network path, and RPF blocks it. Asymmetric tunneling can also cause jitter for voice clients if the network delay between the network upstream and downstream paths is different. Starting in code Release 4.1.171.0, Cisco added the symmetric mobility tunneling feature to alleviate the limitations of asymmetric mobility tunneling. Figure 9-4 shows where to enable symmetric mobility tunneling from the controller GUI. After enabling this feature, you must reboot the controller for it to take effect.
Figure 9-4 Enabling Symmetric Mobility Tunneling
When using symmetric mobility tunneling, RPF does not come into consideration because the client traffic path has the same ingress and egress point on the network. Figure 9-5 illustrates the symmetric mobility tunneling flow.
If you decide to use symmetric mobility tunneling, you should configure it on every controller in the mobility group. Symmetric mobility tunneling is the same tunneling scheme that is used in auto-anchoring. Auto-anchoring is covered in the next section. Starting in code Release 5.2, asymmetric tunneling is deprecated.
Figure 9-5 Symmetric Mobility Tunneling Traffic Flow
Tip If symmetric mobility tunneling is not enabled on the controllers when a Layer 3 mobility event with AP Groups takes place, the client might not be able to pass traffic properly because the data is sent on an incorrect VLAN. You must enable symmetric mobility tunneling if the AP Group VLAN interface on the foreign controller is using a different VLAN interface than the anchor controller. See the AP Groups section of this topic for more information on AP Groups.
Auto-Anchor Mobility
Auto-anchoring is when you anchor a WLAN to a particular controller in the mobility domain or group. Auto-anchoring can be used for load balancing and security. You can force clients to be on a particular controller/subnet regardless of the controller they access the wireless network from. Perhaps the most common use for auto-anchor is with guest networking.
With auto-anchor, regardless of which controller’s APs a client associates with, the client traffic is anchored to this one controller. Auto-anchoring is basically symmetric tunneling using a fixed anchor. Unlike the behavior with normal client roaming events, the anchor controller designated when configuring auto-anchor can never change. When a client first associates with a controller on an anchored WLAN, a Local Session entry is created for the client. The controller sends out a Mobile Announce message to the mobility group. When that message is not answered, the Foreign controller contacts the configured anchor controller and creates a foreign session for the client in its database. The anchor controller then creates an Anchor session for the client.
All traffic to and from the client associated with an anchored WLAN passes through the anchor controller. This is known as a bidirectional tunnel because the foreign controller encapsulates the client packets in EtherIP and sends them to the anchor. The anchor de-encapsulates the packets and delivers them to the wired network. Packets destined for the client are encapsulated in the EtherIP tunnel by the anchor and sent to the foreign controller. The foreign controller de-encapsulates the packets and forwards them to the client. Figure 9-6 illustrates the symmetric traffic flow with auto-anchoring.
Figure 9-6 Auto-Anchoring Symmetric Tunnel
