There is a feature in the 7.x version that you can enable client load balancing per wlan ssid. However, this feature has caused me issues in the past and is not really worth enabling unless you do a lot of testing. If the users are not having issues, then I wouldn't worry about it, as the client is the one that chooses what ap it wants to join.
Aggressive load-balancing on the WLC allows the LAPs to load-balance wireless clients across APs in an LWAPP system.
This feature can be used in order to load-balance clients across LAPs on a single controller.
Aggressive load-balancing works at the association phase. If enabled and the conditions to load-balance are met, when a wireless client attempts to associate to a LAP, association response frames are sent to the client with an 802.11 response packet that includes status code 17. This code indicates that the AP is too busy to accept any more associations.
It is the responsibility of the client to honor, process or discard that association response frame with reason code 17. Some clients ignore it, even though it is part of the 802.11 specification. The standard dictates that the client driver must look for another AP to connect to since it receives a "busy" message from the first AP it tries. Many clients do not do this and send the association request again. The client in question is allowed on to the wireless network upon subsequent attempts to associate.
In WLC versions 220.127.116.11 and earlier, the controller only sends one association response frame with reason code 17 to the client. If the client decides to discard the reason code 17, the client can try the same AP again and this time the AP allows the client to complete the association.
If the client honors the association response status code 17, the client then attempts to associate to a different AP. For example, if load-balancing is enabled and the load-balancing window is configured as five clients, when a sixth client tries to associate to the AP, the client receives an 802.11 Association Response frame with status code 17, which indicates that the AP is busy.
"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
Transferring Crash file from standby: Login to the Active WLC in HA.
From CLI: (Cisco Controller) >transfer upload datatype crash (Cisco
Controller) >transfer upload filename (Cisco
Controller) >transfer upload mode tftp (Cisco Controller) >transfer
This is the start of a display filter cross reference between Wireshark
and OmniPeek. The 1st installment is a table of advanced filters. More
filters will be added as time allows. It is a living doc, so check back
for changes every so often Please feel f...