Bad roaming in Meraki

[fjulianom]

Hi guys,

According to Meraki documentation: As a wireless client roams in an area covered by Meraki APs advertising the same SSID, it will try and associate to the AP that provides the strongest signal.

I have 4 APs in my office which are near among them. For that reason I have configured them with 6 dBm for 2.4 GHz and 12 dBm for 5 GHz (the difference of 6 dB is for contributing to the natural band steering). But I see there are sticky clients, the clients don't roam though they are receiving a strongest signal from other AP. Even turning off and on the Wi-Fi client in a laptop in a new location where receives stronger signal from a new AP (-42 dBm), it gets connected to the previous AP which is farther and from which receives weaker signal (-65 dBm). What can I do to facilitate roaming? Is there any feature in Meraki to touch?

Regards,

Julián

[ww]

make sure client drivers are up to date and test some clients with roaming set to agressive in the client driver settings.

also you can set the minimum bitrate to a higher value in the dashboard, for example 24Mbps

[fjulianom]

Hi ww,

I have set the minimum bit rate to 12 Mbps. I will try with the driver settings.

Thanks very much,

Julián

[MerakiDave]

For starters, consider running the SRC (Stable Release Candidate) firmware 25.9 if you're not already.  You could check with Meraki Support first to scrub your config and confirm 25.9 is a good choice, just in case there's a known issue specific to your environment or AP models.

Remember that it's ALWAYS the clients (not the APs) that ultimately make the roaming decisions, and it varies wildly by device vendor, by operating system, and by device driver versions. I've seen devices cling for dear life to an AP 50 feet away when it's right underneath another AP. It's very device-dependent.

So we cannot control the clients, but we try to get them behaving well via best practice settings. And even then, they don't always behave well, and still varies by device type, OS and driver version.  And don't forget that every RF environment is going to be different, and in a given RF environment, every client is going to have a different perception of it.  Different vendors and different operating systems will use different methods, often based on RSSI, which is typically proprietary and different phone/laptop/tablet manufacturers implement in different ways.

So it's entirely possible that client devices can stay "sticky" to an AP even on a floor above or below (through a ceiling or floor) even with another AP in the same room. Obviously there's going to be signal attenuation through a ceiling/floor, but there could still be enough signal strength to keep the client happily associated at a reasonable data rate.

Newer clients that support 802.11k, 11v, 11r (all of which are there in r25 firmware) can leverage neighbor reports to interact with APs to make optimal roaming decisions, and APs can assist with client balancing, but still, it's the client who makes the decision and initiates the roam. And that decision process is a dynamic one with constantly changing variables, such as people (attenuators) moving around.

I've observed similar behavior in my own home, where I have an AP in my basement office and an AP in a 2nd floor bedroom. Some devices will consistently roam from AP1 to AP2 when I get within 15 feet of the AP, while other devices will stay associated to AP1 no matter how close I get to AP2. The behavior isn't perfect but improved with newer firmware.

And implement standard best practices, like setting minimum bit rates to 12Mbps (for example), using automatic power reduction, band steering to favor 5GHz, minimizing the number of SSIDs, using an appropriate channel width, including DFS channels if appropriate, etc. 

And of course you can always get with Meraki Support to take a closer look at your specific APs and clients where you’re seeing roaming issues.  Many "roaming issues" can actually be normal behavior given client dependencies and so many variables.  Still, Support has additional tools on the back-end to get some insight on how the APs are behaving and communicating regarding client roaming and steering.  

More info

https://documentation.meraki.com/MR/Other_Topics/Client_Balancing

https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/802.11k_and_802.11r_Overview

https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Roaming_Technologies

[fjulianom]

Hi MerakiDave,

I am not a starter at 802.11 though I am in the Meraki world. 

For starters, consider running the SRC (Stable Release Candidate) firmware 25.9 if you're not already.  You could check with Meraki Support first to scrub your config and confirm 25.9 is a good choice, just in case there's a known issue specific to your environment or AP models.

The APs are updated to firmware 25.9.

Newer clients that support 802.11k, 11v, 11r (all of which are there in r25 firmware) can leverage neighbor reports to interact with APs to make optimal roaming decisions, and APs can assist with client balancing, but still, it's the client who makes the decision and initiates the roam.

I could enable 802.11r but according to Meraki some clients may not be able to join the network, so I think is better to not enable it to avoid compatibility problems with some clients.

And implement standard best practices, like setting minimum bit rates to 12Mbps (for example), using automatic power reduction, band steering to favor 5GHz, minimizing the number of SSIDs, using an appropriate channel width, including DFS channels if appropriate, etc. 

I have implemented most of the above.

And I completely agree that the device which makes the decision to roam is always the client and not the APs, although we can make adjustments to favor the roaming as you said.

By the way, very great explanation! 🙂

Regards,

Julián

[PhilipDAth]

I nearly always enable 802.11r.  I don't have that many compatibility issues.

[PhilipDAth]

Another question I often ask clients is; if I enable 802.11r 99% of your clients will get an improved roaming experience, but 1% of the devices, mostly very old devices, may no longer connect.  Do you want to sacrifice the benefits gained by 99% of the users to still support the 1%?

I think every time they get me to turn on 802,11r.  Often it is just a commitment to replace the small number of those very old devices that don't support it.  Hey they just spent a pile of money putting in a nice new Meraki WiFi network - while cripple its features?

[fjulianom]

Hi Philip,

That's makes a lot of sense. I will comment this with customer.

Regards,

Julián

[MerakiDave]

Another option regarding the 802.11r question is that if you have some percentage of devices that may not support it, and you want to give 11r benefits to those that do, and you're running r25, perhaps consider the "Adaptive" setting instead of just the enabled/disabled settings.  Clients who don't support it should still be able to join the SSID and just not leverage 11r.

[PhilipDAth]

The problem with "Adaptive" is that it only works with Apple mobile devices.

[fjulianom]

Yes, that's the reason for which I didn't consider Adaptative 802.11r.

Regards,

Julian

[VascoFCosta]

From my experience; I would focus more on the client equipment’s than with the Meraki APs (or other vendor APs). 

Got a situation where all clients worked fine except a specific brand and type of smartphones. Those phones would work fine throughout the different floors but, from the several packet captures that I've done, I notice that as soon as they detected a beacon from the AP that was used one the first time they registered on the network, they would try to roam back to it, even if they were already registered in APs with the much better RSSI and SNR values.

Have you checked the technical doc's or support communities from those equipment’s?

[fjulianom]

Hi,

I find an option in Meraki which I think it has to do with roaming directly, which is the "Client balancing" feature. When I enable this feature I can see some logs like this:

The AP rejects the association according to load balance, even if the client is receiving stronger signal from this AP. So I don't know how good is to enable this feature, especially for environments with few clients.

Regards,

Julián

[MRCUR]

You may find that the client load balancing feature is best left disabled in a low density setup. Otherwise you'll see these rejections happening. Some clients don't handle that well in my experience and end up in a state where they simply keep trying to associate with the AP that is rejecting them. 

[fjulianom]

Hi MRCUR,

Good information! Thanks!

Regards,

Julián

[PhilipDAth]

I would leave Client Balancing on if you can.  Especially if you have nice 802.11r enabled.

Lets say a client can see two access points.  One has no clients, and the other has 30 clients.  If it attaches to the AP with 30 clients it allows the client to be given an indication that it should attach to the other AP.

[fjulianom]

Hi Philip,

You are right, but that the client can attach to an AP which receives weaker signal from is also true. This is my case right now and therefore my laptop browsing speed is lower. In my case it makes no sense since in my office we have 4 APs and we are around 35 people. What was stated by MRCUR is also true.

Regards,

Julián

[Dylan_YYC]

Wow, great information! Thanks for posting!