802.11r Fast Roaming and OKC Explained - 夜莺博客

802.11r Fast Roaming and OKC Explained

A voice call that drops every time someone walks between offices is usually not a coverage problem — it is a roaming latency problem. Roaming back to the controller for a full 802.1X re-authentication costs hundreds of milliseconds, which a Wi-Fi call cannot tolerate. 802.11r fast BSS transition and opportunistic key caching both attack that delay, from opposite directions, and modern designs usually deploy both.

What makes plain roaming slow

In a WPA2-Enterprise network, a client moving to a new AP repeats the whole authentication: 802.11 open authentication, association, EAP exchange with the RADIUS server, then the four-way handshake. The EAP round trips are the expensive part, and they involve a device — the RADIUS server — that is not in the data path at all.

802.11r: pre-computing the keys before the client moves

802.11r introduces a key hierarchy under the PMK: PMK-R0 held by the controller, PMK-R1 derived per AP, and the PTK derived from the R1 without a server round trip. The client can perform the FT authentication with the target AP in advance of actually roaming, so by the time it sends a reassociation request the keys already exist on both sides.

  • Over-the-air (OTA): the client talks to the target AP directly, using FT authentication frames. Fastest, and the recommended mode for controller-less and FlexConnect deployments.
  • Over-the-DS: the client sends the FT frames through its current AP, and the distribution system relays them. Useful when the client cannot reach the target AP directly, but it adds a hop.
! AireOS controller
config wlan security ft enable 1
config wlan security ft over-the-ds disable 1
config wlan security ft reassociation-timeout 20 1
show wlan 1 | include FT
show client detail <mac> | include Mobility|FT

! IOS XE 17.x (Catalyst 9800) - verify syntax with '?' on your release
wlan FT-WLAN 1 FT-WLAN
 security ft
 no security ft over-the-ds
 security wpa akm ft dot1x

All mobility-domain members must share the same mobility domain identifier if you want FT to work across controllers; a mismatched domain ID leaves clients doing full authentication on one side of the campus and fast roaming on the other.

OKC is not 802.11r

Opportunistic key caching is a vendor technique that predates 802.11r and requires no protocol change: the client and infrastructure cache the PMK derived from the original authentication and reuse it across APs that share the same PMK. It removes the RADIUS round trip but keeps the standard 802.11 key exchange, so it is typically slower than FT and faster than nothing.

The practical difference shows up in client compatibility. OKC works with almost any client that supports PMK caching. 802.11r requires client support, and older or buggy supplicants may refuse to associate at all on an FT-only WLAN — the classic symptom being a handful of devices that connect everywhere except the FT SSID.

Deploying without breaking legacy clients

! two SSIDs with identical names is a valid migration trick:
!   one with FT AKMs enabled, one without
! or use the adaptive / mixed FT option where the release supports it

Three deployment rules that avoid most pain:

  1. Test with your actual client population, not one laptop. Phones, scanners, medical devices and older printers all behave differently.
  2. Keep the same security configuration (AKM suites, PMF setting) on both sides of a roam, or the client will not attempt FT.
  3. Where the controller supports it, use adaptive or mixed mode so FT-capable clients get fast transition and everyone else can still associate.

Measuring whether it worked

show client detail <client-mac>
! Protocol : 802.11ac
! Security : WPA2 802.1X
! 802.11r : Enabled / Disabled
! Mobility State : Run
!  Policy Type : Static
!  Session Timeout : 0

Look for the client-level FT state on the controller, and confirm the roam on the client side with an OS-level roam event log. A useful sanity check is to compare roam times before and after: with FT, the client should never appear to have re-authenticated to the RADIUS server during the roam, which is visible in the authentication logs as a missing EAP exchange.

Supporting material elsewhere on this site: WPA3-Enterprise with 802.1X and RADIUS for the authentication side, and Wi-Fi site survey methods to make sure the roam boundaries fall where you intended.

原文链接:https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-2/config-guide/b_wl_17_2_cg/802_11r_bss_fast_transition.html