Client Balancing
Overview
Client balancing aims to steer devices to associate with the best available access point (AP). When a client attempts to connect to a busier AP, the AP rejects the connection, prompting the client to connect to a different AP until it finds the one with the least usage. Since many clients and/or applications do not handle these rejections appropriately, we suggest not enabling client balancing in your network.
Depending on the firmware version and client type, the AP rejecting the association might provide specific information about the least loaded AP, giving the client a higher chance of connecting to it on the second attempt. When the client is already connected, the AP may also advise the client to move to another AP with more resources.
For details about how the algorithm works, please refer to sections Client Balancing Behavior - MR 29.X and Newer Firmware or Client Balancing Behavior Prior to MR 29.X Firmware.
Client balancing is available in MR 25.X and more recent firmware and is disabled by default in RF profiles. It was first introduced under the name AP Steering.
Client Balancing Behavior Prior to MR 29.X Firmware
Metrics
Several metrics are gathered by each AP to ensure that the best client and AP match is made. RF environment metrics and the algorithm's wireless clients heard by APs are factors. These measurements are captured in real-time and shared amongst nearby APs in the Meraki network.
Information Exchange
Each AP has a local database that stores clients' metrics, both associated and not associated. This information is shared between each AP on the LAN via broadcast messages with an encrypted payload. Note that this message encryption is dynamically configured and secured by the Meraki cloud.
Note: Broadcast frames for this information use UDP port 61111 and are sent over the LAN infrastructure.
APs on the same LAN segment will automatically send and learn the information needed to make informed client balancing decisions. This feature was designed for nearby APs, which typically reside on the same LAN segment (for example, a floor or a building may all share a common management VLAN). Since Client Balancing information is sent via broadcasts, any existing network segregation will ensure that Client Balancing intelligence is kept within its relevant area.
Note: Since the feature relies on AP to AP communication, administrators need to ensure that inter-AP communication is allowed and port isolation is turned off.
Warning: If you use multiple management VLANs for APs in the same Meraki dashboard network, ensure they're correctly pruned. APs will acknowledge UDP 61111 traffic regardless of what VLAN it arrives on, which is necessary to avoid inaccurate load-balancing metrics.
Client Measurements
Each AP measures the RSSI for management traffic sent by nearby clients. The Meraki RSSI is a combined measurement of noise floor and client signal strength, and it’s normalized across MR models. Each access point records client measurements in its local database and distributes the info to neighbor access points. The tables update in real-time as updates are triggered, allowing the APs to react more quickly when making steering decisions.
Load Measurements
Each APs current load is also shared with its neighbors. The load metric is defined as the number of existing clients connected to the AP. The load metric determines a better possible AP for a client connection.
Distributed Intelligence
Client Balancing operates without cloud interaction and utilizes several robust features discussed below to make steering decisions.
Per-Client AP Resource Group
The Meraki APs create an AP resource group for each client. A resource group is made based on the notion that not every AP in a network is a good candidate for the client's next connection. Therefore, when multiple APs hear a given wireless client at 30dB or higher, those APs become a resource group for the client. The load algorithm then attempts to load APs within a client resource group evenly.
Note: If a client is not heard by any AP at an RSSI of 30 or higher, it will not be steered.
Roam-Through for VoWiFi/VoIP
Clients using real-time applications like VoIP or video collaboration roam from one AP to another using fast roaming technologies. For example, suppose a Meraki MR access point senses this roaming by detecting a re-association frame. In that case, the client will be permitted to join regardless of whether there is another preferred AP to ensure minimal roaming latency for these sensitive applications.
SSID Awareness
Client balancing only analyzes directed probe requests from clients for SSIDs configured on the AP when considering an AP in a particular AP resource group. This behavior ensures that client balancing will continue to make the most intelligent decisions even if the SSID availability feature is enabled or a radio on a particular AP is disabled.
Sleeping Client Detect times out data for mobile clients that are not actively roaming but physically moving. For example, a mobile device is in your pocket while in power-saving mode. Mobile devices tend to shut down radios to preserve battery life. When the mobile device leaves sleep mode, it will re-connect to the wireless network.
Many environments are designed with APs in distinct areas where the APs do not see clients in each area in other areas. If a client is measured in one area and then moves to a new location while in power save mode, the APs may not be able to track the roam. Measurement data for the client times out after 10 seconds to ensure that APs only within the physical area local to the device are used for steering decisions.
BSSID Block List Protect
For various environmental or wireless adapter driver reasons, a client may not always transition to a preferred AP as the client balancing feature offers. However, it will always be admitted if the client attempts to associate with the same AP a second time.
Note: This failsafe mechanism ensures that a client will only experience a brief delay when resending association frames (usually less than 5ms) and that the client does not block the BSSID. Clients occasionally employ BSSID blocklisting to prevent continuous connection failure.
Steering a Client via Association Rejections
During the association process, a client may be rejected with a reason code 17 message indicating that the AP is busy in order to guide the client to a different AP.
802.11v basic service set - transition management
Modern clients support 802.11v - BSS-TM (Basic Service Set - Transition Management) which enables network information to be exchanged between the AP and client. During the association process, clients and APs mutually determine if 802.11v BSS-TM can be used. An unsolicited 802.11v BSS-TM frame may be sent from the AP to the client which can indicate to the client that there is a more preferred AP to be connected to. The BSS-TM frame includes a list of neighbors and a report of each of their current loads. This additional information provided to the client reduces client scan times making for graceful steered roams.
Note: This feature has not been implemented until MR 29.1 firmware.
Event log reporting
Dashboard will report when Client Balancing is triggered for a client within the Event Log. Using the Event Log's built-in filtering, an administrator can filter on load balancing events and drill down to a particular access point or client if required. The event will report details about which AP is preferred for the client association.
Legend:
- load - Number of current clients on the Client Balancing AP
- best_ap - IP address of most preferred AP for client to join
- best_ap_load - Number of clients connected to the most preferred AP
- best_ap_rssi - Client probe request signal strength measured by preferred AP
Client Balancing Behavior - MR 29.X and Newer Firmware
The client balancing technique described in the previous section is passive client balancing. APs would only attempt to load balance clients to a better AP (if one is available) at association time. The new active client balancing technique has been introduced in MR 29.X firmware, where an AP would try to steer already associated 802.11v-capable clients to a better AP (if one is available) using BSS-TM frames.
Note: When client balancing is enabled in RF profiles on a network running MR 29.X or newer firmware, active client balancing is enabled by default for 802.11v-capable clients, and passive client balancing is maintained for clients that don’t support 802.11v.
We made the following changes in MR 29.1 firmware:
-
APs will try to steer clients to a better AP (if one is available):
-
At association time with the reason code 17 (passive client balancing for non-802.11v clients) without indicating a list of neighboring APs to connect to.
-
At association time with BSS-TM frames for 802.11v-capable clients, indicating a list of neighboring APs to connect to.
-
Post association with BSS-TM frames for 802.11v-capable clients by indicating a list of neighboring APs to connect to.
-
-
An AP can only attempt to load balance the client or reject an association request two times for both active and passive client balancing.
-
Suppose a client sends an association request the 3rd time (passive client balancing). In that case, the AP will a) accept the association request and b) mark this client as persistent and won’t attempt to load balance this client even with active client balancing for the duration of the client’s association.
-
If a client does not move to a different AP after two attempts (active client balancing), the AP will mark this as persistent and won’t attempt to steer this client for the duration of the client’s association.
-
Note: Active client balancing is not enabled for non-802.11v clients because it can only be done by sending dissociation frames to such clients, which would lead to unexpected client disconnections.
-
MRs check parse probe requests, association, and re-association requests to determine 802.11v client capabilities.
Before MR 29.X, firmware APs would only parse probe requests which did not always allow to capture 802.11v client capability. In cases when a client does not send a probe request and sends an association request instead. This enhancement enables APs to track 802.11v clients’ capabilities better.
-
Improved LAN message exchanges between APs
-
802.11v client capabilities are exchanged between APs for more accurate tracking.
-
Clients do not always advertise 802.11v capability in association/reassociation requests which means that after the client has been load balanced once, this capability might get lost on the new AP. To avoid this, the APs now include the clients’ 802.11v capability in the messages exchanged between AP on the LAN via UDP 6111.
-
-
Improved steering metrics
For pre-association (passive) client balancing, MRs use the same logic based on RSSI and AP load as in MR 28.X and older firmware with optimized metrics to ensure that the client balancing does not happen or lightly loaded APs or too often.
For post-association (active) client balancing, MRs use a new proprietary algorithm that considers AP load and links quality between a client and a candidate AP.
Client Balancing Comparison Table
The differences between client balancing implementation in pre-and-post-MR 29.X firmware are highlighted in the table below.
|
Feature |
Pre-MR29.X |
Post-MR29.X |
|
APs will try to steer clients… |
Only at association time (passive client balancing) |
At association (passive) and post-association (active client balancing) |
|
APs may reject an association request (passive client balancing)... |
Only once then accept an association request |
Two times then accept an association request |
|
APs will try to steer an associated 802.11v client (active client balancing)... |
N/A (no active client balancing) |
Two times then mark the client as persistent and stop steering attempts fro the duration of the session |
|
Default client steering mode |
Passive for all. Clients may be steered to a better AP (if one is present) only at association time and only with the reason code 17 |
Active for 802.11v-capable clients at an association or post-association via BSS-™ frames. Passive for non-802.11v clients with the reason code 17 only. |
|
802.11v client capability is determined based on… |
Probe requests only |
Probe requests, association, and re-association requests. |
|
802.11v client capability is exchanged between APs on the LAN |
No |
Yes |
|
Maximum association rejects (passive client balancing) before a client is considered persistent |
1 |
2 |
|
Maximum load balancing attempts (active client balancing) before a client is considered persistent |
N/A (no active client balancing enabled) |
2 |