Hello I have a 7210 running 6.4 (pre-release). I have a few users complaining of disconnects randomly. When I look the users up in Airwave I show low health and very low SNR. It makes me believe that for some reasons the users are not being handed off between APs.
We use AP-105s.
The users are mostly on Windows systems 8 and 8.1. I have PMKID turned off on the clients. What do you suppose would make clients behave this way?
I would also like to say it is not EVERY client, it is a select few which leads me to believe it's a client issue and not a network issue.
Have you looked at clientmatch events to see if they correspond with user complaints? You should be able to see the match events in airwave.
This is the Events I see. I am not sure where I would go to see client match events?
Those ARE the events. You have alot of sticky client events and that could be because the power on your access points are too high. I would first backup my flash and then try setting the ARM min and ARM max to 12 and 18 respectively. That way, clients will not hang onto APs longer than they should.
Does changing ARM settings require reboot to take effect?
Collin i did not know this!!!
How does having high power on the AP affect the client match?
It is possible if you could explain it with more detail? i would like to understand!
I think we should ask Ereader22 what he did. He did more than lower the power.
Starting off the power between 12 and 18 means that clients can start off in a good state so that Clientmatch does not have to "fix" them in a bad state. It is more about starting off your network healthy, rather than helping clientmatch.
So basically if you got for example an AP 105 which go up to 23 db is bad?
Why does it start from a bad state when they are connecting to an ap with max output power?
Thanks Collin im getting good info here :)
I would like to know this because some clients got the output power to the max so they can cover some areas without buying more APS.
It would be really helpful to know the reason of why is it bad so i can explain it!
fwiw, people who have misconfigured 2.4g radios to max power (usually by jamming min-tx power in ARM profile to 127 or 21 etc) is one of the most common causes of sticky clients I see in the field, especially with Android phones.
Splitting the arm profile and maintaining the 2.4g max tx power at (or or better still below) 5g min tx power will greatly reduce this and improve what some are calling 'natural bandsteering'. If the population of devices is known to be predominantly dual band, then even creating a 3-6dB spacing between max-tx for 2.4g and min-tx for 5g will drastically help.
NightShade - the reason is that the roam threshold of the device is quite low and whilst the signal is good enough to stop it roaming, client match knows it's closer to another AP, hence it falls into steering category. It's basically the classic case of sticky client, but, it's exacerbated by too high power on 2.4g and roaming behaviours of certain devices (i.e. smartphones versus a laptop with roaming set to medium or even aggressive).
I do undersand that
But my question was regarding of what happens with an AP 104 and if it has external atenas a semidirectional one, which focus de beam to reach further.
How does this affect to clients? which does not have a semidirectional antenna to focus the beam to asnwer back???
I mean this antenas would be used for specfifc scenarios...
I do get lot of clients asking me why do we need soo many APS why dont we just use a semidirectional antena so it can reach further, and i want to have this clear to asnwer correctly to this type of statement... also to know how does this work!
I really dont use external antennas, i use 95% of times internal antenas like aP 205, 215 etc.
Long time ago about this post, but did you find out the answer to your question about APs with semidirectional antennas and clients? I am curious because most of the time I use APs with internal antennas, but I have cases where I used APs with semidirectional antennas (AP-277) to give coverage to large outdoor halls and the clients were cell phones.
I almost forgot to come back and fill you in. Changing the max power has really helped with a lot of the issues.
Aside from that, we downloaded the new driver straight from Intel since the Lenovo update application is behind a few revs.
The combination of the two really did the trick for us.
Please let us know anything else that you did, if you did to make things better. Users always want to hear from users.
To add some quick color, without knowing 100% if this was the solution...and I will use some analogies over specific RF terms...EDIT: And I am not going to bring in TxBF, MRC, etc. This si more a mental excercise.
The issue with running your indoor APs at such a high power is that, while it makes the coverage 'look' good (since there's RF blasted everywhere and so all the client devices report super great signal), the clients themselves do not have the same power and antenna gain to support 'reach back' at the same level. So take an AP at 23dBm and a client at 17dBm (which is actually higher than most devices like phones and tablets), that is at least a 6dB difference in the link budget. That means the AP has at least 4 times the power output of the client.What occurs next is the client says 'hey I think I have great signal, I am going to stay with this AP and ask to negotiate a high data rate'. Except when this happens, it doesn't actually work that way. The client may try to run at MCS15 (as an extreme example), but in reality, the client is too far away such that the smaller power output of the client can't really 'push' MCS15 back to the AP. The result is the transmit fails and the client falls back on slower rates until it gets an ACK back from the AP. Carrying it further, if a client is a long distance away from the AP, while the 23dB power output may be enough to get the frames to the client, the 17dB client is not powerful enough to send a frame back. A such, the client keeps re-transmitting without ever getting an ACK, and may chose not to want to roam because it thinks it has great signal from it's associated AP.
In short, everything works best indoors when the AP power output (in general) matches the client power output you are supporting. 25-50mW is pretty much the range of client device power output for most consumer WiFi devices (small phones to laptops, respectively). If all your laptops have a 100mW radio with a 3dB antenna then I would say you can run your APs wide open.
So the controller and APs have some mechanisms to help address these conditions, like Client-Match, probe-response thresholds, etc which are great tools to have, but maxing the power ouput of all the APs means the system can't work as well because it creates the above issues (and others like more broad ACI/CCI which raises the noise floor and decreases Rx sensitivity across the board, etc). So better to set ARM to use a more manageable range of power that is commisurate with the device types you are looking to support, so that the 'system' starts off 'healthy' in the first place.
Hope that helps.
Thanks for your awsome explanation Howard! now it seems really clear to me
Ah I see I've spurred some interest.
I am actually at a Small university. We have a REALLY dense AP population. This was a necessity to get around the signal loss we experience due to the old building we are in. Our walls are all about 1 foot of concrete. And we have many columns that are about 2foot wide squares of concrete. So to overcome all the signal loss to certain areas we have APs stacked relatively close in some areas.
Our Common area is almost the entire first floor of our building. Our reception, visitors, and cafeteria are all located in this area. So it is generally a high use area. This is where we were seeing a lot of issues with Client Match.
My understanding is that some clients were trying to stick to APs that are on the other end of the room while they were closer to other APs. There are certain areas that the signal can pass through perfectly because there is no direct impedence by walls or columns.
I'm guessing we saw some of our issues due to clients sticking to APs that Aruba was trying to shift to a better AP.
However, I also had to enable ARP to unicast. We were saying a lot of traffic in the air, so most likely causing congestion and dropping packets.
Then to top it off, users running Windows 8.1 on Lenovo laptops were not getting the most up-to-date driver for wireless. Lenovo has a testing period on all the drivers they approve. However, when there are issues with drivers this sucks because you have to wait for Lenovo to approve the driver for it to show up on their website or their update application. Downloading the driver for the Wireless card directly from intel was the solution that worked for multiple 8.1 users.
Also, I didn't know that anyone would really be interested but we already had our min TX power set to 3, assuming that our APs would be able to negotiate what power would be best and only use the highest power needed. However, there was clearly some overlap. So making the change also ensures that each AP is at a higher power from the start. Even at their Min they will have a certain area of coverage.
I will be personally tweaking TX power settings to ensure we don't have "TOO" much overlap. In some areas our APs are as close as 30-40 feet apart. (with a concrete column or wall between). AP density was the only way to really overcome the dead spots we were seeing.
Thankfully Airwave allows me to setup a heatmap so that I don't have to walk around with my laptop and HeatMapper. (Though I will for problematic areas. )
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.