Sneha at Infosys enables 802.11r on the corporate SSID for VoIP, and a fleet of older barcode scanners immediately drop off the network. What is the cleanest fix?

Correct: a. Some legacy/embedded supplicants cannot parse the Mobility Domain IE and refuse to associate when FT is on. Splitting the SSID keeps fast roaming for the devices that benefit while giving the broken clients a non-FT home. Aruba explicitly recommends testing device interoperability before enabling 11r broadly.

On Aruba, you enable 802.11k on a WLAN. A colleague insists you must also separately enable 802.11v for steering to work. What is actually true?

Correct: c. Per Aruba's roaming docs, when 802.11k is enabled, 802.11v is automatically activated in the background to carry BSS Transition messages that steer the client to a better AP. They are complementary, not exchangeable, and you do not turn 11k off.

Two adjacent buildings each have their own Aruba controller. Roaming within a building is fast; roaming between buildings drops sessions. The 802.11r config is identical on both. What is the architectural gap?

Correct: d. Identical 11r config is not enough across controllers. Without a cluster, the anchor changes on a cross-controller roam, so IP/VLAN/session are lost and the client must re-establish at L3. Putting both controllers in one cluster keeps the UAC fixed and preserves the session across buildings.

You try to enable controller clustering for seamless roaming, but the cluster will not form. You confirm IP reachability is fine. Which two conditions should you check first?

Correct: c. Aruba clustering will not coexist with HA-AP fast failover, and every managed device in the cluster must run the same software version. A mismatch on either is the classic "cluster won't form" cause — check these before deeper debugging.

A hospital plans roaming-critical voice for an all-Apple iPhone fleet across a large campus. Which roaming design is the soundest?

Correct: a. Apple devices ignore OKC and use 802.11r, so FT must be on. Add 11k/v for fast discovery and steering, and cluster the controllers so the L3 anchor survives — voice needs both the L2 key speed and L3 session preservation. Raising power or per-floor SSIDs just creates coverage and re-auth problems.

An auditor argues: "Our roaming is perfectly tuned with 802.11r/k/v and a clean cluster, so the wireless platform is secure — patching the controllers can wait." How should you assess this position?

Correct: b. Roaming tuning and platform patching are orthogonal. A well-roaming but unpatched controller is exposed to documented critical RCE (CVE-2024-26305/26304 on ArubaOS; CVE-2024-42505/06/07 on APs via PAPI/UDP 8211). The WPA version does not change that — patch cadence on the cluster is non-negotiable.

Aruba Fast Roaming — 802.11r/k/v, OKC & Clustering, Visual & Interactive

Q: In a Wi-Fi roam, which device actually decides when to leave the current AP and join a new one?

Correct: b. The roam decision lives in the client's driver. 802.11k and 802.11v can nudge the client toward a better AP, and on AOS-10 the AP can even send a disassociate as a last resort, but normally the client owns the timing. That is exactly why "sticky clients" are so painful — the infrastructure cannot force a well-behaved roam.

Q: On an Aruba WLAN, which standard hands the client an optimized list of neighbouring APs and channels so it does not have to scan every channel?

Correct: c. 802.11k Radio Resource Management returns a Neighbor Report so the client scans only the relevant channels and finds the next AP faster. On Aruba, enabling 802.11k automatically activates 802.11v BSS Transition steering in the background. 802.11w is about protecting management frames, not discovery.

Q: A client completes 802.11r Fast BSS Transition in 45 ms, yet the call still drops for two seconds. The radio handoff was genuinely fast. Where is the real problem?

Correct: a. 802.11r only accelerates the Layer-2 key handshake. If the roam crosses to a different controller or VLAN and the session is not anchored, the client must re-establish at Layer 3 — seconds, not milliseconds. Aruba clustering with a fixed User Anchor Controller keeps the IP, VLAN and session intact so the L3 break never happens.

Q: Your show ap client roaming-history shows one hop as FULL-AUTH while the rest are FT (11r) . What is the most likely cause of that single slow hop?

Correct: d. FT only works when the target AP shares the mobility domain (MDID) and the R1 key has been pushed to it — that requires the APs to be in the same cluster / RF space. A hop to an AP outside that domain has no cached key, so it falls back to a full 802.1X auth. Fix the MDID/cluster boundary and the slow hop disappears.

Why a roam is harder than it sounds

Picture Sneha walking from the lobby to the 3rd-floor lab at her Infosys campus, on a VoIP call the whole way. Her phone passes under six different access points. Each handoff from one AP to the next is a roam. Get it wrong and her call stutters or drops. Get it right and she never notices.

The simple version: a normal roam is like leaving a building and showing your full ID badge at the next door from scratch — slow. Fast roaming is like the second door already having your photo on file, so you just nod and walk in. That nod is the difference between a smooth call and a dropped one.

The hands-on version: a full re-association forces a fresh 802.1X/EAP exchange plus a 4-way handshake against the RADIUS server — that can be 600–800 ms or more. Fast-roaming standards cache the keys so only the 4-way handshake (or less) runs at the new AP, dropping handoff to roughly 40–50 ms.

The design version: roaming is a Layer-2 event, but the user's experience is decided at Layer 3. The art is layering FT/OKC for the L2 key handshake on top of a cluster + anchor model that preserves the L3 identity (IP, VLAN, session) so latency- and state-sensitive apps never see a break.

A roam has four phases, and the slow ones are the security phases — not the radio hop itself.

The radio hop (phases 1 and 3) is quick. The killer is phase 2 — a full 802.1X re-authentication against RADIUS. Fast roaming exists to avoid repeating it.

Field scenario · Sneha at Infosys Symptom: "My WhatsApp call cuts out for a second every time I walk between meeting rooms." Cause: the WLAN had no fast-roaming standard enabled, so every handoff triggered a full RADIUS re-auth. Each gap was the 700 ms of phase 2.

Pause & Predict

Before you read on: of the four phases, which single one do you think fast-roaming standards work hardest to eliminate?

Phase 2 — 802.1X authentication. It is the only phase that reaches all the way out to the RADIUS server. 802.11r and OKC let the AP infrastructure reuse a cached master key so this round-trip is skipped, while the radio phases stay roughly the same.

Four words you must own first

🔑

PMK

tap to flip

Pairwise Master Key — the top-level secret derived from your 802.1X/EAP login. Caching it across APs is what makes fast roaming possible.

🤝

4-Way Handshake

tap to flip

The exchange that turns the PMK into per-session encryption keys (the PTK). Fast roaming keeps this but skips the full EAP that comes before it.

🌐

BSSID vs SSID

tap to flip

SSID = the network name you see. BSSID = one specific AP radio's MAC. You roam between BSSIDs while staying on the same SSID.

🗺

Mobility Domain

tap to flip

A group of APs sharing an MDID that forms one continuous RF space, so 802.11r R1 keys can be shared and clients can fast-roam between them.

① The roam itself — watch it happen

The client, not the AP, decides when to roam. Your phone watches the signal of its current AP. When it drops below a threshold and a better AP is available, the phone jumps. Press Play below to walk one roam, stage by stage.

▶ Watch a fast roam (802.11r + OKC active)

Sneha's VoIP phone hops from AP1 to AP2 while staying on SSID Corp-Voice. Each stage lights up as it happens.

① ON AP1 Phone 10.20.5.41 associated to AP1 (BSSID a8:bd:27:11:aa:01), RSSI -72 dBm and falling

▼

② 802.11k AP1 hands a Neighbor Report: "AP2 is on channel 36, strong here". Phone scans only that channel — not all 25.

▼

③ DECIDE AP2 measured at -58 dBm > AP1's -72. Phone chooses to roam to AP2 (BSSID a8:bd:27:11:aa:02).

▼

④ FT / OKC No RADIUS round-trip. AP2 already holds the cached PMK (R1 key via FT, or PMK via OKC). Phase-2 auth is skipped.

▼

⑤ 4-WAY Only the 4-way handshake runs on AP2 → fresh PTK derived. Elapsed so far: ~45 ms.

▼

⑥ ANCHOR Cluster keeps the phone on the same User Anchor Controller. IP 10.20.5.41 + VLAN unchanged. Call never breaks.

Press Play to step through one fast roam. Each press of Next advances one stage.

Quick check · Q1 of 10

In a Wi-Fi roam, which device actually decides when to leave the current AP and join a new one?

a) The controller, which pushes the client off b) The client (phone / laptop), based on signal thresholds — the AP can only hint c) The RADIUS server d) DHCP decides at lease renewal

Correct: b. The roam decision lives in the client's driver. 802.11k and 802.11v can nudge the client toward a better AP, and on AOS-10 the AP can even send a disassociate as a last resort, but normally the client owns the timing. That is exactly why "sticky clients" are so painful — the infrastructure cannot force a well-behaved roam.

② 802.11r / k / v + OKC — four jobs, not four copies

Students mix these four up constantly. They are not alternatives doing the same thing — each owns a different slice of the roam. Here is the one-line job of each.

11r and OKC both speed the key step (the slow part). 11k and 11v help the client find and move to the right AP. You typically run them together.

802.11r — key transition 802.11k — discovery 802.11v — steering OKC — key caching

ELI5: 11k is the map ("the next shop is on this street"), 11v is the gentle push ("go there, it's better"), and 11r / OKC are the VIP pass that lets you walk straight in without queuing at security again.

Practitioner: on Aruba, 802.11r is enabled by default and 802.11k auto-enables 802.11v in the background. OKC is a separate toggle. Always validate the PMKID and keep OKC on for non-Apple fleets — but never assume Apple devices use it.

Architect: treat 11k/11v as the steering plane and 11r/OKC as the security-key plane. For roaming-sensitive workloads (voice, RTLS, medical carts) you mandate 11r; you keep OKC as the fallback for older non-FT clients that still respect cached PMKs.

One screen to memorise before the ACMP exam — and before you flip 802.11r on for an entire campus.

Configure it on Aruba Instant

On an Aruba Instant / AOS-10 SSID, fast roaming lives under the WLAN's security settings. Here is the minimal CLI to enable 802.11r, 802.11k and OKC on a voice SSID.

Aruba Instant CLI — enable fast roaming on the voice SSID

(Instant AP)(config)# wlan ssid-profile Corp-Voice
(Instant AP)(SSID Profile "Corp-Voice")#   opmode wpa3-aes-ccm-128
(Instant AP)(SSID Profile "Corp-Voice")#   dot11r
(Instant AP)(SSID Profile "Corp-Voice")#   dot11k
(Instant AP)(SSID Profile "Corp-Voice")#   okc
(Instant AP)(SSID Profile "Corp-Voice")# end
(Instant AP)# commit apply

Expected output — verify it took

(Instant AP)# show ap debug dot11r-info
SSID         802.11r   802.11k   OKC    MDID
-----------  --------  --------  -----  ------
Corp-Voice   Enabled   Enabled   On     0xa1b2
Corp-Guest   Disabled  Disabled  Off    --

Pro tip — set the Mobility Domain ID on purpose

Aruba auto-derives an MDID per SSID, but on multi-cluster or multi-site designs you should set it deliberately. APs that share an MDID form one continuous RF space and can share 802.11r R1 keys — which is the whole point of FT. Two sites with clashing auto-MDIDs can silently break cross-controller fast roaming.

Quick check · Q2 of 10

On an Aruba WLAN, which standard hands the client an optimized list of neighbouring APs and channels so it does not have to scan every channel?

a) 802.11r — Fast BSS Transition b) OKC — Opportunistic Key Caching c) 802.11k — Radio Resource Management Neighbor Report d) 802.11w — Management Frame Protection

Correct: c. 802.11k Radio Resource Management returns a Neighbor Report so the client scans only the relevant channels and finds the next AP faster. On Aruba, enabling 802.11k automatically activates 802.11v BSS Transition steering in the background. 802.11w is about protecting management frames, not discovery.

Pause & Predict

An Apple-heavy fleet (MacBooks + iPhones) roams slowly even though you enabled OKC. Why might OKC be doing nothing here?

Apple macOS and iOS do not support OKC. They use 802.11r Fast BSS Transition instead when it is available. For an Apple fleet you must enable 11r — turning on OKC alone leaves those devices doing slow full re-auths. This single fact has cost many engineers a full afternoon of confused packet captures.

③ Clustering & the User Anchor Controller

Here is the trap that catches even strong L1s: your roam can be lightning-fast at Layer 2 and still drop the call. Why? Because if the new AP lands you on a different controller or VLAN, your IP and session are lost and you must re-DHCP. Aruba's answer is clustering plus the UAC.

Both APs tunnel into the cluster, but the client stays bonded to one User Anchor Controller. The AP changes; the anchor — and therefore the IP, VLAN and session — does not.

Field scenario · Rahul at TCS Symptom: "Roaming is fast on the dashboard, but RDP sessions still freeze when users walk between buildings." Cause: the two buildings sat behind different controllers with no cluster, so each cross-building roam changed the anchor and forced a new IP. Fix: put the controllers in one cluster so the UAC stays fixed.

The constraint everyone forgets

Symptom you will see: you enable a cluster and it refuses to come up, or HA-AP fast failover stops working. Cause: if HA-AP fast failover is enabled, a cluster cannot be enabled — they are mutually exclusive. Also, every controller in the cluster must run the exact same software version. One mismatched node and the cluster will not form. Check both before you blame the network.

Quick check · Q3 of 10

A client completes 802.11r Fast BSS Transition in 45 ms, yet the call still drops for two seconds. The radio handoff was genuinely fast. Where is the real problem?

a) The new AP lands the client on a different controller/VLAN with no cluster, so the client loses its IP/session and must re-DHCP — a Layer-3 break b) The RADIUS server is slow c) 802.11r was not really enabled d) The phone's battery saver throttled the radio

Correct: a. 802.11r only accelerates the Layer-2 key handshake. If the roam crosses to a different controller or VLAN and the session is not anchored, the client must re-establish at Layer 3 — seconds, not milliseconds. Aruba clustering with a fixed User Anchor Controller keeps the IP, VLAN and session intact so the L3 break never happens.

④ Troubleshoot — "roaming is slow / call drops"

You configured everything and users still complain. Here is the diagnosis ladder — each card is one CLI move on the controller or AP. Tap to flip.

①

Is FT actually on?

tap

show ap debug dot11r-info — confirms 802.11r / k / OKC + MDID per SSID. If FT shows Disabled, the client is doing full re-auth every hop.

②

Sticky client?

tap

show ap association — find a client glued to a far AP at -80 dBm. ClientMatch / 802.11v steering can nudge it, but the client driver still owns the decision.

③

Roam history

tap

show ap client roaming-history — see the actual hops, RSSI at each, and whether each roam was FT (fast) or a full auth (slow).

④

Cluster healthy?

tap

show lc-cluster group-membership — all nodes CONNECTED + same version. A split or version-mismatched cluster causes the L3 roam drops from Section 3.

Controller CLI — settle "did this roam go fast?" in 5 seconds

(MC1) #show ap client roaming-history client-mac 2e:8a:1f:44:7c:90

Expected output

Roaming History
---------------
Time      From-AP   To-AP    From-RSSI  To-RSSI  Roam-Type
--------  --------  -------  ---------  -------  ---------
10:14:02  AP1-3F    AP2-3F   -72        -58      FT (11r)
10:18:41  AP2-3F    AP4-2F   -74        -60      FT (11r)
10:23:09  AP4-2F    AP6-1F   -78        -55      FULL-AUTH   <-- slow hop

That last line is your smoking gun: one hop fell back to a full auth. Usually it means AP6 is in a different mobility domain (wrong MDID) or a different cluster — exactly the cross-controller break we covered above.

Pause & Predict

A "sticky" phone clings to a -82 dBm AP across the room instead of roaming to a -55 dBm AP overhead. The infra wants it to move. What is the strongest standards-based lever Aruba has — and its hard limit?

802.11v BSS Transition Management — the AP sends a BTM request asking the client to move to a named better AP (Aruba's ClientMatch drives this). The hard limit: it is a request. A poorly behaved client can ignore it. As a last resort AOS can deauthenticate the client to force a re-scan, but that is a blunt tool, not a clean roam.

Common mistake — flipping 802.11r on globally and walking away

Symptom you will see: a subset of devices — old barcode scanners, some Android builds, IoT sensors — vanish from the SSID entirely the moment FT goes live. Cause: those clients have a broken FT supplicant and cannot parse the Mobility Domain IE, so they refuse to associate. Fix: split the SSID — a non-FT SSID for legacy gear, an FT SSID for modern devices. Aruba's own guidance is to test interoperability of the common device types before enabling 802.11r fleet-wide.

Security note — patch the controllers, not just the Wi-Fi config

Fast roaming is a config feature; the platform running it still needs patching. In 2024 HPE Aruba disclosed multiple critical unauthenticated RCE bugs in ArubaOS controllers/gateways (e.g. CVE-2024-26305 / CVE-2024-26304) and in access points via the PAPI service on UDP 8211 (CVE-2024-42505/06/07). Lesson for the exam and the job: a beautifully tuned roam on an unpatched controller is still a breach waiting to happen. Track HPE security bulletins and keep the cluster on a fixed, patched version.

Quick check · Q4 of 10

Your show ap client roaming-history shows one hop as FULL-AUTH while the rest are FT (11r). What is the most likely cause of that single slow hop?

a) The client ran out of battery b) FULL-AUTH is always faster than FT c) The RSSI was too strong d) The target AP is in a different mobility domain (different MDID) or a different cluster, so the cached R1 key was not available and a full re-auth ran

Correct: d. FT only works when the target AP shares the mobility domain (MDID) and the R1 key has been pushed to it — that requires the APs to be in the same cluster / RF space. A hop to an AP outside that domain has no cached key, so it falls back to a full 802.1X auth. Fix the MDID/cluster boundary and the slow hop disappears.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer. No login, no waiting.

Pre-curated answers from Aruba TechDocs + Airheads community + the ACMP guide. For a live prod issue, paste your show ap client roaming-history + show lc-cluster group-membership into chat.techclick.in.

Lock it in — explain it back

Self-explanation: in one line, why can a roam be fast at Layer 2 and still drop the call?

Teach a friend: explain 11r vs 11k vs 11v vs OKC to a teammate in four short lines.

📨 Want a recall nudge?

Drop your email and we will send you three quick recall questions on this lesson in 7 days — spaced repetition is how this sticks for the ACMP exam and the job.

✓ Saved. We will nudge you in 7 days. Keep roaming.

📖 Glossary

802.11r (FT): Fast BSS Transition. Pre-distributes the R1 key to target APs so the slow re-auth is skipped during a roam.
802.11k (RRM): Radio Resource Management. Gives the client a Neighbor Report so it scans only relevant channels.
802.11v (BTM): BSS Transition Management. Lets the AP request that a client move to a better AP; Aruba's ClientMatch drives it.
OKC: Opportunistic Key Caching. Caches the PMK across APs under one administrative control. Not supported by Apple macOS/iOS.
PMK / PTK: Pairwise Master Key (the cached secret) and Pairwise Transient Key (the per-session key derived by the 4-way handshake).
MDID / Mobility Domain: The ID shared by a group of APs forming one RF space so R1 keys and fast roaming work between them.
UAC: User Anchor Controller. The single controller that owns a client's session/IP across all APs in a cluster.
Cluster: A set of Aruba controllers acting as one HA unit, providing seamless roaming, hitless failover and load balancing.

📚 Sources

HPE Aruba Networking TechDocs — Roaming and the key management service (AOS-10). arubanetworking.hpe.com/techdocs
HPE Aruba Networking TechDocs — Configuring Support for 802.11r and OKC (Instant).
HPE Aruba Networking TechDocs — Controller Clustering & User Anchor Controller (ArubaOS 8.10 / 8.11).
Aruba Certified Mobility Professional (ACMP) Official Certification Study Guide — Introduction to Clusters; NetProj ACMP Exam Notes.
Aruba Airheads Community — Clustering of Mobility Controllers thread.
HPE Security Bulletins — ArubaOS multiple critical vulnerabilities (CVE-2024-26305 / 26304); Access Points command injection via PAPI UDP 8211 (CVE-2024-42505/06/07). Arctic Wolf / Censys advisories, 2024.

What's next?

You can make a roam fast and keep the session anchored. Next we leave the on-prem controller behind and go cloud-native: how Aruba Central NetConductor builds an EVPN-VXLAN fabric and pushes cloud-based auth and policy to the edge.

Next · Aruba Central NetConductor — Cloud-Native EVPN-VXLAN Fabric & Cloud Auth → ← All lessons

Aruba Fast Roaming — Watch a Call Survive an AP Hop in 11 Minutes

By the end you will be able to

Pick a topic — jump straight to it

The Roam Itself

11r / k / v + OKC

Clustering & UAC

Troubleshoot

Why a roam is harder than it sounds

Four words you must own first

① The roam itself — watch it happen

▶ Watch a fast roam (802.11r + OKC active)

② 802.11r / k / v + OKC — four jobs, not four copies

Configure it on Aruba Instant

③ Clustering & the User Anchor Controller

④ Troubleshoot — "roaming is slow / call drops"

🤖 Ask the AI Tutor

📝 Wrap-up — six more

Lock it in — explain it back

📨 Want a recall nudge?

📖 Glossary

📚 Sources

What's next?