C9800 Mobility and Inter-Controller Roaming Explained

Why Mobility Matters

Enterprise wireless networks must support seamless client roaming. When a wireless device moves between access points, you want zero service interruption. The Catalyst 9800 WLC provides sophisticated mobility mechanisms to handle this requirement, whether clients roam within a single controller or across multiple controllers in a distributed deployment. Understanding mobility types, configuration layers, and inter-controller mechanics is essential for operators managing large-scale wireless infrastructure.

Client Database and Roaming Context

When a wireless client associates and authenticates to an access point, the C9800 creates a client database entry containing the client's MAC and IP addresses, security context, quality of service settings, and details about the AP to which the client is associated. At each client roam, this context must be maintained so the C9800 can forward frames and manage traffic to and from the wireless client. This context preservation is the foundation of all roaming behavior.

The type of roaming depends on whether the APs are registered to the same C9800 or to different C9800s, and whether clients maintain the same IP address across the roam.

Types of Client Roaming

Client roaming in a C9800 deployment falls into two broad categories:

• Intra-controller roaming: Both APs are registered to the same C9800
• Inter-controller roaming: The two APs are registered to two different C9800s

Each category has distinct behavior based on site tags, policy profiles, and VLAN configuration.

Intra-Controller Roaming

Overview and Roaming Types

In intra-controller roaming, the client roam is limited to APs on one C9800. Depending on tags and profiles applied to the APs, three types of intra-controller roaming can occur:

• Intra-WLC, Intra-WNCd roaming (same site tag, same policy profile)
• Intra-WLC, Inter-WNCd roaming (different site tags, same policy profile)
• Intra-WLC, Inter-policy profile roaming (same site tag, different policy profiles)

On the C9800, the Wireless Network Control daemon (WNCd) terminates Control and Provisioning of Wireless Access Points (CAPWAP) tunnels and processes control and management traffic. Multiple WNCd instances run across multiple slots depending on form factors.

Intra-WNCd Roaming (Same Site Tag, Same Policy Profile)

APs are mapped with site tags and policy tags. When you group RF-proximate APs into one custom site tag (intentionally grouping them by proximity), each custom site tag with an AP is mapped to a single WNCd instance. When a client roams between two APs that are RF neighbors and belong to the same WNCd instance with the same site tag, the roam is within the same WNCd instance, referred to as intra-WNCd roam.

In intra-WNCd roaming, the C9800 simply updates the client database with information about the new AP to which the client is now associated. The client retains its IP address, and the C9800 continues to forward traffic for the client. All 802.11r fast secure roaming optimizations (11k, 11v, 11w-FT) are supported with this roam. For C9800 form factors like C9800-CL (small) and C9800-L, all roams are intra-WNCd roams.

Inter-WNCd Roam (Different Site Tags, Same Policy Profile)

When grouping RF-proximate APs into one custom site tag, the maximum number recommended on each site tag for local mode deployment is about 500 APs. In FlexConnect mode, the maximum is 100 APs. If you have APs that are RF neighbors but belong to different custom site tags, roaming between them is across two WNCd instances, referred to as inter-WNCd roam.

With inter-WNCd roaming, fast secure roaming is supported because the PMK cache is shared across WNCd instances. Starting with release 17.6.1, 802.11k and 802.11v are also supported when roaming across WNCd instances because AP neighbors are calculated independently from the WNCd instance.

Intra-WLC Roam with Different Policy Profiles

APs are mapped to policy tags. A policy tag maps WLAN profiles to policy profiles. The same WLAN can be mapped to different policy profiles via different policy tags. Different APs can be mapped to two different policy tags on the same C9800, allowing flexible WLAN and policy configurations independent of site boundaries.

When a client roams within a WLAN across two APs mapped to different policy tags, two roaming scenarios may occur:

• Same WLAN profile, same policy profile (name and content), but different policy tags: The roaming will be seamless. Tag name or tag string does not influence roaming.
• Same WLAN profile, different policy profile (either name or content): The client roam goes through full authentication and DHCP. By design, different policy profile configurations usually mean the client policy needs revaluation. Starting with IOS-XE release 17.3, the wireless client vlan-persistent feature enables seamless fast secure roaming across policy profiles if 17 other parameters can be different on the two policy profiles but would still result in seamless fast secure roaming.

Inter-Controller Roaming

Mobility Peering and Full-Mesh Configuration

In a local mode deployment of multiple C9800s, clients can roam across APs that are registered to different C9800s through inter-controller roaming. For clients to roam across controllers, the C9800s must be aware of each other through a full-mesh configuration called a mobility peer. Each mobility peer requires the MAC address, IP address of the Wireless Management Interface (WMI), and mobility group name of the peer C9800 obtained from the mobility peer configuration. On a C9800 local mode deployment, a mobility group defines the boundary for sharing security context and PMK cache of wireless clients between controllers. Fast secure roaming occurs within a mobility group for local mode.

Clients can roam between two local C9800s in different mobility groups provided they are defined in each other's mobility domain or list. However, this is a case of inter-mobility-group roaming, and the client undergoes a full authentication while keeping its IP address.

Layer 2 Roaming

If the C9800 that the client is roaming to supports the same operational VLAN as the C9800 from which the client is roaming from, the client roam is Layer 2. When the client roams to an AP registered to a new C9800 other than the one it is on, the new C9800 exchanges mobility messages with the original C9800, and the client database entry with all its context is moved to the new controller and deleted from the original WLC.

The client retains its IP address, and the C9800 continues to forward traffic for the client. The 802.11r and all fast secure roaming optimizations discussed with this roam are supported. For C9800 form factors like C9800-CL (small) and C9800-L, all roams are intra-WNCd roams.

Note that the C9800 uses the VLAN ID only to determine the type of roam. If a deployment has two C9800s configured with the same VLAN ID but the VLAN is mapped to two different subnets, then the roam across those two C9800s is still treated as Layer 2 roam. The client context is moved with the client holding on to its IP address, and all client traffic post-roam gets blackholed until an idle timeout or a session timeout or the user triggers client deletion and fresh association to get a new IP address.

Layer 3 Roaming

If the C9800 that the client is roaming to supports a different operational VLAN than the C9800 it is roaming from, the client roam is Layer 3. Mobility messages are exchanged between the two C9800s when the client roams. The client database entry is not moved to the new C9800, but a copy of the client entry is created on the roam to C9800. Further, the client entry is marked as "foreign" on the new roam to C9800 (also called foreign WLC) and as "anchor" in the roam from WLC (called anchor WLC). The client retains the IP address it received when it was associated with the original C9800. All client traffic is tunneled from the Foreign C9800 to the Anchor C9800, which then forwards it to the wired infrastructure.

Note that in the case of Layer 3 roaming, if ACL and QoS profiles are in use, either due to configuration on a policy profile or obtained via AAA override, the QoS policy gets applied on the Foreign C9800, whereas the ACL policy gets applied on the Anchor C9800.

Static IP Client Mobility

If clients are assigned static IP addresses and they roam across C9800s or across policy tags where the same subnet as the static IP is not present, the clients are not able to connect to the wireless network. Enabling this feature anchors the static IP client traffic back to the controller whose wired infrastructure supports the subnet of the static IP.

This feature works only in centrally switched SSIDs and when the client is associated with Open, PSK, or dot1x SSID. It mandates that the feature be enabled on all the C9800s in the mobility list. It is mutually exclusive with the auto anchoring feature and IBCM with AireOS WLC. To configure on the C9800 GUI, navigate to Configuration > Tags and Profiles > Policy Profile > Mobility and select Static IP Mobility.

Auto-Anchor Mobility (Guest Tunnel)

When you need to provide wireless guest access in an enterprise deployment, one major design requirement is to provide segregation of guest traffic from all other VLANs. Auto anchoring refers to an intentional way of tunneling clients on a WLAN to a specific anchor WLC, which is then responsible for forwarding the traffic out to the wired infrastructure. In the case of guest access, this anchor WLC is usually located in the DMZ area of the network, thereby achieving the desired segregation. This feature is sometimes referred to as guest tunneling, which is a misnomer. Wireless guest access is the more common use case for auto anchoring, but the feature is not limited to wireless.

Auto anchoring requires that these parameters match between foreign and anchor WLC:

• WLAN profile > Security settings
• Policy profile > DHCP settings
• Webauth parameter-map type

Auto anchoring can be enabled as shown in the GUI from the C9800 by navigating to Configuration > Tags and Profiles > Policy Profile > Mobility, then selecting Export Anchor, and finally selecting Anchor IP from the available list. Note that the foreign WLC points to the anchor WLC wireless management IP, whereas the anchor WLC points to itself.

Configuring Secure Mobility Tunneling on a C9800

Mobility Peering and CAPWAP Tunnels

When two C9800s are defined in each other's mobility list, they communicate using CAPWAP over User Datagram Protocol (UDP) ports 16666 and 16667 to establish a secure tunnel between each other. The control channel of the tunnel is always DTLS (Dynamic Transport Layer Security) encrypted, whereas the data channel can be optionally encrypted through explicit configuration. This is called secure mobility, and this tunnel is used to exchange mobility messages like mobility announce, mobility handoff, and many more to provide seamless client roaming.

Each C9800 can have a maximum of 72 members in its mobility domain, across all mobility groups. However, within a mobility group, only 24 WLCs are allowed. On the C9800, the mobility group is identified by a mobility group name that is part of the Day 0 configuration wizard. If no custom mobility group name is defined, the C9800 boots up with the mobility group name "default." You can edit the mobility group name anytime on the C9800 GUI by navigating to Configuration > Wireless > Mobility > Define Mobility Group Name.

Mobility Group Configuration Fields

The following configuration fields are relevant:

Configuring Mobility Peers

To define mobility peers for the C9800 in its mobility domain or list, navigate to Configuration > Wireless > Mobility > Peer Configuration and enter the MAC address, IPv4/IPv6 address, and Mobility Group Name of the peer C9800 obtained from the Mobility > Global Configuration tab of the peer. This configuration needs to be done on both the local C9800 and peer C9800 and repeated for all the peers in the mobility domain.

Additional configuration fields are available:

• Data Link Encryption: Only the mobility control tunnel is DTLS encrypted by default. This field allows you to enable DTLS encryption for the mobility data tunnel. This configuration needs to be enabled on both the local and peer for encryption and decryption to occur.
• SSC Hash: The DTLS tunnel uses a manufacturer-installed certificate (MIC) in the case of hardware form factors of C9800. However, virtual form factor C9800-CL has a self-signed certificate (SSC). The SSC hash is used as an additional validation when peering with the C9800-CL.

You can verify mobility tunnel status by navigating to Configuration > Wireless > Mobility > Peer Configuration. The equivalent CLI is show wireless mobility summary. You can view mobility tunnel statistics by navigating to Monitoring > Wireless > Mobility. The CLI equivalent to see the statistics is show wireless stats mobility and show wireless stats mobility messages.

C9800 to AireOS Inter-Release Controller Mobility (IRCM)

Next-Generation and Legacy WLC Coexistence

A C9800 running IOS-XE is termed a next-generation WLC. Legacy WLCs refer to AireOS WLCs. It is a common requirement to have AireOS and C9800 WLCs coexist because the network is migrated from AireOS to IOS-XE. In a hybrid deployment, it is expected to have clients be able to seamlessly roam across these WLCs that differ in hardware and software. This is referred to as Inter-Release Controller Mobility.

AireOS also supports mobility and client roaming. AireOS WLCs use UDP port 16666 for the control tunnel but use IP protocol 97 (that is, Ethernet over IP, or EoIP, tunnels) for the mobility data tunnel. To peer with a C9800, the AireOS WLC needs to support the secure mobility feature, available starting with AireOS release 8.8.1110. The AireOS WLCs that are supported in these releases are Cisco 3504, Cisco 5520, and Cisco 8540.

However, a large deployment base exists for Cisco 5508 and Cisco 8510. To accommodate these deployments, a special 8.5 IRCM code is available. Note that other AireOS WLCs like Cisco 2504, Cisco WiSM2, and Cisco FlexConnect 7510 do not support the IRCM release and hence cannot create a mobility tunnel with C9800.

IRCM Roaming Behavior

The important point that you need to remember is that when a client performs IRCM roaming, it is always Layer 3, irrespective of the client VLAN configured on either AireOS WLC or C9800. When the client first connects to the network, whichever WLC it lands on serves as the anchor WLC. This means the client gets an IP address from the VLAN/subnet associated to the WLC that it first connects to. If the client VLAN/subnet is different on the two WLCs, you need to make sure that you don't have clients with static IP because that would be valid on only one of the WLCs. When guest tunnels are used with anchor and foreign WLCs, it is also possible to have an AireOS WLC serve as an anchor to the C9800 foreign, and vice versa. To define the AireOS WLC and C9800 as mobility peers, you need to use the same steps described for Figure 6-31. The only exception is that the AireOS WLC does not have secure mobility enabled by default and needs explicit configuration, as shown in Figure 6-33. Also note that AireOS WLCs mark mobility tunnel traffic with DSCP 0. However, this mismatch does not prevent a tunnel from coming up.

Roaming Optimization Features

802.11k Neighbor Reports

An unsolicited optimized roaming request means wireless clients are expected to scan RF and roam to AP with the highest signal. However, some clients have displayed sticky behavior where they stay with the AP to which they are associated, even when a neighboring AP provides a stronger signal. To address this problem, the C9800 supports optimized roaming where the RSSI of the client data packets and data rate are monitored, and the client is proactively disassociated. The 802.11v BSS Transition Management Request enhances optimized roaming by informing the client of an imminent disassociation and providing a list of APs to roam to.

To configure 802.11v on the C9800 GUI, navigate to Configuration > Tags and Profiles > WLAN Profile > Advanced > 802.11v and select BSS Transition.

Imminent Disassociation

An 802.11v BSS Transition Management Request sent by an AP to a client is only a suggestion. The C9800 provides a configuration option called Imminent Disassociation for you to force the clients to disassociate if the client does not associate with another AP within a defined window of time. Clients are informed of imminent disassociation via the 802.11v BSS Transition Management Request frame. Note that the request frame sent by AP in unsolicited request use case cannot leverage imminent disassociation. On the C9800, imminent disassociation can be configured only from CLI using #bss-transition disassociation-imminent under a specific WLAN profile.

Key Takeaways

• Client roaming in the C9800 maintains a database entry containing the client's MAC, IP, security context, QoS context, and AP association details. This entry must be preserved or updated at each roam.
• Intra-controller roaming keeps clients on one C9800 and can occur within the same or different WNCd instances depending on site tag configuration. PMK cache and fast roaming are supported across all intra-controller scenarios.
• Inter-controller roaming involves full-mesh mobility peer configuration with proper MAC, IP, and group name entries. Layer 2 roaming maintains IP address; Layer 3 roaming creates an anchor-foreign relationship and requires tunneling.
• Secure mobility tunnels use CAPWAP over UDP ports 16666/16667 with mandatory DTLS encryption for the control channel. Keep alive intervals and DSCP marking ensure tunnel health and prioritization.
• Static IP mobility anchors clients to the controller supporting their subnet; auto-anchor mobility (guest tunneling) segregates traffic through a designated anchor WLC.
• C9800-to-AireOS IRCM enables hybrid deployments, though always treated as Layer 3 roaming. Supported AireOS platforms include Cisco 3504, 5520, and 8540; Cisco 5508 and 8510 require special 8.5 IRCM code.
• Roaming optimization through 802.11k, 802.11v, and 802.11w-FT reduces roam latency to sub-millisecond timescales, critical for delay-sensitive applications like voice over wireless.