One other wrench in this at least from the Aruba standpoint.... check the cpu load on the Auth process.... we found back in late October that one of our heaviest used controller (M3 running 6.1.3.7) was pegging over 90% utilization for the Auth process which at the time we believed the authentication was being additionally impacted (mostly drops). It was indicated (source does not want to be mentioned) that there was a hard limit to the number of auth's per second the controller could handle (approx. 40 - 50/sec), at peak we were running around ~100/sec. We upgraded to the version 6.3.x to resolve other issues. We noticed that the system now spawned 3 Auth processes, but we still getting complaints. We then discovered through TAC and internal investigation that a new dot1x throttling mechanism had been introduced in the version of code. This new "Throttling" was still impacting our authentications but saving the cpu's on the auth process. We were instructed to adjust the Watermarks to reach a balance point from the defaults. This is a slidiing scale.... the higher the Watermarks, the higher the cpu process, but the less drops experienced.
to view the cpu process: "Show cpuload current | include auth" On 6.3x code: to view the Throttle parameters: "show dot1x counters" (There is some math involved when the system decides to drop packets) to view the dropped auths: "show ap debug client-mgmt-counters" and look for the "Associations Dropped Due to Auth Throttling" In the end, the old addage still holds true..."You can never please 100% of the people 100% of the time....Keep calm and carry on" M On 2014-01-31, at 2:11 PM, Jeffrey Sessler wrote: > We noticed that the WLAN with band/load-steering enabled had a high report > rate of Macintosh connectivity issues, and the WLAN that did not was trouble > free. > > I suspect what was happening was this: Mac would initially associate > (Ent-WPA2), then the controller would force it to move to another band and/or > AP. It's at this point (a roam) that the Apple certificate issue would kick > in, and it was hit or miss as to the Mac re-associating or failing. This was > especially problematic when a Mac client was equidistant from two AP's. > > Turning off band/load steering pretty much eliminated the bulk of the > connectivity issues, and trusting the certificate solved the rest. > > Band/load steering is just problematic because you can never predict how a > client will react to it. > > Jeff > > >>> On Friday, January 31, 2014 at 10:57 AM, in message > >>> <CAPCnwUdh-=jawm78pjfuu1n9bhs9d_japthbfnwrrgsrbzg...@mail.gmail.com>, > >>> Norman Elton <normel...@gmail.com> wrote: > Interesting. What were the band-steering symptoms? Any way to pin the problem > down to band-steering, or was it trial and error? > > Norman > > > On Fri, Jan 31, 2014 at 1:44 PM, Edward Ip <i...@algonquincollege.com> wrote: > I agree with Jeff, we recently disabled band steering on our Aruba > controllers and it has helped a bit. > > Edward Ip > Algonquin College | 1385 Woodroffe Avenue | Room C316 | Ottawa | Ontario | > K2G 1V8 | Canada > algonquincollege.com > > From: The EDUCAUSE Wireless Issues Constituent Group Listserv > [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey Sessler > Sent: Friday, January 31, 2014 1:40 PM > > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] OS X 802.1x auth issue > > > We've seen the cert issue, and OS 10.8 and 10.9 don't seem to like > band/load-steering. The cert issue coupled with band-steering and/or > load-steering make the Mac's very unhappy. > Jeff > > >>> On Friday, January 31, 2014 at 10:05 AM, in message > >>> <CAPCnwUdAuZqKuFwOycKrGmXgiKCrb_Wy82=o5xc3be+o7an...@mail.gmail.com>, > >>> Norman Elton <normel...@gmail.com> wrote: > And a follow up. Has anyone actually confirmed that this bug is > actually causing client complaints? We do seem to riding a wave of > complaints from MacBook owners. We are only just now starting to > change cert trust settings. Hopefully we'll know more next week as > students have a chance to test things out over the weekend. > > Norman Elton > College of William & Mary > > On Fri, Jan 31, 2014 at 12:59 PM, Norman Elton <normel...@gmail.com> wrote: > >> It also appears specific to certs based on 2048 bit keys. Also there is no > >> cert validation delay upon initial connect... only when attempting to > >> reauth... ie after a death or a roam event. > > > > Can anyone confirm the bug only affects certs with 2048 bit keys? I > > don't see that listed anywhere in Apple's release. It's an interesting > > twist. > > > > Thanks! > > > > Norman Elton > > College of William & Mary > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > Michael Hulko Network Analyst Western University Canada Network Operations Centre Information Technology Services 1393 Western Road, SSB 3300CC London, Ontario N6G 1G9 tel: 519-661-2111 x81390 e-mail: mihu...@uwo.ca <mailto:mihu...@uwo.ca> ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
