802.11r FT with FlexConnect central authentication

[Johannes Luther]

Hi Cisco Support Community

I have a question regarding 802.11r fast roaming in a FlexConnect WLAN with central authentication.

Let's assume all APs are in the same FlexConnect group.

I'm referring to this guide:

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/80211r-ft/b-80211r-dg.html

In the beginning of the document it's stated that:

If WAN link latency exists, fast roaming is also delayed. Voice or data maximum latency should be verified. The Cisco WLC handles 802.11r Fast Transition authentication request during roaming for both Over-the-Air and Over-the-DS methods.

At approximately the mid of the document (section "802.11r BSS Fast Transition on FlexConnect Deployment") another thing is described.

The 802.11r Fast Transition (FT) feature for FlexConnect mode APs is optimized such that the FT authentication request process and validation occur at Cisco AP itself and the Cisco AP itself sends FT authentication response. There is no change in the key derivation system.

So at least I understand, that the FlexConnect AP handles the FT process and send just a copy of the FT auth packet to the WLC. The answer of the WLC may arrive at the AP after the FT process is done. However if the FT process fails, the client may be deauthentication afterwards by the AP.

Long story short - what is the correct statement? Does the WAN delay really impact the roaming speed?

[Ric Beeching]

Hi Johannes,

The document recommends to use FT over-the-air only with FlexConnect as this will result in only packets being exchanged between the client and AP during roaming. 

I believe that if you use FT over-the-ds with FlexConnect then WAN Latency may introduce the delay. I'm wondering if during over-the-ds the APs will talk to each other via CAPWAP control which will do a full loop over the WAN and introduce delay whereas via over-the-air there is no need for that communication and it will be local only. 

Ric

[Johannes Luther]

Hey Ric, thank you for the answer. You're right. With over-the-DS roaming, the client registers itself over the "source" AP to the "destination" AP over the WLC.

However, the deployment guide states

the 802.11r Key Cache is distributed to all the APs in the same FlexConnect Group. The Key Cache distribution is done by the Cisco WLC after the client device does the initial FT association through Central Authentication.

So the Cache ist distributed to all APs in the FlexGroup before the client acutally roams. Therefore, the FT roaming request is not really needed over the DS in "real-time". This is also outlined in the examples.

So from my point of view the statement that the WAN delay during FT roaming is no longer relevant - regardless if over-the-air or over-the-ds is used.

Anyway - follow up question:

What's the correct method? over-the-air or over-the-ds?

All the guides state how to configure it - but not the advantages or drawbacks of each solution.

What method do you guys normally enable in production networks?

[Johannes Luther]

Just a follow up. ... as always a brilliant source is the blog of Rasika

There is a post about over the air FT

https://mrncciew.com/2014/09/07/cwsp-802-11r-over-the-air-ft/

and one post about over the DS FT

https://mrncciew.com/2014/09/08/cwsp-802-11r-over-the-ds-ft/

In his tests, FT over-the-air was slightly faster (14ms) compared to over-the-ds (88ms). Although for over-the-air FT, two more frames are needed (because it's essentially a simple 4-way handshake).

I guess regardless of the used method, the strength of 802.11r is the standardized key distribution and derivation method. So I stick with the guide and generally try over-the-air in the deployments. The question is if the clients support my plan as well :)

[Ric Beeching]

I see what you mean although I still think that in over-the-ds examples AP-to-AP communication will take place via CAPWAP Control over the WAN unless they communicate locally over their native VLAN? I'm not sure they do that at all in which case over-the-ds would introduce that delay on high latency WANs.

Thanks for Rasika's links, that chap is a genius. I have avoided 802.11r due to client support but that's also because there is such a huge mix of devices on my networks. If I was managing one with MDM or a list of permitted devices then it'd be easier to work out eh :).