Aggressive Load Balancing = unstable network

Unanswered Question
Mar 4th, 2010
User Badges:

Last week we upgraded 26 WLCs 4400 controllers from version 5.2.178 to version 6.0.188.0/6.0.196.0.


Two days after the upgrade, IT-administrators had reported problems with 15 of the WLCs.

The symptoms was:

- Problems conntecting to SSIDs

- Unstable network when connected

- Clients didnt get a IP-adress

- Unstable signal strength


After some troubleshooting, it turned out "Aggressive load-balancing" was enabled on the WLCs having these problems.


Output from one WLC:


(Cisco Controller) >show load-balancing

Aggressive Load Balancing........................ Enabled

Aggressive Load Balancing Window................. 0 clients

Aggressive Load Balancing Denial Count........... 3

                                                    Statistics

Total Denied Count............................... 5873 clients

Total Denial Sent................................ 14067 messages

Exceeded Denial Max Limit Count.................. 2924 times

None 5G Candidate Count.......................... 8215 times

None 2.4G Candidate Count........................ 2331 times


Yesterday we ran this command on these WLCs:


config load-balancing aggressive disable


..and the problems now seem to have dissappeared.


Aggressive load-balancing is disabled as default in the newest versions of WLC software, but we have upgraded since version 4.0.155.5 (where I think this was enabled as default), and I guess this setting was enabled because of that.

Some info from cisco.com about aggressive load balancing:


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.




Just wanted to post this in case others are experiencing problems like we did

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

Actions

This Discussion

 

 

Trending Topics - Security & Network