Constant Random DFS events causing CCI and poor user experience

[Davey_Hayes]

Hi All

We have a fairly large deployment in London which is designed for dense mobility / voice usage.

Have implemented a well spaced manual channel plan on 5ghz with next to no CCI.

Seems that DFS is causing client issues due    to choosing the same UNII 1 channels on neighbouring AP's , post 28.7 upgrade, I estimate 80% of 300 AP's at this location needed further reloads to revert to configured channel.

Same is happening on other sites around the UK

This is becoming a big problem as the offices is now being used more as more users are returning and in the habit of using WiFi ..

Any suggestions as the support service is P155 poor

[alemabrahao]

Have you tried to disable DFS channels?

[Davey_Hayes]

LOL that a Joke....? we have open plan environments with a potential of 400 users per floor with additional meeting rooms , how'd you propose disabling DFS channels with 25 AP's per floor?

[alemabrahao]

No, it's not a joke, It's just a question. I'm not suggesting that, you can perform Lab to test It.😉

[Davey_Hayes]

From the vast amount of design and post survey work carried out  with Ekahau this is a non starter

[alemabrahao]

Ok, so I suggest opening a case with Meraki support.

[Davey_Hayes]

Already done , another non starter

[WB]

So escalate it to your account rep instead of getting snarky and mopey in here? You asked for suggestions and people are offering some, including an actual Meraki employee

[TBHPTL]

You do it exactly as stated and with static power settings..static channels, smaller cells, lower power. Perhaps designed coverage with external ants. This is the art and zen of wireless design both Ekahau and Hamina have excellent wireless predictive design tools. Use them and validate.

[GreenMan]

Despite your reservations, I think you will need to re-engage with the Support team - perhaps look to escalate via a manager or your account team, if you feel you're not being listended to?   (you can usually find the latter via Help > Get help > Still need help > Contact your Meraki Sales representative).  I would suggest quoting the original case reference, so that whoever picks it up has the original background. The key, by the sounds of it, would seem to be that you feel you're getting a lot more DFS events after a particular firmware upgrade, than with exactly the same deployment on an older version of firmware.   Do you have any numeric evidence of this   (?)   Bear in mind that if there really is radar transmission being detected (are you on a flight path?), then reverting to one of the non-DFS channels is mandatory and the same challenge would apply regardless of the WiFi technology.   Longer-term, the advent of WiF6E should help here - more channel space, in 6 GHz, with no DFS - but you obviously don't have the APs and there aren't yet many clients to take advantage of this, right now.

[PhilipDAth]

Hmm.  Some thoughts going through my mind.  Maybe the system has calculated it's more optimal to have those APs re-using the same channels so that other APs that are also in hearing range but carrying a greater load can use the non-overlapping channels.

Personally - I have never used manual channel assignments.  I'm not a fan of that approach.  It is a static calculation that is done once, versus a dyanmically calculated system that can consider load on AP and loads that vary (such as by time of day), interfence that can come and go, available RF spectrum (which can vary by time of day because of neighbouring WiFi).  Maybe manual assignment works ok in an envirnment with no interfence, constant non-moving loads, and where their are no other WiFi networks around.

What power levels are you using?  Lower power levels will enable greater channel re-use (and encourage romaing).

Some power levels I have found good for dense deployments that offers great compatibility are:

[cmr]

It did used to be that DFS events were only reported in the event log and didn't make the AP status go yellow.  Are you confusing that with having more events?

We have 5 central London venues and do see DFS events on APs that can see the outside, but as we use 20 MHz channels it hasn't yet been a performance issue.  As @PhilipDAth said, perhaps turning down the max power and setting yours to 20MHz might be the way forward (unless you already do this).

[Davey_Hayes]

OK so to calm the farm,,, Meraki have admitted there is a Bug with DFS causing the AP to stay on the Unii 1 channel , this is being looked into by Engineering , and in the mean time I've configured the AP's with Dynamic channel allocation which has in most part calmed the situation down , but in doing so have now seen another issue, again related to DFS...

AP's are now going into a non broadcast state after DFS events , i.e registered but not broadcasting SSID's so clients cannot connect , anyone see this in the Central London Area??

[TBHPTL]

Re-channel without DFS use 20MHz wide channels. You can also try enable Auto RF with Busy hour enabled.

[Paccers]

Agree with @TBHPTL, using non-DFS channels if possible will remove the chance of weird behaviour with CAC windows and backoffs