Meraki offers some great products and it is amazing how far the company has come with so little in the beginning. They started with a wireless mesh with dispersed control plane in the cloud and have moved on to a full stack for enterprises! Some say it is not enterprise grade - my take is Meraki fits any enterprise if the enterprise fits Meraki.
During some time I have been experiencing SSIDs disappearing and clients disconnected for what felt like about a minute every time which got me thinking of 802.11h. 802.11h relates to scanning for radar and in the event of one stop using the channel in question for 30 minutes and change to a new. But before servicing clients on the new channel wait and listen for a minute. And any application would suffer from this outage especially voice applications.
Surely this could not be the reason since I knew the APs 5Ghz radio was on channel 44. Maybe it was Meraki´s Auto RF changing the channel due to interference or high utilization and in that process restarting the radios. But the event log depicted a different situation - got to love the event log setup for a clean overview and filtering options. It was a bit more hard to troubleshoot the same on Cisco´s 3700 series some years ago.
What I found was a sad chain of events.
First the AP was changing from a non DFS channel 44 to DFS channel 60 for unknown reasons. Filtering did not show Auto RF changing it - so what did?! Actually average utilization were highest for this channel in UNII-1 so don't know why it had chosen this channel in first time. And it was happening within seconds triggering disassociations and associations of all clients - still within TCP/IP limits so this did not give the impression of a missing connection. But imagine the extra overhead taking up airtime with a bunch of APs doing the same in an enterprise.
Next I found that the change back to channel 44 happened due to a DFS event triggering disconnections of clients.
This had gone on 1-2 times a day for 1.5 month of time.
For the fun of it I tested if it related to channel 44 and set it to 36 but same thing happened. Out of the blue changed to channel 60 followed by a DFS event and changed back to 44 again. 44 still being more utilized than 36.
To verify if the AP was really seeing a radar blast I checked the log of a MX64W standing next to an AP. It did not show any DFS events.
I also did test on my Cisco CUWN solution which did not detect any during a period of time the MR32 detected one.
The behavior of changing to channel 60 every time and it detecting a DFS event looks to me as 2 bugs in the SW. One why is the channel changed? The event log does not disclose anything and it would not make sence. Two is the false-positive DFS events triggered by a low threshold in the algorithm? Or is it magic? But one upgrade and it is fixed for all customers that is! :)