FreeRADIUS and EDUROAM timeout issues

[Peter Eriksson]

Alan DeKok wrote:
> Peter Eriksson wrote:
>> The default setting seems to be less than optimal since if a remote site
>> have problems with their home RADIUS servers then we risk having our
>> local servers mark the upstream servers as "dead" since it's not
>> receiving answers for a specific 'realm'...
> 
>   That's been a bit of a problem in RADIUS proxying.  The specification
> says that serves MUST answer Access-Requests.  But some implementations
> don't do that when they're proxying.  This causes all sorts of problems.
> 
>> Perhaps increase the 'response_window',
>> and lower 'zombie_period' and 'revive_interval'
>> and 'check_interval' values...
> 
>   If you're using "status-server", then "revive_interval" isn't used.

Hmm.. When I have been testing stuff here it feels like it was that
(review_interval) timeout that was being used before the server first
sent a 'status-server' check after having marked it 'down'. But I might
have been mistaken. Gonna do some more tests...

I wonder how low I can set things to lessen this issue. Perhaps set
zombie_period and check_interval to one second...


>> Best would probably be if FreeRadius kept a
>> separate timeout for each 'server/realm' tuple...
> 
>   Ugh.  That's adding complexity to work around bugs in other RADIUS
> servers, IMHO.  Rather than keeping track of N realms && M home servers,

Well, it doesn't necessarily have to be bugs in RADIUS server. It can be
a multitude of stuff that causes a far away home server to not respond.
Like a network outage. It doesn't feel right to have a system where a
network outage in (for example) Australia can take out all the EDUROAM
service for people at our university, just because we happen to have a
guest from that Australian university that made an attempt to connect
to the EDUROAM system...



> it now has to keep track of (N x M) combinations.  That's expensive.

Yes... But that is what I think the EDUROAM people that use 'Radiator'
does use.

- Peter