A change to Meraki’s underlying algorithm for Client Balancing is getting an overhaul in version MR29.1.
In early July 2022, Meraki released a public beta of MR29.1 which includes a change in the way Client Balancing is handled.
At Packet6, we’ve always recommended disabling Client Balancing due to how devices negatively reacted.
Prior to MR29.1, a Meraki access point would reject a device association. As a result, the user experience would be poor - often considered as Wi-Fi not working or experiencing long times to connect.
In this blog post, we’ll discuss what’s different in Client Balancing and how it might be useful.
What is Client Balancing?
Client Balancing is a method of steering devices to an access point with less load (or number of devices associated).
There are a few metrics taken into consideration for Client Balancing:
- Load
- Best AP
- Best AP Load
- Best AP RSSI
Load (on the target AP) will identify how many devices are currently associated on the access point. Client Balancing will know the Best AP for a device to associate to, along with how many devices are associated to that AP (called Best AP Load), along with that AP’s RSSI view of the device.
Meraki access points share a database with other nearby Meraki access points containing a list of associated and nearby devices.
Access points form an AP Resource Group for a nearby device, used for Client Balancing. You could consider this as a list of AP neighbors.
Client Balancing MR29.1+
Meraki’s MR29.1 improves the algorithm and operation of Client Balancing.
Previously, devices were steered passively. Starting with MR29.1, Meraki access points will steer passively and actively (using 802.11v).
That means at association and post-association to Wi-Fi, steering can occur.
Because devices ultimately decide where they want to join, having a denied association request could place an SSID on a device blocklist which is used to prevent association to a problematic SSID.
MR29.1 will reject a device association twice before accepting the request.
Wireless standards, such as 802.11v, have been around for many years to help improve roaming to nearby access points. Meraki will now implement 802.11v (for 802.11 compatible devices) as a way to transition devices to another access point.
Using a standardized method is a better improvement than proprietary vendor technology. The implementation can be compatible across vendors and device manufacturers.
How Will This Impact You?
Further testing and device support will help us determine if this is a good improvement to Client Balancing.
The number of denied associations should help prevent devices from hanging in limbo and creating a poor Wi-Fi user experience.
Before relying on proprietary vendor technology to steer devices to a more preferred access point, review your Wi-Fi design.
A well planned Wi-Fi design can help mitigate the need for features such as Client Balancing. On the contrary, these features can help mitigate the load with an influx of devices in a high density environment.
But we must remember.. the devices decide which access point they want to associate to.
Do you have 802.11v enabled on your Meraki network? There isn’t a checkbox that specifically states “enable 802.11v”.
A wireless frame capture can identify if 802.11v, BSS Transition,
Client Balancing can be enabled per RF Profile. Test Client Balancing out on a smaller scale before rolling it out to every environment.
https://mobileinfoworld.com/updates-meraki-client-balancing/
