FreeRadius with Eduroam - Accounting

[Arran Cudbard-Bell]

On 14 Oct 2011, at 15:33, Mike Diggins wrote:

> 
> On Fri, 14 Oct 2011, Alan DeKok wrote:
> 
>> 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.
> 
> Does FreeRadius work synchronously only, so a slow response from one remote server stops any other pending authentications from completing until that first one is finished?

No. Not in normal multithreaded mode.

> 
>> 
>>> 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?

You start sending it status server packets to check, which is what happens if you have status-server configured. That one of the primary reasons for having status-server in the first place, and the reason you don't proxy status-server packets.

> I'm not sure. If my assumption above is correct, then I don't see a good solution. I'm thinking of a method like Squid proxy server, where a number of authenticators are used, so one that's slow or fails doesn't affect the others.

That's the case here.

> The only suggestion I can think of right now is to send the server-status message to the next hop first before marking it dead. I think that would be a safer assumption when proxying anyway.

Which is what happens already (see diagram in previous post).

-Arran

Arran Cudbard-Bell
a.cudbardb at freeradius.org

Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !