Mike Diggins wrote: > Accounting feature on the WLAN controllers (for now), I noticed that a > similar failure is a happening on the Authentication side. Some > authentication requests proxied to other radius servers (via Eduroam) > are either failing or taking a long time to respond, which also causes > my FreeRadius to mark the Home Server as DOWN. That also seems to cause > a chain reaction of backed up requests, causing my WLAN controllers to > failover the radius server.
There's really very little you can do about that in RADIUS. FreeRADIUS figures out that a home server is down because it stops responding to requests. So if it stops responding... it looks like it's dead. > So, similar to my Accounting problem, is there anyway to prevent a > single Authentication failure from backing up the works!? Does FR answer > queries in sequence only? I don't really understand why this sort of > failure has such a nasty consequence. What, exactly, is the server supposed to do when the next hop isn't responding to packets? Is the next hop up? Is it down? How can you tell? It's this kind of thing that makes me think keep-alives should become standard for eduroam. The extra few packets every couple of seconds are a small cost to pay for ensuring that authentication works. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
