Shumon,
We used to have the same problem when we had the Aironet solution a
couple of years back. It was actually due to the APs sending a
re-association packet/frame to the device, even if that device was
directly underneath the AP. What type of platform are you currently
running your infrastructure on? How dense is your environment? Do you
have dynamic channel/power assignment or are you doing it statically?
Then we had a similar problem, when we deployed to the Airespace
solution, which was due to 2 bugs; one on the controller and another on
the router. Those are things you might want to look at a little bit.
Although the authentication mechanism is what is being impacted, it does
not seem to be the source of your problem, for the simple fact that
people are authenticating. Have you sniffed the air? You could try
running some tests by leaving a device connected and monitoring it and
what type of traffic it is receiving. Look to see what is happening
with the device when it is disconnecting. Check to see if it is
happening at random intervals, or the intervals are more periodic.
Whatever you do, do not ignore it because there are no complaints. I am
sure that are many of us here in the group whom in ignoring small
problems have gotten burnt.
Let us know how it works out.
Thanks.
Jorge
Shumon Huque wrote:
We rolled out a WPA/802.1x authenticated WLAN to our student
residences this semester. We're using EAP-TTLS with PAP as
the inner authentication protocol. The EAP servers are a set
of centralized RADIUS servers that perform Kerberos5 password
verification to our KDCs in the backend.
We've noticed several problems that we didn't observe when
we had it running on a much smaller scale in our own offices.
A large number of users seem to be repeatedly authenticating,
some of them as frequently as every 30 seconds or every few
minutes. Some debugging revealed that these users are frequently
oscillating their associations between a number of different
access points. A smaller number of users keep reassociating with
the same access point. This is causing a very large load on the
authentication server infrastructure, which we've temporarily
worked around by load balancing the APs across additional
RADIUS servers.
However, we're also assuming that this is causing lots of user
visible performance problems due to roaming latency (scan,
reassociate, authenticate, 802.11i handshake, DHCP address
acquisition etc). Surprisingly, not many users have complained.
Perhaps they are only browsing the web or using other non-
interactive apps which can tolerate delay. Or they might
simultaneously have a wired ethernet connection.
Is frequent reassociation the normal behavior in a dense
deployment of APs? I can understand that it might be for
highly mobile stations like wireless VoIP phones. But our
environment is composed of mostly stationary wireless laptops
in student rooms. My assumption was that roaming typically
happened when a user moves towards a stronger signal AP and
at some configured signal quality threshold, the station started
scanning for a better AP. Am I wrong?
Or is this more likely something in our radio environment or
insufficient coverage etc? Our wireless LAN engineers are
currently investigating this, but I'd be interested to hear
the experience of others.
Do we need a fast roaming solution to deal with this? Having
access points and stations able to cache the PMK (Pairwise
Master Key) would probably help the best, as that would allow
them to often establish a secure association without conducting
a heavyweight authentication dialog with the RADIUS server. But
I'm not sure if access points or typical endstations support this.
TLS session resumption will probably help a bit also (if supported).
We use cisco aironet 1200/1100 access points. The clients are
mostly PCs running SecureW2, Macs running with the built-in
EAP-TTLS/802.1x support in Mac OS X, and a smaller number of
Linux machines.
Thanks for any advice!
---
Shumon Huque 3401 Walnut Street, Suite 221A,
Network Engineering Philadelphia, PA 19104-6228, USA.
Information Systems & Computing (215)898-2477, (215)898-9348 (Fax)
University of Pennsylvania / MAGPI. E-mail: shuque -at- isc.upenn.edu
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.
--------------------
This electronic message is intended to be for the use only of the named
recipient, and may contain information that is confidential or privileged. If
you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution or use of the contents of this message is
strictly prohibited. If you have received this message in error or are not the
named recipient, please notify us immediately by contacting the sender at the
electronic mail address noted above, and delete and destroy all copies of this
message. Thank you.
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.
