9800-CL 17.6.x 802.11r not working

[Marci]

Hello all,
does anyone know why with version 17.6 it is not possible to enable Central Association in the policy.
Without Central Association and Central Authentication no Fast Roam works for me.

In version 17.3  this works also only if both options are active.

With 17.6 I have not yet found a working solution for 802.11r in Flexconnect mode.

APs used: 9105AXI

[Flavio Miranda]

I have found some information that might be helpful.

"In the releases prior to Cisco IOS XE 17.2.1, the PMK cache was shared across the FlexConnect APs using the AP site tag. All the APs that are a part of a site tag share the PMK cache. This is applicable only for central authetication. "

Which means, priviously, if you had AP  with the same site tag, AP would have the PMK stored and Fast Roaming (802.11r) would be possible. 

But now they change this.

"From Cisco IOS XE 17.2.1, you can create a Mobility Domain ID (MDID) for each of the APs.
All the APs with the same MDID share the PMK cache keys even if they are in different site tags.
When MDID is configured for APs, the PMK cache keys are not shared with the APs that are not a part of the same MDID, even if they are a part of the same site tag.
MDID supports PMK cache distribution for both central authentication and local authentication. "

And now comes your problem apparently:

"An MDID is used by 802.11r to define a network in which an 802.11r fast roam is supported.
PMKs should be shared within mobility domains, allowing clients to support fast roaming. If defined, MDID takes precedence over a site tag."

And here comes the trouble:

"MDID is configured only through the open configuration model. There is no CLI or GUI support."

But, it seems to me that if you enable MDID AP groups, 802.11r will work for you even with central authentication and local authentication.

But, this alternative to enable MDID surprises me as it seems that Cisco wants us to use coding in order to enable features:

"MDID configurations are exercised only from open configuration models. For more information about open configuration models, see the

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/172/b_172_programmability_cg.html 

Well, if you have the chance, it is recommend to rise a TAC for this and ask them why such thing. But the thruth is, whithout PMK being share among Access Point, 802.11r will not work otherwise there will be Full authentication and full authentication takes too long.

Hope that helps.

[Marci]

thanks for the info.
but unfortunately doesn't explain for me why it works with 17.3.x and not with 17.6.x if this functionality was introduced in 17.2.1.

[Marci]

17.3.x -> 802.11r works fine if central authentication + central association enabled

17.3.x -> 802.11r not working if central authentication + local association

17.3.x -> 802.11r not working if local authentication + local association

17.6.x -> 802.11r not working if central authentication is set (central association function is no longer available)

17.6.x -> 802.11r not working if local authentication is set (central association function is no longer available)

[Flavio Miranda]

I got it. But what  I meant is that maybe you should take a look on the information about MDID considering you dont know why is woking and why is not working either.  If you look at 17.3 and 17.6 documentation you are going to see that from all new feature and changes, 802.11r is not on of that,  which means Cisco may had made changes mean while and not explicit documented. that´s why worth it dig a bit on it and, as I said, if you can do that, get TAC on phone and ask them.

[Rich R]

Agreed to talk to TAC - as usual documentation is out of step with what has changed in IOS! I wish they would get better at properly updating the docs and documenting the changes!

17.6 config guide still says: https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-6/config-guide/b_wl_17_6_cg/m_config_model.html

"Central Association Enable: When central association is enabled, all switching is done on the controller."

Which is inaccurate anyway because it's association not switching!  But as you pointed out it no longer exists on the GUI and now on CLI:

9800(config-wireless-policy)#central ?
association Deprecated CLI.APs in FlexConnect mode do not support Central Association
authentication Enable/disable central authentication
dhcp Central dhcp for locally switched clients
switching Enable/disable central switching

So although that documentation implies that the site tag should still work when MDID is not configured it probably isn't as a result of central association itself being deprecated.

So MDID may be the only way to do it now!

Rather surprising for Cisco to introduce a feature which isn't supported on GUI or CLI!  Even more so since the GUI itself actually uses the open configuration model to configure the WLC and the config is ultimately stored in the CLI config!  The verification command they provide is a CLI command and shows what the config looks like - maybe try configuring it on CLI and see what happens?

Device#  show running-config | section specific-config
ap specific-config 58ac.70dc.xxxx hostname AP58AC.70DC.XXXX 
   roaming-domain roaming_domain_2 
ap specific-config 78xc.f09d.xxxx hostname AP78XC.F09D.XXXX 
   roaming-domain roaming_domain_3

[Rich R · Accepted solution]

There is some mention in https://www.cisco.com/c/en/us/products/collateral/wireless/catalyst-9800-series-wireless-controllers/guide-c07-743627.html

"Let’s analyze the recommendations one by one. The first suggestion above would help improve the way the resources are used internally on the C9800, optimizing inter-process communication. Also, keep in mind that for FlexConnect deployment, using the default site tag means that fast secure roaming would not be possible as the Pair Master Key (PMK) derived at first authentication is only distributed across the APs in the same custom tag.

Assigning the same site tag to all the APs in the same roaming domain (the area, floors, group of floors, building where the majority of the roaming takes place) is particularly important if you require “optimized” fast roaming for delay sensitive applications, such as voice over WLAN. Optimized here means that WLC would leverage 80211k/v protocols to pass additional information to the client to assist the roaming process; for example a list of neighbor APs a client could roam to (this is provided via 802.11k neighbor list). When roaming across two APs in different site tags, the AP neighbor information is lost, and hence protocols such as 802.11v and 802.11k that rely on this information are not optimized. The recommendation is to assign all the APs in the same roaming domain (where seamless and fast roaming is needed) to the same site tag. This affects only 802.11k/v and doesn’t affect fast and seamless roaming (802.11r, OKC, etc.), which is supported across site tags. This limitation is removed starting release 17.6.1. In this release the user will have to manually check if the SSID is enabled on the neighbouring APs by making sure that it’s included in the policy tag. Starting release 17.7.1, the check is automatic.

Note:     For APs in local mode (so for central association SSIDs), seamless roaming with 802.11r, Cisco Centralized Key Management and Opportunistic Key Caching (OKC) work across site tags. No limit there."

No mention of MDID and also implies custom site tag should work!

Definitely question for TAC and if you can try 17.7.1 to see whether behaviour changes there?

[Marci]

The information with the default tag was the solution!
Many thanks