I have noticed in general, AutoRF tends to use on the 5ghz band channels 36,40,44 and 48 disproportionally over DFS channels, even if there is more congestion/utilisation on those channels where the DFS channels are clear. We have DFS channels enabled for use, and we do not generally have hardly any DFS events seen (I have seen none in this example network below).
For example, I have one network comprising of 8 access points, and with the exception of one ap, all have been assigned channels 36,40,44 or 48 despite utilisation on those channels and nothing on the DFS channels. Channel width is set to 20mhz
Channel utilisation as shown on one of the central ap's
5ghz channels assigned by AutoRF to the ap's in this network
Is their some weighting given to the lower channels ? Is there an acceptance that unless channel utilisation is high (i.e. higher then 50%), it will not attempt to move to a clearer channel ?
Documentation here https://documentation.meraki.com/MR/Monitoring_and_Reporting/Location_Analytics/Meraki_Auto_RF%3A__W... states that:
5 GHz Channel Selection
Channel availability for 5GHz varies based on AP model and regulatory domain. The access point will consider any channel that it is certified for in the regulatory domain of operation. A list of channels can be viewed by opening the channel dropdown for the AP on the radio settings page. There is no preference for a particular band and all channels are weighted evenly.
Be interested in your views and your own experience. Our networks are in the UK
I am based close to the Channel, and have in my vicinity the UK Channel Control Centre as well as several military and ASR landing pads. To make matters worse there is a flight path used by animal transports overhead and the southbound transit route for shipping is within sight. This means that there is interference from marine, aviation and weather ground stations. In bad weather the interference increases as the military use anti-personnel radar. From time to time one of the Apaches notices my WiFi (and a large generator disguised as a haystack) and it does the "bee-dance". We exchange waves.
The problem with using radar vulnerable channels is that, depending on the circumstances, the interaction of DFS/TPC/CAC can result in silent listening periods of up to 4 hours, but only in extreme cases. Most users assume that the AP has stopped functioning and log a fault. Understandably, the manufacturers wish to avoid this false fault report.
Thanks for sharing your experience.
Presumbaly you have the 'use DFS channels' option disabled, so restrict yourself to 36,40,44 and 48. I would do the same if I was seeing that amount of radar, air traffic etc using those DFS channels and your AP's having to drop down back into the non-dfs channel range (at the same time disconnecting your clients). I guess your see a lot of DFS events in the event log..
I'm not seeing dfs events and as we are not near aircraft or radar to be affected, we enable the use of DFS channels. The query I have, is that in practice, I am seeing over 80% of my access points being auto assigned on to one of the 4 channels (36,40,44,48) which have greater utilisation/congestion and the other 20% assigned to the other 12 channels, which to me doesn't seem well balanced if (as Meraki state) all channels are equally considered...
Actually, I go out of my way to see what happens when DFS/TPC/CAC comes into play. But I do keep an alternative AP that does not get interference. In my experience, it is better to explicitly assign WiFi frequencies and RX levels.
I must of slipped into old version mode, these ap's are actually using the standard default indoor profile
Thanks for the tip on update auto channels when no clients connected, I'll give that a try I would of thought that it would be able to do this automatically overnight when very few clients are connected, but will give it a push.
Look forward to the enhancements to AutoRF, will try that in a non production network, however, difficult to replicate the live network and client use to fully test, and I think there's too many issues still with 26.+ firmware for us to apply to the production enviroment