Michael, Are you using AAA Fastconnect allowing your controller to handle radius requests instead of using a backend server? While we haven't done this ourselves, I know of others that have run into the same issue of not being able to keep up with the auth requests. You'll notice this even more as smartphones will re-auth all the time. - Don
On Fri, Jan 31, 2014 at 4:26 PM, Michael Hulko <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]>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:[email protected]] *On Behalf Of *Jeffrey >> Sessler >> *Sent:* Friday, January 31, 2014 1:40 PM >> >> *To:* [email protected] >> *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 <[email protected]> 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 <[email protected]> >> 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/.<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: [email protected] <mailto:[email protected] <[email protected]>> > > > > > > ********** 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/.
