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