Wireless Access

Info:

Controller and AOS: 7220, running 6.3.1.2.

AP: 225's

Client: MacBook Pro (10.9.2 - mid 2012 version).

Other notes: Client match is active on 2.4 and 5 GHz. Windows devices roam without any problems.

We are expericing from hard handoff issues with mac book pros on enterprise network (WPA2 PEAP-MS-CHAPv2). The AP'a are on the same AP group/VLAN and noticing the macbook being very sticky (-80 RSSI as some points) and eventually dropping the connection for about 10-15 before connected to a new AP. Our environment is designed for 5GHz coverage, so there is no reason for the client to ever be at -80 RSSI.

ARM DEBUG USER LOGS:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Apr 22 10:49:51 :507013:  <DBUG> |AP 522B sapd|  Client Match: Detected client 14:10:9f:d2:5d:6d Assoc BSSID 9c:1c:12:88:f0:b0 channel 44 with low RSSI 11 dB

Apr 22 10:49:51 :507007:  <DBUG> |AP 522B sapd|  Client Match: For client 14:10:9f:d2:5d:6d Trigger Sticky No better candidate AP

Apr 22 10:49:54 :507013:  <DBUG> |AP 522B  sapd|  Client Match: Detected client 14:10:9f:d2:5d:6d Assoc BSSID 9c:1c:12:88:f0:b0 channel 44 with low RSSI 9 dB

Apr 22 10:49:54 :507007:  <DBUG> |AP 522B  sapd|  Client Match: For client 14:10:9f:d2:5d:6d Trigger Sticky No better candidate AP

Apr 22 10:49:57 :507013:  <DBUG> |AP 522B  sapd|  Client Match: Detected client 14:10:9f:d2:5d:6d Assoc BSSID 9c:1c:12:88:f0:b0 channel 44 with low RSSI 9 dB

Apr 22 10:49:57 :507007:  <DBUG> |AP 522B sapd|  Client Match: For client 14:10:9f:d2:5d:6d Trigger Sticky No better candidate AP

Apr 22 10:49:59 :501161:  <DBUG> |stm|  Client Match Received probe report: AP 9c:1c:12:88:f7:e0 ESSID CORP Assoc ESSID CORPfor client 14:10:9f:d2:5d:6d with signal 68

Apr 22 10:49:59 :501161:  <DBUG> |stm|  Client Match Received probe report: AP 9c:1c:12:89:06:e0 ESSID CORPAssoc ESSID CORP for client 14:10:9f:d2:5d:6d with signal 75

Apr 22 10:50:00 :501161:  <DBUG> |stm|  Client Match Received probe report: AP 9c:1c:12:88:f7:f0 ESSID CORPAssoc ESSID CORPfor client 14:10:9f:d2:5d:6d with signal 69

Apr 22 10:50:00 :507013:  <DBUG> |AP 522B sapd|  Client Match: Detected client 14:10:9f:d2:5d:6d Assoc BSSID 9c:1c:12:88:f0:b0 channel 44 with low RSSI 9 dB

Apr 22 10:50:00 :507007:  <DBUG> |AP 522B sapd|  Client Match: For client 14:10:9f:d2:5d:6d Trigger Sticky No better candidate AP

Apr 22 10:50:03 :501161:  <DBUG> |stm|  Client Match Received probe report: AP 9c:1c:12:88:f0:a0 ESSID CORPAssoc ESSID CORP for client 14:10:9f:d2:5d:6d with signal 70

Apr 22 10:50:03 :507013:  <DBUG> |AP 522B sapd|  Client Match: Detected client 14:10:9f:d2:5d:6d Assoc BSSID 9c:1c:12:88:f0:b0 channel 44 with low RSSI 9 dB

Apr 22 10:50:03 :507007:  <DBUG> |AP 522B sapd|  Client Match: For client 14:10:9f:d2:5d:6d Trigger Sticky No better candidate AP

Apr 22 10:50:04 :501161:  <DBUG> |stm|  Client Match Received probe report: AP 9c:1c:12:88:f6:c0 ESSID CORP Assoc ESSID CORP for client 14:10:9f:d2:5d:6d with signal 78

Apr 22 10:50:05 :501161:  <DBUG> |stm|  Client Match Received probe report: AP 9c:1c:12:89:08:a0 ESSID CORP Assoc ESSID CORPfor client 14:10:9f:d2:5d:6d with signal 78

Apr 22 10:50:06 :507013:  <DBUG> |APAP 522B sapd|  Client Match: Detected client 14:10:9f:d2:5d:6d Assoc BSSID 9c:1c:12:88:f0:b0 channel 44 with low RSSI 9 dB

Apr 22 10:50:06 :507007:  <DBUG> |AP AP 522B sapd|  Client Match: For client 14:10:9f:d2:5d:6d Trigger Sticky No better candidate AP

Apr 22 10:50:08 :501161:  <DBUG> |stm|  Client Match Received probe report: AP 9c:1c:12:88:f9:b0 ESSID CORPAssoc ESSID CORP for client 14:10:9f:d2:5d:6d with signal 71

Apr 22 10:50:08 :501161:  <DBUG> |stm|  Client Match Received probe report: AP 9c:1c:12:89:09:c0 ESSID CORP Assoc ESSID CORP for client 14:10:9f:d2:5d:6d with signal 67

Apr 22 10:50:09 :507013:  <DBUG> |AP AP 522B sapd|  Client Match: Detected client 14:10:9f:d2:5d:6d Assoc BSSID 9c:1c:12:88:f0:b0 channel 44 with low RSSI 9 dB

Apr 22 10:50:09 :507007:  <DBUG> |AP AP 522Bapd|  Client Match: For client 14:10:9f:d2:5d:6d Trigger Sticky No better candidate AP

Apr 22 10:50:10 :501161:  <DBUG> |stm|  Client Match Received probe report: AP 9c:1c:12:89:06:f0 ESSID CORP Assoc ESSID CORP for client 14:10:9f:d2:5d:6d with signal 81

Apr 22 10:50:12 :507013:  <DBUG> |AP AP 522B sapd|  Client Match: Detected client 14:10:9f:d2:5d:6d Assoc BSSID 9c:1c:12:88:f0:b0 channel 44 with low RSSI 9 dB

Apr 22 10:50:12 :507007:  <DBUG> |AP AP 522B sapd|  Client Match: For client 14:10:9f:d2:5d:6d Trigger Sticky No better candidate AP

Apr 22 10:50:13 :501161:  <DBUG> |stm|  Client Match Received probe report: AP 9c:1c:12:89:09:50 ESSID CORP Assoc ESSID CORP for client 14:10:9f:d2:5d:6d with signal 79

Apr 22 10:50:15 :507013:  <DBUG> |AP AP 522B sapd|  Client Match: Detected client 14:10:9f:d2:5d:6d Assoc BSSID 9c:1c:12:88:f0:b0 channel 44 with low RSSI 9 dB

Apr 22 10:50:15 :507007:  <DBUG> |AP AP 522B sapd|  Client Match: For client 14:10:9f:d2:5d:6d Trigger Sticky No better candidate AP

Apr 22 10:50:17 :501161:  <DBUG> |stm|  Client Match Received probe report: AP 9c:1c:12:89:09:d0 ESSID CORP Assoc ESSID CORP for client 14:10:9f:d2:5d:6d with signal 63

Apr 22 10:50:17 :507018:  <DBUG> |AP AP 431B Bsapd|  Client Match: New assoc 14:10:9f:d2:5d:6d Assoc time 1750479

Apr 22 10:50:17 :501161:  <DBUG> |stm|  Client Match Received probe report: AP 9c:1c:12:88:f6:d0 ESSID CORP Assoc ESSID CORP for client 14:10:9f:d2:5d:6d with signal 73

Apr 22 10:50:18 :501161:  <DBUG> |stm|  Client Match Received probe report: AP 18:64:72:e4:86:30 ESSID CORP Assoc ESSID CORP for client 14:10:9f:d2:5d:6d with signal 87

Apr 22 10:50:18 :507013:  <DBUG> |AP AP 522B sapd|  Client Match: Detected client 14:10:9f:d2:5d:6d Assoc BSSID 9c:1c:12:88:f0:b0 channel 44 with low 

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Text highlighed in bold is when the client finally made the connection to the new AP.

dAS,

Please type "show ap active" and take a look at the power on your access points on the 5ghz.  If they are more than 18, we need to configure the ARM Min TX to 12 and the ARM Max TX to 18.  If the power is more than that, clients will attempt to hold onto APs longer than they should, even with ClientMatch enabled.  If they are not more than 18, we might need to find out more about your environment.

I just ran the command and it looks like I do have a large # of AP's at max power on 5 GHz.

My concern of maxing out the power at 18 dBw is that other clients (windows) will suffer from connecting to 5GHz.

Thanks for the info

You should also try using 20mhz channels so that you have more channel reuse on the 5ghz band.  You do that by changing the "Allowed 40 mhz bands" to "None" in your ARM profile.  If a client sees an access point at a high power and it associates with a 40mhz channel, it will hold on longer and possibly create a roaming issue.  Change ARM to min 12 and Max 18 and disable 40mhz channels and see if things improve.

Thanks again for the info.

I'm hoping that changing channel it back to 20 MHz doesn't resolve the issue because a large number of our clients use 40 mHz (image attached) and a lot  of users correlate data rates to their wireless performace. I will plan on making the adjustment to the power levels before adjusting the channel widths and let you know what happens. 

A couple of more things, we have a AirMagnet sensor in the area and 5 GHz channel utilzation/interferance doesn't seem to be a problem. I also upgraded to the lastest version of Mac OS (10.9.3) and it didn't make a difference. 

dAs,

With bonded channels, you only have 4 non-overlapping channels.  That means if you have a dense deployment you are only slightly less likely to have overlapping channels than the 2.4ghz network (3 non-overlapping channels).  In addition, devices that do NOT use 40 mhz channels like most phones will not utilize the second channel, but another 40mhz-capable device will not be able to use the channel that the 20mhz device is not utilizing, either.  Using 20mhz channels gives you less contention and every device that is 5ghz capable can use all of the spectrum presented, making things more efficient in a dense environment.  Your macs will hold onto a 40mhz channel longer, which will contribute to your roaming issue if your power is over 18.

People pay attention to performance first.  Geeks look at the associated rate.  Statistically lower contention means better performance.  It is good that your sensor does not say that there is high utilization.  That is separate from your roaming issue, which could be created by asymetric power between your clients and your access points.

cjoseph, 

I understand the point you are trying to make but if you noticed in the attachment over 50% of are clients are using 40Mhz channels. I would have looked into making the change from 40 to 20 Mhz if performance was the problem. 90% of our clients are having not having issues with roaming or performance except the MacBook pro's. 

We are still implementing Aruba across our campus and I would hate to not give clients the full wireless potential Aruba offers. We are also in the process of rolling out some AC/3 spatial stream devices that are reaching 450 mbps data rates. We have a large application development group who watches assciation rates across multiple devices and runs performance test to local/remote servers.

dAs,

I only have suggestions based on the information that you have supplied.  Maybe you should consult someone who can get ALL of the details of your deployment so that you can make an informed decision.

cjoseph,

I really apperciate the help and will open a TAC case.

I will update the ticket on the findings for others to reference.

Thanks again,

dAs

Hi dAs!

I´m working in an environment with some OS X machines that suffer abit when roaming compared to the windows laptops. My first observation is that a macbook go through a full reauthentication each time it roams, I find information about them not supporting OKC but not sure if that´s changed in the later versions.

A followup issue on that is that they´re having problems validating the certificate of the RADIUS server. See this article for suggested resolution:

http://support.apple.com/kb/TS5258

If you got any more tips from your TAC case, please post for us :)

Any further updates on this? I am having similar problems with macbooks in our enviroment.