Wireless Access

We have been experiencing wireless clients from various locations dropping off the wireless network intermittenly for the last few weeks. We are running Aruba 225's with Aruba OS 6.4.2. We are in a health care environment, we broadcast 5 SSID's, 4 strictly for health care devices and 1 guest network. On the health care network dedicated for laptops, runs machine authentication on 802.1x WPA2 Enterprise. This particular network runs on A-Band only, on 5Ghz running HT on the SSID. There is a mixed environment of machines, primarily Dell and Lenovo laptops that are on a standard lifetime refresh cycle of 3 years. The machines that we've encountered most of the issues with are the Lenovo's but also some Dell's with outdated wireless card drivers. But this seems to be a seperate issue, as we've updated the wireless drivers to the latest versions on all of the laptops in our environment. My question to the community is, could HT be a problem on A-band? We have also been testing the ARM feature, but have yet to find it to solve the problem we have been having. We have spoke with Aruba Tech Support, but issue still persists. Thank you all for your help.

 

-James

Quite frankly, 5 SSIDs is alot of SSIDs to run in a busy environment and it can create performance issues.  In a practical sense, you should be running 3 or at most 4.  

 

You are engaged with TAC.  Have they already suggested any changes and is it going in the right direction? (making it better)

Have you always had the issues with dropping, or is it fairly recent?

Since we opened a ticket, tech support recommendation was to enable ARM. Since enabling ARM (it is disabled at other sites) some of the issues have gone away.  However, at those sites with ARM enabled clients are still intermittenly dropping. Most of the issues we are seeing are fairly recent (within the last month or two).

Well, we're moving in the right direction.  Why did you disable ARM?

We disabled ARM because we had wireless clients that would randomly drop, have poor signal, or no signal at all. As soon as we disabled ARM, those symptoms seemed to disappear.

Okay.  By default ARM has "Client Aware" which will not let an access point change channel while clients are associated, so there are protections for that.

 

With that being said, please continue to work with TAC on the drops and keep us apprised of your progress.

Any news? ¬¬

We've recently had some issues with smart phones experiencing the issue. From what I've read, I may have made a mistake -client match- and using handover trigger simultaneously. As I sifted through my logs, I noticed a few hundred clients showing "unsupported" and thought that by turning on the handover trigger, my problems may be resolved. However, I'm still debugging clients to try to sift through for clues. And one thing, if using intel cards update drivers.

Do not use handover triggers.  That is a legacy construct and should not be used.

Do not change any client match settings.  The power of your access points is the main determining factor of how clients roam, if they hold on too long or if they try to roam while they are just "sitting there".

Client Match operates after a client has already made a decision to roam, minimum 2 minutes after it is already on an access point.  It is not a roaming mechanism.  Setting the power of your access points correctly allows them to roam better, so you do not have to consider tuning clientmatch to do anything after.

 

Devices set to "unsupported" means that clientmatch tried three times in a row to steer them and they did not respond.  "unsupported" means that client match will not act on those devices for another 2 days by default.  Again, setting the power on your access points means that (1) they will choose the correct band (2) they will roam more easily and (3) Clientmatch will not have to "clean up" clients that have roamed poorly.

 

If you are setting the ARM-MAX-TX power in your access points to above 18, you are doing it wrong.  Asymetric power between your clients and the access points is the biggest cause of sticky clients, lost data due to one-sided connections and clients roaming randomly and disconnecting, because the power is too high.  Having the power greater than 18 can also cause a great deal of co-channel interference which punishes your wireless performance.

 

If you are setting the 2.4ghz ARM TX power equal to, or more than the 5ghz, you are doing it wrong;  The 2.4ghz band travels further and needs to be less than the 5ghz tx power by at least 3db for clients to want to go to 5ghz instead.

 

If the difference between  your max tx power and min tx power is more than 6, you are doing it wrong; db is logarithmic, so every 3 db increased or decreased is a doubling or halving of radio power, which can be considerable.  Making the difference between the min and max no more than 6 makes cells more even and roaming more even.

 

If you are running 80mhz channels, with any type of density, you are doing it wrong;  There are not enough non-overlapping 80mhz channels to not cause interference.  In addition, no all clients even support 80mhz channels, so you are wasting bandwidth.  Go to 40 mhz channels or even 20 mhz channels.  It will give you more non-overlapping channels to deploy.

 

If you are not dropping broadcasts and multicast at the Virtual AP level, you are doing it wrong.  Multicast and Broadcast traffic are the sworn enemy of wireless traffic.  There is very little if any mission-critical broadcast or multicast applications that are run on wireless.

 

If you are having problems, you should open a TAC case to get their opinion, or even hire a professional reseller to help you plan your network properly.  I frequently see many of the same people with similar complaints that are totally solvable or that can be lessened with a little help from TAC or professional help.

 

We can answer some questions on here, but someone needs to advise users of the "big picture" specific to their environments.  I can imagine alot of users on here see an idea that they like and it gets applied out of context or without taking the big picture into account.  That can hurt more than help.

 

 

Hi!...

 

In my case (i open a case with the same pattern) was a bug and was fixed in 6.5.0.4. I´m did double check with users and i saw a lot of users in 2.4 today! :)

 

The case still open and will remain until monday that i´m sure that this no happen at least by "3 days" after controller update and some "IT/power/frecuent users give me his feedback.

 

Best regards.