Wireless Access

Hi

I just wanted to share some experiences with high density ares and AP-220 series.

I large customer had much of the same issues explained in this tread, not only towards Intel.

They saw random disconnects, even failure to connect.

We could actually see that the client was unabel to get a lock on the AP when roaming, PHY state was suddenly g, not a-HT or a-VHT.

Often had to reboot computer or disable/enable the wireless device to get it running again.

The Aruba system was running with most of the settings default, VHT and CM enabled and all.

This happened only on AP-220, when moving to a buidling with the older AP-130 series, the issue was not seen.

After weeks with TAC, i was given some new RF settings to use with AP-220 in particular.

We ended up running AP groups for only AP-220 beacuse of this.

The problem was related to too agressive Client Match etc, hence the roaming did not work, so users was disconnected.

I use these settings whenever i install a system running AP-220's, this has proven to be very stable.

As i understand much has changed with new drivers, but these settings a worth a shoot.

This particular customer is running controller-based, but i guess this was aparent allready.

As these problems happend over a year ago, the controllers in question was running 6.3.1.x, and they have been upgraded across 6.4 without problems.

Settings we implemented are as follows:

rf arm-profile "default.armg.11ac"
  cm-sticky-snr 15
  cm-sticky-min-signal 65
  cm-steer-timeout 3
  cm-lb-thresh 30
  cm-lb-client-thresh 30
  cm-max-steer-fails 2
!
rf ht-radio-profile "default.htrpg.11ac"
!
rf dot11g-radio-profile "default-g.11ac"
   arm-profile "default.armg.11ac"
   ht-radio-profile "default.htrpg.11ac"
!
rf arm-profile "default.arma.11ac"
  cm-sticky-snr 15
  cm-sticky-min-signal 65
  cm-steer-timeout 3
  cm-lb-thresh 30
  cm-lb-client-thresh 30
  cm-max-steer-fails 2
!
rf ht-radio-profile "default.htrpa.11ac"

Hope this will help you

Roar Fossen

There are some ClientMatch settings that were tweaked in later 6.3.1.x codes however, we STRONGLY recommend using our RF optimization solution on any deployment moving forward.  It is located here - 

https://ase.arubanetworks.com/solutions/id/75

In addition, we have published our 11ac reference design docs as well

http://community.arubanetworks.com/t5/Validated-Reference-Design/RF-and-Roaming-Optimization-for-Aruba-802-11ac-Networks/ta-p/227716

http://community.arubanetworks.com/t5/Validated-Reference-Design/Very-High-Density-802-11ac-Networks-Validated-Reference-Design/ta-p/230891

Of the Client Match settings listed, the only two that are not defaults (6.4.2.5 code) are:

• cm-steer-timeout 3
• cm-lb-thresh 30
  
• cm-sticky-snr 15

I have created new policies with the 2  of the above settings as well as some of the recommended RF and Roaming settings:

rf arm-profile "A_Optimized"
max-tx-power 18
min-tx-power 12
backoff-time 1800
error-rate-threshold 70
error-rate-wait-time 90
cm-steer-timeout 3
cm-lb-thresh 30

rf arm-profile "G_Optimized"
max-tx-power 12
free-channel-index 40
backoff-time 1800
error-rate-threshold 70
error-rate-wait-time 90
cm-band-g-max-signal 10
cm-steer-timeout 3
cm-lb-thresh 30

I have yet to test this as I just enabled it. I will find out Monday if I'm having better luck.

To be honest, the RF settings much more determine the success you will have vs. ClientMatch.  If the RF is not designed properly, ClientMatch will not be able to do its thing.

Use the "show ap radio-summary" command to see your RF utilization numbers in the middle of the night, and then during the day.  Your utilization should not be more than 50% sustained for good performance.