A different MR network for every remote site for AutoRF benefits ?

[pjc]

Hello all,

I've just stumbled acorss this post https://community.meraki.com/t5/Dashboard-Administration/Meraki-Dashboard-Reporting-How-can-I-get-a-...

where

@MerakiDavewrote..

" putting all APs into a single network *might* be fine for your deployment, but could also go against a common best practice, but again it depends on your deployment. Each wireless network is meant to be more of a single site or physical location, like a single branch office, or a corporate office building or group of buildings, or a single school (or perhaps a middle + high school on a common campus, or a single college or university campus for example. The point is that each of these is a single contiguous AutoRF domain for which all of the APs make their RF decisions about channels and power.

So, that got me thinking, where we have one congifured Meraki MR network for most of our WAN sites, and at each site, there would be between 1 and 15 access points, and where we use auto power and auto channel settings for our AP's, is the auto management not able to make the best judgements, as we don't have a seperate Meraki MR network configured for every (approx 150) WAN sites ?

Having a single network helps with access point SSiD tagging, whitelisting clients (that move between sites) and various other admin management duties.  To have to do these functions in 150 different networks would be a pain ( I know we have the config sync function)

Have I understood this advice correctly ?  I though that as each AP knows it's direct negihbours using it's 3rd scanning radio (we use mr32 and 33's), it would caluclate the auto settings based on those neighbouring AP's each can see and not some ap's at a WAN site 50 miles away ?

Appreciate your thoughts

Thanks

[BrechtSchamp]

Well that's what templates are for I guess.

One instance where you would definitely see problems is with DFS. If one of your APs sees a radar, then ALL APs will avoid that channel, even though they might be a long way from the radar.

AutoRF is designed from the assumption that APs are separated into networks, so it's probably best to use it that way.

[pjc]

Thanks both.  We are not seeing any problems, and interestingly enough, despite the documentation telling me that if one AP sees a DFS event, all ap's in that network chnage channels, looking at all of my logs, it would appear this is not the case.

I have one site near an airport, that regilarily see's radar etc that triggers a DFS event.  The single AP we have at the site, does, as expected, move to a non-DFS channel, however, all other ap's in the same logical WAN network on that same channel that the airport site was on at the time of the DFS event, do not change their channel as a result of the DFS event.  This behaviour is consistent with other sites, and DFS events, no channel change triggered on other AP's in the same network. 

Be interested in the definitive answer on this, howver, I'm more interested in how AutoRF chooses channels for each AP, and whether if it does have any bearing on AP's being in a large network with sites many miles away or does it do intelligently based on the neighbour AP's channels that each AP sees on it's scanning radio

Cheers

[BrechtSchamp]

---

@pjc wrote:

Be interested in the definitive answer on this, howver, I'm more interested in how AutoRF chooses channels for each AP, and whether if it does have any bearing on AP's being in a large network with sites many miles away or does it do intelligently based on the neighbour AP's channels that each AP sees on it's scanning radio

---

Me too. Maybe @davidvan can shed some "official" light on this.

[davidvan]

This was answered at Cisco Live recently during BRKEWN-1683, as we talked about "Demystifying Auto RF" at 39:25. We generally recommend one network per geographic area for Auto RF to work correctly. You can look this up here.

At 1:26:00, Sunmeel answers this question.

Let me know if helpful. If not, we can clarify further.

[BrechtSchamp]

Perfect. Thanks @davidvan ! Thanks also for reminding me that I still need to look at the CLUS recordings! Looking forward to that client health feature! Do you know where we can find that whitepaper about the algorithm that Sunmeel talks about at 42:19?

So to summarize things up for the community here regarding this topic. Sunmeel basically explains that a trigger happening in one part of the network can cause the algorithm to shuffle channels or signal strengths on all of the APs in the same network. This is not a big deal in a single building/campus (it's what it's supposed to do) but it's therefore generally not a best practice to have APs in different parts of a city/country/world in the same network.

The example he gave is the density of users changing in a school when the students come in and triggering a rebalancing of the transmit powers of the APs. Another school having a different starting hour, and having its APs in the same network would also see its transmit powers changed even though there no students came in yet. Basically that means that you're introducing unnecessary network AutoRF changes which is undesirable.

[davidvan]

@BrechtSchamp I didn't see him mentioning a whitepaper at 42:19, but he's probably mentioning this Auto RF documentation page. We also referenced this high-density deployment guide during our talk.

@pjc I'll get Sunmeel on here to answer your question.

[BrechtSchamp]

All right, I'll give that a read! Thanks again.

[pjc]

@davidvan  and @Sunmeel 

Thanks for the link to the document, I think it's the same I stumbled across a couple of days ago. 

I think I'm trying to establish the amount of weighting that is given to the neighbour ap reports that are scanned locally when feeding this into the cloud and for the decision based on that and what the influence of other ap's in the same dashboard network but not seen locally as geographically apart

"Auto Tx

Each AP (Access Point) samples the signal-to-noise (SNR) of neighboring APs that reside in the same dashboard network. All radios on an AP can perform the sampling. The SNR readings are compiled into neighbor reports which are sent to the cloud for processing. The cloud aggregates neighbor reports from each AP. Using the aggregated data, the cloud can determine each AP's direct neighbors (neighbors that a client might directly roam too) and how much each AP should adjust radio transmit power so coverage cells are optimized. Once calculations are complete, the cloud instructs each AP to decrease (or in some instances increase) transit power to reach an optimal power level. The Auto TX process is performed every 20 minutes for each AP in the dashboard network on both 2.4GHz and 5GHz radios "

[Sunmeel]

This is the published paper about our AutoRF: https://conferences.sigcomm.org/imc/2017/papers/imc17-final203.pdf

This is another doc that one of our SEs wrote based on the above paper: https://wirelesslywired.com/2019/05/08/meraki-auto-rf-explained/

As far as the question about splitting the network for each location is concerned that is the recommended best practice. AutoRF considers a lot of factors when making channel decisions and one of them is neighbor APs. There are other factors as well that may impact channel change decisions beyond neighbor AP SNR. 

What we have seen is that in a high-density environment when customers have deployed multiple geographically separated areas under a single network other factors tend to cause channel changes even if a lot of traffic is not seen. 

Hope this helps.

[pjc]

@Sunmeel 

Thanks very much for the additional info, much appreciated.  This extra info has given me a greater understanding of how AutoRF works, and it's clear that there are benefits of having each geolocated site in it's own network in the dashboard. 

I will now go ahead and do the work for our networks.  I have seen the use of configuration templates will minimise the ongoing admin, where we can apply changes to the templates which will in turn apply to each of the networks bound to those templates (whitelisted clients, SSID changes etc), as well as the ability to do summary reports on templates too.

Thanks again !

Paul

[pjc]

Hi guys,

A bit of a potential showstopper for us using configuration templates instead of networks, it's not letting me add clients to a group policy (eg no splash screen) in templates (as I did in networks), my users roam across multiple networks, and would need whitelisting into 120 networks (don't want to think about having to do that)....any ideas anyone - Thanks

[BrechtSchamp]

There used to be a note in the docs saying that whitelisting clients in a network bound to a template would whitelist it for all networks under that template. But it's no longer there and the OP in that topic also noted that it didn't actually do that in practice. That topic was this one fyi:

https://community.meraki.com/t5/Dashboard-Administration/Dashboard-Configuration-Sync/td-p/34678

I think @PhilipDAth 's suggestion in that topic is probably the best reply in this case.

[pjc]

Thanks for the lead @BrechtSchamp 

I'll check back with @ZachM90 to see if he got anywhere with this.  I don't think @PhilipDAth solution using Radius is not suitable for our guest clients

Thanks

[pjc]

@davidvanThanks for the clarification.

Before I go off and split my existing 3 WAN networks into 120+ individual networks (the majority of those sites having 3 or less ap's in each of them), and then grapple with the ongoing complexities such as whitelisted clients, reporting, alerting, api integration etc etc and general management as a result of this change, what are the real world implications of leaving these sites in out 3 networks ?  I get the example of different schools starting at different times, but how many channel and power changes happen as a result of this in the real world ?  I note that RSSI of neighbour BSSs metrics is used as part of the decision, this will of course be a local to that AP consideration

Our networks of offices, and libraries and day centres etc have similar usage/opening times to each other within the same network, so I'm trying to gauge if the benefits (if any in our case) will outweigh the added admin overhead...

Would alos be interested in reading the whitepaper mentioned at 41:19 if you can provide a link

Thanks all

[PhilipDAth]

I have a large retailer (for my country) that I look after and we have all of their APs for every location in a single seperate network.  It's been that way for maybe 4 years.  We did it that way because of how they wanted to review the WiFi anayltics.

Never had a problem.