Catalyst 9800 Roaming Scenarios: Intra-Controller vs Inter-Controller Architecture

On the Cisco Catalyst 9800, roaming behavior depends on controller boundaries, Site Tag and WNCd placement, policy-profile compatibility, the client VLAN, the mobility configuration, and whether APs operate in Local or FlexConnect mode.

Understanding these boundaries is essential when designing a WLAN for predictable handoffs, especially for voice, real-time collaboration, and other latency-sensitive applications.

1. Intra-Controller Roaming

Intra-controller roaming occurs when a client moves between two APs joined to the same physical or virtual C9800 controller. The controller updates the client’s point of attachment and maintains or rebuilds the necessary security and forwarding state.

                         SAME C9800 WLC
                                |
             +------------------+------------------+
             |                  |                  |
             v                  v                  v
       Same WNCd          Different WNCd      Different Policy
       Same Site Tag      Usually different  Profile / Policy
                          Site Tags           considerations

Intra-WNCd Roaming

APs that share the same custom Site Tag are managed by the same WNCd process. A roam between those APs stays within the same client-control process, avoiding inter-process synchronization.

• Database flow: the controller updates the client entry with the new AP association.
• Client addressing: the client normally retains its IP address when the WLAN and forwarding policy remain compatible.
• Fast secure roaming: 802.11r and OKC can operate within the roaming domain when correctly configured and supported by the client.
• 802.11k/v: these protocols assist roaming but do not perform the roam themselves.

WNCd Instances and Site-Tag Placement

WNCd is the primary IOS XE process for AP and client sessions. The number of WNCd instances varies by platform.

Verify the active processes with:

C9800# show processes platform | include wncd

The default-site-tag consideration

For Local mode APs on a multi-WNCd controller, APs using default-site-tag can be distributed across WNCd instances in round-robin fashion. This increases the chance that a client roam requires inter-process communication. Custom Site Tags keep all APs in the same tag on one WNCd and make placement more predictable.

Roaming Across Site Tags

For centrally associated Local mode APs, seamless roaming with 802.11r and OKC is supported across Site Tags. Starting with IOS XE 17.6.1, clients roaming across Site Tags can also benefit from 802.11k/v; in 17.6.1 the administrator must ensure the SSID is present on neighboring APs, while the check becomes automatic from 17.7.1.

Cisco recommends approximately 500 Local mode APs per Site Tag as a performance-design reference, not as a universal hard limit. Platform-specific supported maxima can be higher.

FlexConnect Site Tags

For FlexConnect, the Site Tag defines the fast secure roaming domain because client key distribution occurs among APs in the same Flex Site Tag. Roaming between different Flex Site Tags requires full reauthentication.

• Use a custom Flex Site Tag for each actual roaming location.
• Do not use default-site-tag when FlexConnect fast secure roaming is required.
• The traditional limit is 100 APs per Flex Site Tag for seamless roaming.
• From IOS XE 17.8.1, FlexConnect High Scale Mode can support up to 300 APs and 3,000 clients per Site Tag when pmk propagate is enabled in the Flex profile.

C9800(config)# wireless profile flex BRANCH-FLEX
C9800(config-wireless-flex-profile)# pmk propagate

Roaming Across Policy Profiles

By default, the C9800 does not permit seamless roaming for the same WLAN when it is mapped to different policy profiles. The client disconnects and reauthenticates.

The roaming-across-policy-profile feature is enabled globally with:

C9800(config)# wireless client vlan-persistent

When enabled, the client retains its original VLAN and IP address. The controller can apply the new profile’s supported attributes, except that the original VLAN remains in use.

Use VLAN persistence only when the design genuinely requires roaming across compatible policy profiles. For new deployments, a simpler addressing and policy design is usually easier to operate. A larger subnet may be appropriate in some environments, but subnet size must be based on broadcast-domain scale, failure domains, DHCP capacity, and security requirements rather than a universal /22 or /21 rule.

2. Inter-Controller Roaming

Inter-controller roaming occurs when the client moves between APs joined to different C9800 controllers. The controllers must be configured as mobility peers, with reachable mobility control and data paths.

• Same mobility group name: required when a shared fast-roaming cache is needed for mechanisms such as 802.11r, CCKM, PKC, or OKC.
• Different mobility group names: controllers can still be mobility peers within the broader mobility domain, but they do not share the same fast-roaming cache, so a full authentication may be required.
• Connectivity: UDP 16666 and 16667 must be permitted between controller management interfaces when they are separated by a routed network.

Layer 2 vs. Layer 3 Inter-Controller Roaming

Layer 2 Inter-Controller Roaming

On C9800-to-C9800 mobility, the Layer 2 versus Layer 3 decision is based on the client VLAN ID. For an L2 roam, the client entry moves to the target controller and traffic is forwarded locally by the target controller.

The Same-VLAN-ID, Different-Subnet Trap

If both controllers use VLAN 10 but VLAN 10 represents different IP subnets, the C9800 can classify the transition as Layer 2 because the VLAN IDs match. The client can retain an address that is unusable on the target broadcast domain.

Layer 3 Inter-Controller Roaming

When the client VLAN IDs differ, the original controller keeps an Anchor entry and the target controller creates a Foreign entry. The client keeps its original IP address, and traffic is carried through the inter-controller mobility data tunnel back to the anchor for delivery to the original wired subnet.

Client -> AP -> Foreign C9800 == mobility data tunnel ==> Anchor C9800 -> Wired subnet

Auto-Anchor Mobility

Auto-anchor mobility is a static foreign/anchor design commonly used for guest access. Internal controllers act as foreign controllers and tunnel guest traffic to an anchor controller, often placed in a DMZ. The security outcome still depends on the firewall, routing, policy, and anchor design; the tunnel alone does not guarantee internet-only isolation.

Roaming Scenario Summary

3. Catalyst 9800 Roaming Design Blueprint

• Align custom Local mode Site Tags with real roaming domains where practical.
• Balance Site Tags across WNCd processes instead of placing the entire deployment on one WNCd.
• Treat 500 Local mode APs per Site Tag as a performance recommendation, and check the platform-specific maximum.
• Use one custom Flex Site Tag per FlexConnect roaming location.
• Enable pmk propagate only when using the documented FlexConnect High Scale design.
• Keep WLAN security and policy settings consistent across mobility peers.
• Use the same mobility group name where fast inter-controller roaming is required.
• Keep identical VLAN IDs mapped to the same subnet across C9800 mobility peers.
• Prefer the same recommended IOS XE release across mobility peers where operationally possible.

Feature Recommendations: What Is Generally Safe?

Optimized Roaming

Cisco’s current best-practices guide recommends leaving legacy Optimized Roaming disabled; it is disabled by default. Modern designs normally rely on standards-based 802.11k, 802.11v, and 802.11r behavior.

Aggressive Load Balancing

This is not an unconditional “always disable” setting. Cisco states that, if load balancing is required, the global window should be five clients or higher, and the feature should be used only in good-coverage environments because it may negatively affect voice or interactive video. Use it only after validating the RF design and client behavior.

802.11k and 802.11v

Cisco recommends enabling 802.11k and keeping 802.11v BSS Transition, BSS Max Idle, and Directed Multicast Service enabled. Do not treat every optional 11k/v control as universally appropriate; validate against the actual client population.

802.11r

For a mixed client population, Cisco recommends 802.11r mixed mode: enable FT and offer both FT and non-FT AKMs. For best interoperability, Cisco’s current guidance is to keep Over-the-DS disabled, which means using over-the-air FT behavior.

Final Takeaway

The fastest C9800 roam is not created by one checkbox. It comes from aligning the RF roaming domain, Site Tags, WNCd placement, policy profiles, VLAN plan, mobility-group design, software release, and client capabilities.

Use custom Site Tags deliberately, keep policy and VLAN mappings consistent, verify actual WNCd placement, and treat 802.11k/v/r as client-assistance and key-management tools rather than guarantees. For inter-controller mobility, distinguish clearly between L2 context movement, L3 foreign/anchor tunneling, and static guest anchoring.

References

• Cisco Catalyst 9800 Series Configuration Best Practices
• Cisco IOS XE 17.18.x: Client Roaming Across Policy Profile
• Configure Mobility Topologies on Catalyst 9800 WLCs