Higher Education

I was wondering if anyone else has experienced this behavior before.  We have 2 AP's in one classroom, due to the high number of devices present.  They work just fine initially, and everything is balanced out between the 2.  But after a certain amount of time (call it 10 days), they will stop balancing clients, and one AP will take over.  On the 5Ghz band it will take all the clients, and on the 2.4Ghz band it will take the great majority of them.  When we reboot the AP's, they work fine again until those days/weeks later when it reoccurs.

 

Anyone seen behavior like this before?  We do not have a lot of deployments with 2 AP's in a classroom, but definitely have multiple AP's in other open spaces such as the library and cafeteria, and we do not experience the same issues.  

 

For some numbers, we are talking about ~75 devices on one radio (5ghz), including around 45 desktops that we control and 30 mobile devices that we do not.  I'd blame bad network adapters in those PC's, but that doesn't explain the mobile devices as well.  

 

Also, we've updated both AOS and Airwave versions during the time we've experienced this issue, with no change.  

 

TIA

- Is this Instant, or a Controller-Based Deployment?

- What version of Aruba or InstantOS is this?

- In your ARM profile what is your Min and Max transmit power for each band?

 

Colin,

 

Controller based (7210), 6.4.4.9, and we are at 12-18dbm for 5ghz, 6-9dbm on 2.4Ghz.  

 

Both AP's are currently at 15dbm and 9dmb, respectively.  

 

Since rebooting the AP's an hour ago, we hvae 44 clients on one AP and 26 on the other.  Which is fine with us, if only it continued that way.

The load balancing algorithm has to hit multiple thresholds to induce load balancing. And only then, the client has to have an appropriate option as seen in the VBR.

Take a look at this output:

show rf arm-profile $YOURPROFILE | include "Client Match Load"

Then, for a client you feel should be load-balanced, look at:

show ap virtual-beacon-report client-mac $YOURCLIENT

That should help you diagnose if a client actually should be balancing. It could be that it is trying and just failing to do so. This is your friend:

show ap arm client-match history client-mac $YOURCLIENT

Hope that helps!

- Ryan -

Thank you Ryan.  I ran those commands, though the output is confusing.  Some of the clients state they are steerable, while others state that they are not, but the steering seems to fail for all of them.  I understand the clients are still in charge, I just wonder why it seems that this particular location is such a problem spot.  

 

Is there a VRD in particular for a high density room like this?  I've used the ASE in the past but haven't found any candidates to solve this issue.  About the only thing I can think to do is put hardcoded rules in place for that room, which I do not think is the way to go long-term.  

FWIW, this is what I do for our classrooms, and it's been pretty successful.

- no channel bonding (20MHz only)
- DFS channels enabled
- Channel 144 and 165 are excluded
- 2.4GHz radios @ 3dBm min and max
- 5GHz radios @ 6dBm min and max
(NOTE: these power levels assume the AP is at a reasonable height and not too far from clients.)
- APs are installed evenly throughout the room
- APs nearest the entrance to the room have 2.4GHz radios disabled as to avoid clients first hopping onto 2.4GHz and having avoidable steering attempts
- Tx rates are 24 and up
- Basic rates are 24
- Beacon rates are 24

Other things to try / think about:
- How do each of the 2 APs hear any given client? Is it roughly equal?
- If client has ≥-70dB to a radio, it'll likely take some serious incentivizing to get the driver to want to move on its own
- Where are clients sitting? If one AP is in the back and one in the front, yet clients are aggregating to one end or the other, that could explain things
- At what data rates are clients communicating (show ap debug client-table ap-name...)?
- Even with the 75 clients on the one AP, what is the channel busyness? If it's insignificant, you may be okay to say "who cares" (show ap debug radio-stats ap-name $APNAME radio $0_or_1 | include Busy)
- Run an Airwave "Match Event" report on those two APs for a week with details and see what type of client match activity is occurring

- Here's the innards of our arm-profiles if it helps at all:

rf arm-profile "osu-arm-2.4ghz-classroom-1-3aps"
40MHz-allowed-bands None
no 80MHz-support
max-tx-power 3
min-tx-power 3
ideal-coverage-index 6
free-channel-index 40
backoff-time 1800
error-rate-wait-time 180
cm-unst-ageout-intvl days 0 hours 2
cm-band-g-max-signal 10
cm-band-a-min-signal 70
cm-steer-timeout 3
cm-lb-snr-thresh 25
!

rf arm-profile "osu-arm-5ghz-classroom-1-3aps"
40MHz-allowed-bands None
no 80MHz-support
max-tx-power 6
min-tx-power 6
ideal-coverage-index 6
backoff-time 1800
error-rate-wait-time 180
cm-unst-ageout-intvl days 0 hours 2
cm-band-g-max-signal 10
cm-band-a-min-signal 70
cm-steer-timeout 3
cm-lb-snr-thresh 25
!


- Ryan -

FWIW, this is what I do for our classrooms, and it's been pretty successful.

- no channel bonding (20MHz only)
- DFS channels enabled
- Channel 144 and 165 are excluded
- 2.4GHz radios @ 3dBm min and max
- 5GHz radios @ 6dBm min and max
(NOTE: these power levels assume the AP is at a reasonable height and not too far from clients.)
- APs are installed evenly throughout the room
- APs nearest the entrance to the room have 2.4GHz radios disabled as to avoid clients first hopping onto 2.4GHz and having avoidable steering attempts
- Tx rates are 24 and up
- Basic rates are 24
- Beacon rates are 24

Other things to try / think about:
- How do each of the 2 APs hear any given client? Is it roughly equal?
- If client has ≥-70dB to a radio, it'll likely take some serious incentivizing to get the driver to want to move on its own
- Where are clients sitting? If one AP is in the back and one in the front, yet clients are aggregating to one end or the other, that could explain things
- At what data rates are clients communicating (show ap debug client-table ap-name...)?
- Even with the 75 clients on the one AP, what is the channel busyness? If it's insignificant, you may be okay to say "who cares" (show ap debug radio-stats ap-name $APNAME radio $0_or_1 | include Busy)
- Run an Airwave "Match Event" report on those two APs for a week with details and see what type of client match activity is occurring

- Here's the innards of our arm-profiles if it helps at all:

rf arm-profile "osu-arm-2.4ghz-classroom-1-3aps"
40MHz-allowed-bands None
no 80MHz-support
max-tx-power 3
min-tx-power 3
ideal-coverage-index 6
free-channel-index 40
backoff-time 1800
error-rate-wait-time 180
cm-unst-ageout-intvl days 0 hours 2
cm-band-g-max-signal 10
cm-band-a-min-signal 70
cm-steer-timeout 3
cm-lb-snr-thresh 25
!

rf arm-profile "osu-arm-5ghz-classroom-1-3aps"
40MHz-allowed-bands None
no 80MHz-support
max-tx-power 6
min-tx-power 6
ideal-coverage-index 6
backoff-time 1800
error-rate-wait-time 180
cm-unst-ageout-intvl days 0 hours 2
cm-band-g-max-signal 10
cm-band-a-min-signal 70
cm-steer-timeout 3
cm-lb-snr-thresh 25
!


- Ryan -

EDIT:  I did not see what Ryan wrote above.  It is definitely worth a look.

 

The load balancing algorithm is fairly complicated, but it boils down to:

- Average the Number of Clients on each radio in an AP "neighborhood"

- Determine if any AP has more or less than 20% (cm-lb-thresh) of the average by default

-  If the AP has more, get a potential candidate AP to move it to

-If the AP has less, seek to move clients from another AP in the first category to that AP.  That is based on the Virtual Beacon table seeing that the client to be considered is seen by the target AP at a good enough signal strength.

- There is also the cm-lb-client-thresh parameter (default 30) which determines the absolute number above which an AP will always consider load balancing.

 

There are also a few more parameters that affect load balancing, but the best thing you can do is limit your RF neighborhood by turning down the power 3 clicks on the 5ghz band, because a transmit power of 15 could make it more attractive to clients outside the room.

 

This is on top of clients constantly coming and going, and load balancing is not something that happens perfectly in realtime.  Load balancing also only happens on the same band, not across bands.  

 

Lastly, RF utilization sometimes is dependent on the number of clients on a radio, but sometimes it is not, because many users can be dormant on a radio with quite a few users.  Client traffic is also bursty, so even if there is activity, it could temporarily increase utilization and then go away.

 

Long story short, reduce your power to confine your clients to a specific room.  If you are only providing wireless access to devices in the same room you can run the 2.4ghz at a tx of 3 and the 5ghz at a tx of 9, and that might yield better results, by confining your users to the same room.  You could also improve performance by reducing some of the lower rates.  Doing those two things could improve your performance without worrying about load balancing...