60 second CAC when changing channel to DFS channel

[rhallan]

Running 5520 Controller with 8.10.162.0 code and 2802 APs. DFS is needed and enabled.

Let us say my AP is on DFS channel 100 and is going to change channel to 132. The channel change could be due to radar detection of maybe RRM wants to change channel due to noise etc.

There is a channel change announcement to go to new channel 132.

The clients disconnect and try to connect on channel 132. 

Do the clients actually take a 60 second connection drop as they wait for the AP to finish its 60 second CAC on channel 132 ?

If yes, this does not seem logical to me.

Would RRM not know that status of channel 132 before switching the AP to this channel i.e. there is no radar on the channel rather than switch the channel , leave the clients disconnected for 60 seconds while it finishes the 60 second CAC. There are multiple AP and APs in monitor mode in the environment, I would thing the status of channel 132 would be know before the switch rather the CAC for 60 seconds after the channel change and leave clients disconnected for 60 seconds.

I am told that the Chromebooks will want to connect to the same BSSID and will not roam to a different AP i.e. if the AP is doing a CAC for 60 sends on the new channel 132 they will wait tying to connect to the same AP.

Any input to help me understand what actually happens in these scenarios is appreciated.

[Rasika Nayanajith]

"Do the clients actually take a 60 second connection drop as they wait for the AP to finish its 60 second CAC on channel 132 ?If yes, this does not seem logical to me."
Once the client connected AP vacate from the current channel, client will loose its connection to it. So clients should connect to another AP quickly as possible (depend on its list of BSSIDs it knows). Client should not wait 60s to same AP it was previously connected. However, WiFi (Re)association is 100% driven by  client, depend on how client WiFi driver programmed determine the behavior.

"Would RRM not know that status of channel 132 before switching the AP to this channel i.e. there is no radar on the channel rather than switch the channel , leave the clients disconnected for 60 seconds while it finishes the 60 second CAC. There are multiple AP and APs in monitor mode in the environment, I would thing the status of channel 132 would be know before the switch rather the CAC for 60 seconds after the channel change and leave clients disconnected for 60 seconds."

There is a feature called "Zero wait DFS" available with 9800 IOS-XE 17.10.x onward do exactly what you asked for. Below is a slide from CLUS -BRKEWN-3413 presentation by Jim Florwick. Please watch the recorded session, if you haven't come across it earlier.

HTH
Rasika
*** Pls rate all useful responses ***

[rhallan]

Rasika thanks for the response. I am a big fan of yours and learn a lot from your other post on the Internet.

We have already bough 9800 Controllers to replace our current 5520 and will be able to use the zero wait DFS in the next few months as we do the migration.

In terms of the long disconnect we see on Chromebooks after channel change to a DFS channel:

The vendor replied ""This is a router misbehave issue rather than a Chromebook issue. Chromebook works as expected and the beacon is lost and putting the bad BSSID into the ignore list is an intended behavior.
On the new channel, no beacon was found and the device reports beacon loss and disconnect. This BSSID is considered as bad BSSID and put into the ignore list for 10 seconds.
According to IEEE 802.11 spec, a BSSID should disappear on the old channel and appear on the new channel after a channel switch announcement. However, the router tried to roam the client to a new BSSID within ESS by using CSA. That's why Chromebook cannot find the BSSID on the new channel and report beacon loss and disconnect after channel switch. "

The Cisco AP did not try to roam the client as they say. The AP is quiet for 60 seconds as mandated and we would have hoped the Chromebook on not seeing beacons on the new channel would do a scan and switch to another AP. But look like it keeps trying the new channel on the same BSSID (when AP is quiet for 60 seconds); this give a fairly long disconnect.

Disabling DFS not really a good option for us , while we wait to go to zero DFS are there any other suggestion to minimize these long disconnects on the Chromebooks during switch to DFS channels ?