I see questions come up more and more often around Cisco’s Fast Transition settings (aka FT or 802.11r). In particular mixing non-FT and FT clients on the same SSID, and the role of Adaptive mode. I myself totally misunderstood how their FT Adaptive mode worked until two weeks ago.
There is an awesome culture within Vocera of doing as much as we can to provide guidance to our customers, even when that means providing assistance on another vendors equipment. One such opportunity occurred two weeks ago when a customer wanted to use our voice clients with Fast Transition (the IEEE’s feature name for the 802.11r amendment), but had older Cisco phones on the same SSID that do not support FT. We spun up our lab to test it out and these are the findings.
Summary
Adaptive Mode ONLY applies to iOS devices. No other vendor can support Adaptive mode, it is proprietary to Cisco and Apple.
Update: The Samsung S10 now also supports Adaptive 802.11r according to this Cisco config guide.
Wait, what? You sure?
Yes, let me explain how it works.
- If an SSID has only non-FT authentication modes then Fast Transition mode can be set to Adaptive. The result is that all non-iOS devices (inc MacOS) will connect and roam without FT. But iOS devices can “Adapt” (upscale) their ‘Authentication and Key Management’ suite (AKM) to connect with FT even though the SSID does not support it.
- If an SSID is set to use an FT AKM (FT-PSK or FT-802.1X) then the controller will not let you select Adaptive mode. This is because the SSID already supports FT so there is no need for iOS devices to Adapt their security. In this setup you must select Fast Transition mode of Enabled.
- If you need the SSID to support both FT and non-FT clients then you need to set Fast Transition mode of Enabled and tick both an FT and non-FT AKM (e.g. PSK and FT-PSK). This will allow non-FT devices to connect without FT and FT compatible devices to use FT.
Jerome Henry wrote a great forum post here pointing out some non-FT clients will still not connect because they cannot handle the FT Information Elements (IE) included in the SSID’s beacons. This is typically cheaper and older clients. Vocera is not one of these.
Here’s the testing that allowed me to understand and verify the above information.
Lab Setup
- Cisco virtual WLC running code 8.5.140.0.
- Single Cisco 3502i access point.
- 2x Vocera B3000N clients running 4.3.1.17.
- Vocera configuration machine version 5.3.1.61.
- Vocera Voice Server version 5.3.1.100 (with no badge.properties files on the server).
- All testing was conducted using PSK to match the customers requirements. FT-PSK provides limited roam improvements compared to FT-Dot1X.
- All tests conducted with FT Over-The-DS disabled.
Test 1
A single client was setup for WP2-PSK-AES with FT disabled. The SSID was set to use a “normal” PSK with FT Mode set to Adaptive. The client connected successfully using normal PSK (non-FT PSK).
Test 2
A single client was setup for WPA2-PSK-AES with FT enabled. The SSID was set to use a “normal” PSK with FT mode set to Adaptive (same as Test1). The client would not connected to the WLAN. The CLI log of ‘debug client <MAC>’ showed no log lines at all for the client. The CLI log of ‘debug dot11 probe’ showed the client sending a probe but the AP does not respond. Presumably because the probe contains security settings the SSID does not support.
Test 3
A single client was setup for WPA2-PSK-AES with FT enabled (same as Test2). The SSID AKM was changed to only FT-PSK with FT Mode set to Enabled. The client connected successfully using FT-PSK (802.11r).
Test 4
A single client was setup for WPA2-PSK-AES with FT disabled. The SSID AKM was left with only FT-PSK selected and FT Mode set to Enabled (same as Test3). The client would not connect. The Cisco CLI log file of ‘debug client <MAC>’ showed no log lines at all for the client.
Test 5
Two clients were used for this test. One was setup for WPA2-PSK-AES with FT disabled . The second was setup for WPA2-PSK-AES with FT Enabled . The SSID AKM’s were changed so that both PSK and FT-PSK boxes were ticked. Fast Transition was left at Enabled. Both clients successfully connected to the SSID using their configured security settings.
This CLI screenshot shows both Badges connected with different security.
Great Blog Andrew….interesting to see this live ….thanks for doing this and helping us all improve our knowledge
I am not able to check both PSK and FT-PSK. When I check both and try to apply I get the message “FT PSK or FT 802.1x is not allowed when FT is configured to adaptive mode.”
Correct Jason. If you’re trying to support both FT and non-FT clients then tick PSK & FT-PSK, and set FT Mode to ‘Enabled‘ – as per my third bullet point.
Hope this helps.
this article helped me troubleshoot and issue and was exactly the info i was looking for. thank you for the article!
Excellent, really glad to hear that, thanks for the feedback!
This article is a masterpiece .. thanks
Thank you! I hope it was useful. It may not apply quite the same to the new Cisco Catalyst controllers as I’ve not looked at this since the last update about Android.
This article helped a lot.
I’m using a Cisco Catalyst 9800-CL Wireless Controller – 17.3.4c
Whenever FT was “Enabled”,Macbooks could not connect to the SSID.
nothing would show up under “Troubleshooting / Radioactive Trace / Wireless Debug Analyzer”
Once I setuo it to “Adaptive” it worked fine.
Thanks!
Hello Gui,
What do you have in your “Auth Key Mgmt” ?
Regards
Awesome documentation with test results. Helped a lot