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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
