We use Radiator backend servers bound to each controller independently with failover to another Radius server. At first we thought it was our radius servers having performance issues, but after checking response times and packet captures, we found the controller to be the lynch-pin.
M On 2014-02-03, at 12:56 PM, Wright, Don wrote: > 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 <mihu...@uwo.ca> 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 <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/. > > > ********** 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/.
