Wireless Roaming – Intra & Inter-Controller

1. What Is Wireless Roaming?

Wireless roaming is the process by which a client device (laptop, phone, tablet) moves from the coverage area of one Access Point (AP) to another without losing its network connection. From the client's perspective, the transition should be seamless — the IP address is maintained, active sessions (VoIP calls, VPN tunnels, video streams) remain uninterrupted, and re-authentication latency is minimised.

In a centralised CAPWAP architecture (where all APs are managed by a Wireless LAN Controller — WLC), the WLC plays a critical role in roaming. It maintains the client's session state, coordinates the handoff between APs, and in the case of inter-controller roaming, communicates with peer WLCs via a mobility tunnel to preserve the client's context.

Roaming Type	APs Involved	WLCs Involved	IP Address	Complexity
Intra-Controller (L2)	Different APs	Same WLC	Retained	Lowest
Inter-Controller L2	Different APs	Different WLCs, same subnet	Retained	Medium
Inter-Controller L3	Different APs	Different WLCs, different subnets	Retained via tunnel	Highest

2. The Basic Roaming Process

Whether roaming is intra-controller or inter-controller, the client follows a similar sequence at the 802.11 layer. The key difference is what happens behind the scenes on the infrastructure side.

2.1 Client-Side Roaming Decision

  Client roaming decision process:

  1. Client is associated with AP-1 (signal: -65 dBm)
  2. Client monitors neighbour APs via passive/active scanning
  3. AP-1 signal drops to roaming threshold (e.g., -75 dBm)
  4. Client finds AP-2 with better signal (e.g., -60 dBm)
  5. Client initiates roam:
       a. Sends 802.11 Probe Request to AP-2
       b. AP-2 responds with Probe Response
       c. Client sends Authentication Request to AP-2
       d. AP-2 sends Authentication Response (Open System)
       e. Client sends Association Request / Reassociation Request to AP-2
          ↑ Note: Reassociation Request (not Association) signals a roam
             — it includes the BSSID of the previous AP
       f. AP-2 acknowledges with Reassociation Response
  6. Client is now associated with AP-2
  7. Infrastructure handles the back-end handoff (context transfer)

Roaming is client-driven: The decision of when to roam is made entirely by the client device, not the AP or WLC. The WLC cannot force a client to roam — it can only make the transition easier once the client decides to move. This is the root cause of the sticky client problem: a client may cling to a distant AP even when a closer one is available, because it never decides the signal is bad enough to trigger a roam.

3. Intra-Controller Roaming

Intra-controller roaming occurs when a client moves from one AP to another AP that is managed by the same WLC. This is the simplest roaming scenario because the WLC already has all context for the client and no communication with another controller is required.

  Intra-Controller Roaming Topology:

                     ┌──────────────────────────────┐
                     │         WLC-1                │
                     │  (manages AP-1 and AP-2)     │
                     └───────┬──────────────┬───────┘
                             │ CAPWAP       │ CAPWAP
                         ┌───▼───┐      ┌───▼───┐
                         │ AP-1  │      │ AP-2  │
                         │ (old) │      │ (new) │
                         └───────┘      └───────┘
                             ←── Client moves ──►

  Roam steps (WLC perspective):
  1. Client reassociates to AP-2 — AP-2 notifies WLC via CAPWAP
  2. WLC already holds client's MAC, IP, VLAN, security context
  3. WLC updates its internal database: client now on AP-2
  4. WLC flushes the old AP-1 binding — no more traffic sent there
  5. Traffic flows: Client ↔ AP-2 ↔ CAPWAP ↔ WLC ↔ Network

  No IP change, no re-authentication needed (if using OKC/802.11r),
  no communication with any other device outside WLC-1.

Intra-controller roaming is fast and transparent — the WLC handles the entire handoff internally. With fast roaming techniques (OKC or 802.11r), the total transition time is typically under 50 ms, which is imperceptible to VoIP calls and video streams.

4. Inter-Controller Roaming

Inter-controller roaming occurs when a client moves from an AP managed by one WLC to an AP managed by a different WLC. This requires the two WLCs to communicate with each other via a mobility tunnel to transfer the client's session context. The two WLCs must be in the same mobility group.

4.1 Mobility Groups

A mobility group is a set of WLCs that are configured to trust each other for roaming. When a client roams between WLCs in the same mobility group, the controllers exchange the client's security credentials, IP address, VLAN, and QoS policy via a mobility tunnel (EtherIP over UDP 16666, or CAPWAP).

  Inter-Controller Roaming Topology:

  ┌──────────────┐  Mobility Tunnel  ┌──────────────┐
  │   WLC-1      │◄─────────────────►│   WLC-2      │
  │  (Anchor)    │  (UDP 16666 /     │  (Foreign)   │
  │              │   CAPWAP)         │              │
  └──────┬───────┘                   └──────┬───────┘
         │ CAPWAP                           │ CAPWAP
     ┌───▼───┐                         ┌───▼───┐
     │ AP-1  │                         │ AP-2  │
     │ Bldg A│                         │ Bldg B│
     └───────┘                         └───────┘
          ← ─ ─ ─  Client roams  ─ ─ ─ ►

  Mobility group name must match on both WLCs.
  Each WLC must have the other's MAC address and IP in its mobility list.

4.2 Layer 2 vs Layer 3 Inter-Controller Roaming

Whether inter-controller roaming is Layer 2 or Layer 3 depends on whether the two WLCs serve the client on the same or different IP subnets.

Aspect	Layer 2 Inter-Controller Roaming	Layer 3 Inter-Controller Roaming
Subnet	Both WLCs serve the SSID on the same subnet (same VLAN)	WLC-1 and WLC-2 serve the SSID on different subnets
IP address change	No — client keeps its IP address; no DHCP renewal needed	No — client keeps its original IP via a mobility tunnel (asymmetric routing)
Mechanism	Context transfer via mobility tunnel; client database entry moved from WLC-1 to WLC-2	WLC-1 becomes the Anchor; WLC-2 becomes the Foreign; client traffic tunnelled back to Anchor for routing
Anchor/Foreign concept	Not required — client entry fully moves to WLC-2	Required — Anchor retains the client's original IP context; Foreign handles the local AP association
Traffic path	Client ↔ AP-2 ↔ WLC-2 ↔ Network (direct)	Client ↔ AP-2 ↔ WLC-2 (Foreign) ↔ Tunnel ↔ WLC-1 (Anchor) ↔ Network

5. Layer 3 Roaming – Anchor and Foreign WLC

Layer 3 roaming introduces the Anchor/Foreign concept. When a client roams from WLC-1's subnet to WLC-2's different subnet, the client cannot simply be given a new IP address (that would break active sessions). Instead, the original WLC (now the Anchor) retains the client's IP address and subnet binding, while the new WLC (the Foreign) tunnels all client traffic back to the Anchor.

  Layer 3 Roaming – Data Path:

  Client IP: 192.168.10.50  (assigned by WLC-1 on subnet 192.168.10.0/24)
  Client roams to AP-2 on WLC-2 which serves 192.168.20.0/24

  Without tunnelling: client would need a new IP → all sessions break ✗

  With Anchor/Foreign tunnelling:
  ┌────────────────────────────────────────────────────────────────────┐
  │                                                                    │
  │  Client (192.168.10.50)                                           │
  │      │ 802.11                                                      │
  │  AP-2 ──CAPWAP──► WLC-2 (Foreign, 192.168.20.0/24 network)       │
  │                       │                                            │
  │                       │  EtherIP tunnel (UDP 16666)               │
  │                       ▼                                            │
  │                   WLC-1 (Anchor, 192.168.10.0/24 network)         │
  │                       │                                            │
  │                       ▼                                            │
  │                   Default Gateway / Internet                       │
  │                                                                    │
  │  Client IP 192.168.10.50 is preserved ✓                           │
  │  Traffic flows via Foreign → Anchor → network (asymmetric path)   │
  └────────────────────────────────────────────────────────────────────┘

  From the network's perspective, the client is still on 192.168.10.0/24
  — routers have no idea the client has physically moved to another building.

5.1 Static (Explicit) Mobility Anchors

A related but separate concept is the static mobility anchor (also called a guest anchor). In this design, a WLC is purposely designated as the anchor for a specific SSID (e.g., a guest WLAN) regardless of where the client associates. All traffic for that SSID is tunnelled to the anchor WLC — typically placed in a DMZ — ensuring guest traffic never touches the internal network directly.

  Static Anchor (Guest WLAN) Topology:

  ┌──────────────┐  EtherIP Tunnel  ┌────────────────────────────┐
  │  Internal    │◄────────────────►│  Guest Anchor WLC          │
  │  WLC-1/WLC-2 │                  │  (in DMZ, VLAN 999)        │
  │  (Foreign)   │                  │  Guest clients get IP from │
  └──────┬───────┘                  │  192.168.99.0/24 (DHCP)    │
         │ APs                      └──────────────────────────┬─┘
         │                                                     │
  [All APs — campus-wide]                               [Internet / DMZ]

  Any guest client regardless of which campus AP they connect to →
  traffic tunnelled to Anchor WLC in DMZ → no guest traffic on internal VLANs

6. Fast Roaming – OKC and 802.11r

Standard roaming with 802.1X/EAP authentication involves a full four-way handshake and potentially a complete EAP exchange each time the client roams. This can take 200–500 ms — unacceptable for VoIP calls (which tolerate only ~50 ms of interruption). Fast roaming mechanisms cache security credentials so the full EAP exchange can be skipped on subsequent associations.

6.1 Standard Roaming Authentication Overhead

  Standard 802.1X Roaming (no fast roaming):

  Client associates to AP-2 during roam:
  Step 1:  802.11 Probe → Association (20–30 ms)
  Step 2:  Full EAP exchange with RADIUS server:
           EAP-Request → EAP-Response → RADIUS challenge/response (100–300 ms)
  Step 3:  4-Way Handshake for PTK derivation (20–30 ms)
  ─────────────────────────────────────────────────────────
  Total:   140–360 ms  ← VoIP quality degrades

  With fast roaming (OKC or 802.11r):
  Step 1:  802.11 Probe → Association (20–30 ms)
  Step 2:  SKIPPED — cached PMK/PTK used (0 ms EAP exchange)
  Step 3:  Abbreviated 4-Way or FT exchange (10–20 ms)
  ─────────────────────────────────────────────────────────
  Total:   30–50 ms   ← VoIP-safe

6.2 OKC – Opportunistic Key Caching

OKC (Opportunistic Key Caching), also called Proactive Key Caching (PKC), allows a client that has already authenticated with one AP to reuse the derived Pairwise Master Key (PMK) when it roams to a new AP managed by the same WLC. The WLC caches and distributes the PMK to all APs in the mobility group, so when the client roams the full EAP exchange is skipped.

  OKC / PKC Process:

  Step 1:  Client authenticates to AP-1 via full 802.1X / EAP exchange
           RADIUS server derives PMK → WLC caches PMK for this client

  Step 2:  WLC proactively distributes client's PMKID + PMK to all APs
           in the mobility group (or the target AP on association)

  Step 3:  Client roams to AP-2:
           Client presents PMKID in the Association Request
           AP-2 / WLC recognises PMKID → PMK already cached
           Skip full EAP → proceed directly to 4-Way Handshake

  Step 4:  New PTK derived from cached PMK in ~10–20 ms
           Client is associated and authenticated — VoIP call uninterrupted ✓

  OKC works within a single WLC or across WLCs in the same mobility group.
  Requires: WPA2-Enterprise; OKC enabled on WLC and client supports it.

6.3 802.11r – Fast BSS Transition (FT)

IEEE 802.11r (Fast BSS Transition) is a Wi-Fi standard that redesigns the association handshake specifically for fast roaming. Rather than a separate EAP exchange on each new AP, 802.11r pre-distributes the security keys and allows the client to negotiate the new key material within the reassociation frames themselves — eliminating the EAP round trip entirely.

  802.11r Fast BSS Transition (FT) Key Hierarchy:

  PMK-R0 (top-level key, derived from EAP exchange, held by R0KH)
    │
    └── PMK-R1 (per-AP key, derived from PMK-R0, held by R1KH on each AP)
          │
          └── PTK (per-session pairwise key, derived via FT 4-Way on association)

  R0KH = PMK-R0 Key Holder (the WLC or original authenticator)
  R1KH = PMK-R1 Key Holder (each AP in the mobility domain)

  FT Roaming Flow (Over-the-Air FT):
  1. Client scans and finds AP-2
  2. Client sends FT Auth Request to AP-2 (contains R0KH-ID, S1KH-ID, SNONCE)
  3. AP-2 contacts WLC to obtain PMK-R1 for this client
  4. AP-2 sends FT Auth Response to client (contains ANonce)
  5. Client sends FT Reassociation Request (PTK negotiated inline)
  6. AP-2 sends FT Reassociation Response — client is associated ✓
  Total: ~30–50 ms

  FT Over-the-DS (pre-authentication to target AP via current AP):
  Client can initiate FT with AP-2 while still connected to AP-1
  → zero interruption transition possible

6.4 OKC vs 802.11r Comparison

Feature	OKC (Opportunistic Key Caching)	802.11r (Fast BSS Transition)
Standard	Not formally standardised — vendor implementation (Cisco, Broadcom)	IEEE 802.11r — ratified standard (2008), part of 802.11-2012
Key mechanism	Caches and re-uses PMK; skips full EAP on roam	Hierarchical key structure (PMK-R0/R1); FT key negotiated inline
Client support	Widely supported by modern clients; no explicit 802.11r support needed	Requires both the client and AP to explicitly support 802.11r
Compatibility	Backward compatible — non-OKC clients fall back to full EAP	Non-802.11r clients must use a separate (non-FT) SSID or are excluded
Roaming latency	~50–100 ms (eliminates EAP exchange, still requires 4-way handshake)	~30–50 ms (FT exchange inline with association — fastest option)
Pre-authentication	WLC pushes PMK to APs proactively	Over-the-DS FT allows pre-authentication while still associated to old AP
Cisco WLC config	Enabled per-WLAN: WLAN → Security → Layer 2 → Enable OKC	Enabled per-WLAN: WLAN → Advanced → 802.11r Fast Transition
Use case	Default recommendation for most WPA2-Enterprise deployments	VoIP-heavy environments; voice-grade Wi-Fi with certified handsets

7. Roaming Topology Summary – All Scenarios

  ════════════════════════════════════════════════════════════════════════
  SCENARIO 1 — Intra-Controller Roaming (L2)
  ════════════════════════════════════════════════════════════════════════
  AP-1 (VLAN 10) ──► AP-2 (VLAN 10) — same WLC
  Client IP: retained   | Re-auth: No (with OKC/802.11r)
  WLC action: updates internal client table, notifies old AP to flush

  ════════════════════════════════════════════════════════════════════════
  SCENARIO 2 — Inter-Controller Layer 2 Roaming
  ════════════════════════════════════════════════════════════════════════
  AP-1 on WLC-1 (VLAN 10) ──► AP-2 on WLC-2 (VLAN 10, same subnet)
  Client IP: retained   | Re-auth: No (with OKC/802.11r)
  WLC action: WLC-1 pushes client context to WLC-2 via mobility tunnel
              Client entry moves from WLC-1 to WLC-2 (Export/Import)
  Traffic path: Client → AP-2 → WLC-2 → Network (direct)

  ════════════════════════════════════════════════════════════════════════
  SCENARIO 3 — Inter-Controller Layer 3 Roaming (Anchor/Foreign)
  ════════════════════════════════════════════════════════════════════════
  AP-1 on WLC-1 (VLAN 10, 192.168.10.x) ──► AP-2 on WLC-2 (VLAN 20, 192.168.20.x)
  Client IP: retained via tunnel   | Re-auth: No (with OKC/802.11r)
  WLC action: WLC-1 = Anchor (retains IP binding)
              WLC-2 = Foreign (tunnels traffic to WLC-1)
  Traffic path: Client → AP-2 → WLC-2 (Foreign) → Tunnel → WLC-1 (Anchor) → Network

  ════════════════════════════════════════════════════════════════════════
  SCENARIO 4 — Static Anchor (Guest WLAN)
  ════════════════════════════════════════════════════════════════════════
  Any AP anywhere → always tunnelled to dedicated Guest Anchor WLC in DMZ
  Purpose: isolate guest traffic from internal network completely
  Anchor WLC: placed in DMZ VLAN; DHCP from guest pool; internet access only

8. Common Roaming Problems

8.1 Sticky Client Problem

A sticky client (also called a non-roaming client) refuses to roam to a better AP even when its current signal is very weak. Because roaming is client-driven, the infrastructure cannot force it. Sticky clients cause poor performance and can keep a distant AP's radio busy with low-data-rate retransmissions.

  Sticky Client Scenario:

  AP-1 (far away)   Client   AP-2 (nearby)
  RSSI: -85 dBm  ←──────→  RSSI: -55 dBm

  Client should roam to AP-2 but stubbornly stays on AP-1.

  Why this happens:
  • Client OS does not trigger roam until signal drops very low (e.g., -90 dBm)
  • Client is a power-saving device that avoids the re-association overhead
  • No fast roaming configured — client avoids roam to skip EAP exchange

  Mitigations:
  • Cisco WLC "Client Band Select" and "Aggressive Load Balancing"
  • 802.11v BSS Transition Management (network can suggest better AP — not force)
  • 802.11k Neighbour Report (client gets optimised scan list)
  • Tune AP transmit power — lower power → smaller cells → fewer sticky situations
  • Enable fast roaming (OKC / 802.11r) — reduces the cost of roaming

8.2 Other Common Roaming Issues

Problem	Cause	Fix
Client loses IP on roam	Layer 3 roam occurring but Anchor/Foreign not configured; client gets DHCP on new subnet and drops existing sessions	Ensure both WLCs are in the same mobility group; verify L3 roaming with Anchor/Foreign is active; check mobility tunnel status
Roaming takes too long (VoIP drops)	Full EAP re-authentication on each roam; OKC or 802.11r not enabled	Enable OKC per-WLAN on Cisco WLC; or enable 802.11r for VoIP-specific SSIDs; confirm client device supports the fast roaming mechanism
Client fails to roam at all	Coverage gap between APs; client has no AP with acceptable signal; or client is misconfigured for the SSID security type	Perform wireless site survey; adjust AP placement and transmit power; use WLC RF profiles to optimise coverage
Inter-controller roam fails	Mobility group name mismatch; WLC not in peer's mobility list; firewall blocking UDP 16666 between WLCs	Verify mobility group name matches on all WLCs; add peer WLC IP and MAC to mobility list; open UDP 16666 between WLC management IPs
802.11r causing client failures	Client device does not support 802.11r but connects to an FT-only SSID	Enable both FT and non-FT on the same SSID (Cisco WLC supports mixed mode); or create separate SSIDs — one with 802.11r, one without

9. Verification Commands

Command / Location	What It Shows
`WLC GUI → Monitor → Clients`	All associated clients — current AP, RSSI, SNR, data rates, roaming statistics per client
`WLC GUI → Controller → Mobility → Mobility Groups`	Configured mobility group name, peer WLCs, and tunnel status (UP/DOWN) between controllers
`show mobility summary` (WLC CLI)	Mobility group membership, peer WLC IPs/MACs, and tunnel state
`show client detail <mac>` (WLC CLI)	Full client details — IP address, AP, VLAN, roaming history, security association type (OKC/802.11r/full EAP), anchor/foreign status
`show client roam-history <mac>` (WLC CLI)	Full roaming event history for a specific client — timestamps, APs roamed from/to, roaming latency
`debug client <mac>` (WLC CLI)	Real-time 802.11 association/reassociation events, EAP exchange, mobility tunnel messages for a specific client — verbose, lab use only
`show wlan summary` (WLC CLI)	All configured WLANs with their security, OKC/802.11r settings, and associated client counts
`show ap summary` (WLC CLI)	All joined APs — name, MAC, IP, channel, clients associated, and operational state

10. Key Terms Quick Reference

Term	Definition
Roaming	The process of a wireless client moving from one AP to another while maintaining its network session, IP address, and active connections
Intra-Controller Roaming	Roaming between APs managed by the same WLC; the simplest and fastest roaming type — no external communication required
Inter-Controller Roaming	Roaming between APs managed by different WLCs; requires both WLCs to be in the same mobility group and communicate via a mobility tunnel
Layer 2 Roaming	Inter-controller roam where both WLCs serve the client on the same subnet; client IP is retained and the client database entry is transferred to the new WLC
Layer 3 Roaming	Inter-controller roam where WLCs serve the client on different subnets; Anchor/Foreign tunnelling preserves the client's original IP address
Mobility Group	A set of WLCs configured to trust each other for roaming; they exchange client context via mobility tunnels; mobility group name must match on all members
Mobility Tunnel	A logical tunnel between WLCs (EtherIP over UDP 16666) used to transfer client context during inter-controller roaming
Anchor WLC	In Layer 3 roaming, the original WLC that retains the client's IP address binding; all client traffic is tunnelled to the Anchor for routing to the network
Foreign WLC	In Layer 3 roaming, the new WLC where the client is currently associated; it tunnels the client's traffic to the Anchor WLC
Static Anchor (Guest Anchor)	A WLC designated as the permanent anchor for a specific SSID (e.g., guest); all client traffic is tunnelled to this WLC regardless of physical location — used to isolate guest traffic in a DMZ
OKC / PKC	Opportunistic Key Caching / Proactive Key Caching — fast roaming mechanism that caches the PMK on the WLC and distributes it to APs, allowing clients to skip the full EAP exchange on subsequent associations
802.11r (FT)	IEEE Fast BSS Transition — a standard that embeds key negotiation within the reassociation frames using a hierarchical key structure (PMK-R0/R1), achieving the lowest roaming latency
PMK	Pairwise Master Key — the cryptographic key derived from a successful EAP exchange; cached by OKC so it does not need to be re-derived on every roam
Sticky Client	A client that refuses to roam to a better AP despite having a poor signal on its current AP; caused by the client-driven roaming model where the infrastructure cannot force the transition
CAPWAP	Control and Provisioning of Wireless Access Points — the tunnel protocol between lightweight APs and the WLC that carries both control and data traffic in a centralised WLAN architecture

11. Wireless Roaming – Practice Quiz

1. What is the key difference between intra-controller and inter-controller roaming?

A. Intra-controller roaming requires a mobility tunnel; inter-controller roaming does not B. Intra-controller roaming occurs between APs on the same WLC — no external communication needed; inter-controller roaming involves APs on different WLCs requiring a mobility tunnel between controllers C. Intra-controller roaming always changes the client's IP address; inter-controller roaming preserves it D. Intra-controller roaming requires 802.11r; inter-controller roaming uses OKC

Correct answer is B. Intra-controller roaming is the simplest roaming scenario — all APs involved are managed by the same WLC. The WLC already has the client's full context (IP, VLAN, security, QoS) so no communication with any other device is needed. The WLC simply updates its internal client table to point to the new AP. Inter-controller roaming requires the two WLCs to be in the same mobility group and exchange client context via a mobility tunnel (EtherIP over UDP 16666).

2. A client roams from AP-1 (WLC-1, subnet 192.168.10.0/24) to AP-2 (WLC-2, subnet 192.168.20.0/24). The client keeps its IP address 192.168.10.50. What type of roaming is this and what mechanism preserves the IP?

A. Layer 2 inter-controller roaming — the WLCs are on the same VLAN so no tunnelling is needed B. Intra-controller roaming — the client stays on the same WLC, which is why the IP is kept C. Layer 3 inter-controller roaming — WLC-1 becomes the Anchor (retains the 192.168.10.x binding); WLC-2 becomes the Foreign and tunnels all client traffic back to WLC-1 via a mobility tunnel D. The client received a new DHCP lease on 192.168.20.x that coincidentally matched its old IP

Correct answer is C. This is Layer 3 inter-controller roaming. When a client moves from one subnet to another, it would normally need a new IP address — which would break all active sessions. The Anchor/Foreign mechanism prevents this: WLC-1 (Anchor) retains the client's original IP binding and serves as the routing point, while WLC-2 (Foreign) tunnels all the client's traffic back to WLC-1 via EtherIP over UDP 16666. From the network's perspective, the client never left 192.168.10.0/24.

3. Why is fast roaming (OKC or 802.11r) important for VoIP over Wi-Fi?

A. Standard 802.1X roaming requires a full EAP exchange that takes 200–500 ms — longer than the ~50 ms VoIP can tolerate; fast roaming caches keys so the EAP exchange is skipped, reducing roaming latency to 30–50 ms B. Fast roaming is required to maintain the client's IP address during roaming; without it, the IP changes and the VoIP call disconnects C. OKC increases the Wi-Fi signal strength during roaming, reducing jitter for voice calls D. 802.11r reserves a dedicated radio channel for voice traffic during the roaming transition

Correct answer is A. VoIP is highly sensitive to interruption — most VoIP implementations can tolerate no more than ~50 ms of disruption before a call noticeably degrades or drops. Standard 802.1X roaming requires a complete EAP exchange with the RADIUS server on each new AP association, adding 100–300 ms. Fast roaming (OKC/PKC or 802.11r) pre-caches the derived keys so the EAP round-trip is eliminated, reducing total roam time to 30–50 ms — within VoIP's tolerance window.

4. For inter-controller roaming to work between WLC-1 and WLC-2, what must be configured on both controllers?

A. Both WLCs must be on the same physical VLAN with no Layer 3 boundaries between them B. Both WLCs must run the same Cisco IOS software version C. A static route from WLC-1 to WLC-2's management IP must be configured D. Both WLCs must use the same mobility group name, and each must have the other's management IP address and MAC address in its mobility peer list

Correct answer is D. Inter-controller roaming requires three things to be configured on both WLCs: (1) the same mobility group name — this is how WLCs identify trusted peers; (2) each WLC must have the other WLC's management IP and MAC address in its mobility peers list — this establishes the mobility tunnel; and (3) UDP port 16666 must be open between the WLC management interfaces for the EtherIP mobility tunnel. A mobility group name mismatch or missing peer entry is the most common reason inter-controller roaming fails.

5. What is the purpose of a static mobility anchor in a guest WLAN design?

A. To assign guest clients a fixed IP address that does not change as they roam B. To tunnel all guest WLAN traffic to a dedicated WLC placed in a DMZ, ensuring guest traffic never enters the internal network VLANs regardless of which AP the guest connects to C. To act as a backup WLC that takes over if the primary WLC fails D. To cache the PMK for guest clients so they can roam without re-authenticating

Correct answer is B. A static (explicit) mobility anchor is a WLC specifically designated for a particular SSID — typically a guest WLAN. All internal WLCs act as Foreign controllers for that SSID and tunnel guest traffic to the Anchor WLC. The Anchor is placed in a DMZ VLAN with only internet access. This guarantees that no guest traffic ever reaches internal network segments, regardless of which AP or building the guest connects from. It is a key security design pattern for hospitality, education, and enterprise guest access.

6. In OKC (Opportunistic Key Caching), what is reused during a roam to eliminate the full EAP exchange?

A. The client's IP address and DHCP lease from the previous AP B. The RADIUS server session token, allowing the server to skip validation C. The Pairwise Master Key (PMK) derived from the initial full EAP exchange — the WLC caches and distributes the PMKID to APs so the client can authenticate using the cached key without contacting the RADIUS server again D. The 802.11 association frames from the previous AP, replayed to the new AP

Correct answer is C. When a client first authenticates to an AP via full 802.1X/EAP, the RADIUS server and client derive a PMK. The WLC caches this PMK and its associated PMKID. In OKC, the WLC distributes this PMK to all APs in the mobility group. When the client roams to a new AP, it presents the PMKID in its Association Request. The AP recognises the PMKID and retrieves the cached PMK from the WLC — no RADIUS round-trip needed. Authentication proceeds directly to the 4-Way Handshake to derive a new PTK.

7. How does 802.11r differ from OKC in its approach to fast roaming?

A. 802.11r uses a hierarchical key structure (PMK-R0/PMK-R1) and embeds key negotiation directly inside the reassociation frames — the entire fast transition exchange completes inline; OKC caches the PMK and reuses it but still requires a separate 4-Way Handshake after association B. OKC uses a hierarchical key structure; 802.11r simply caches the PMK from the previous AP C. 802.11r is used only for inter-controller roaming; OKC handles intra-controller roaming D. They are functionally identical — both cache the same PMK and skip the same steps in the roaming process

Correct answer is A. The key architectural difference is how and when key material is negotiated. OKC reuses a cached PMK to skip the EAP exchange, but still requires a separate 4-Way Handshake after the reassociation to derive a new PTK — two steps. 802.11r uses PMK-R0 (held by the WLC) and derives PMK-R1 per-AP in advance. The FT exchange embeds the PTK negotiation directly into the reassociation request/response frames — a single round trip. This makes 802.11r marginally faster than OKC and the preferred choice for the most latency-sensitive voice deployments.

8. A wireless engineer reports that VoIP calls drop every time users walk between the main building and the annex. The annex APs are on a different WLC. The WLC mobility group name is the same on both controllers, but inter-controller roaming is not working. What should the engineer check first?

A. Whether 802.11r is enabled on the WLAN — 802.11r is required for inter-controller roaming B. Whether the client devices support both OKC and 802.11r simultaneously C. Whether the APs in the annex are running the same firmware as the main building APs D. Whether each WLC has the other's management IP address and MAC address in its mobility peers list, and whether UDP 16666 is open between the two WLC management interfaces

Correct answer is D. The mobility group name matches — that's step one. The next most common causes are: (1) the peer WLC entry (IP + MAC) is missing from one or both controllers' mobility peer lists, and (2) a firewall between the two WLC management subnets is blocking UDP 16666, preventing the mobility tunnel from establishing. Use show mobility summary on both WLCs to verify tunnel status is UP. If the tunnel is DOWN, connectivity and firewall rules are the first things to check.

9. Why can traffic shaping cause problems for wireless clients using Layer 3 inter-controller roaming?

A. Traffic shaping modifies packet headers in a way that breaks the mobility tunnel encapsulation B. In Layer 3 roaming, all client traffic is tunnelled from the Foreign WLC back to the Anchor WLC (asymmetric routing) — this tunnelled path is longer than a direct path and adds latency; any shaping or QoS applied at the Foreign WLC may not account for the tunnelled traffic correctly C. Traffic shaping is incompatible with CAPWAP tunnels used between APs and the WLC D. Shaping prevents clients from sending Reassociation Requests during roaming

Correct answer is B. In Layer 3 inter-controller roaming, the data path is inherently asymmetric and longer: client traffic goes Client → AP → Foreign WLC → mobility tunnel → Anchor WLC → network gateway. This additional hop adds latency compared to direct routing. QoS policies (marking, queuing, shaping) applied at the Foreign WLC interface may see the encapsulated tunnel traffic rather than the original client frames, making per-application classification difficult. This is one reason enterprises prefer designs that minimise the frequency of L3 roaming — ideally by sizing mobility group subnets to cover entire campuses.

10. What is a sticky client, and what is the most effective infrastructure-side mitigation available on Cisco WLCs?

A. A client that keeps reconnecting after being deauthenticated; mitigated by MAC address filtering on the WLC B. A client that is assigned a static IP and refuses DHCP; mitigated by forcing DHCP on the WLAN profile C. A client that remains associated to a distant AP despite poor signal instead of roaming to a closer AP; since roaming is client-driven, infrastructure mitigations include 802.11v BSS Transition Management (to suggest a better AP), 802.11k Neighbour Reports (to optimise scanning), and reducing cell size via lower AP transmit power D. A client that stays on 2.4 GHz instead of roaming to 5 GHz; mitigated by disabling 2.4 GHz radios on the WLC

Correct answer is C. A sticky client is a device that refuses to roam away from a weakening AP signal despite a better AP being available. Because IEEE 802.11 makes roaming entirely the client's decision, the infrastructure cannot force a roam. Cisco WLCs offer several "nudge" mechanisms: 802.11v BSS Transition Management sends a suggestion (not a command) to the client to move to a better AP; 802.11k Neighbour Reports give the client an optimised list of nearby APs to reduce scanning time; and reducing AP transmit power creates smaller, more overlapping cells that naturally encourage more frequent roams. None of these are guaranteed — the client ultimately decides.

← Back to Home