On Mar 8, 2016, at 4:54 PM, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
I think that was my issue, as I was using a second VM on the network as the proxy destination I was shutting down the destination server and not waiting for the zombie period to expire.
Yeah. It's documented, but it's not immediately obvious.
That seems to be my issue, I've just re-tested that with 3.0.x head and had the zombie_timeout set too high. After I wound that number down to the same as check_interval and once the server went to zombie then the fallback occurred.
Good.
Granted I won't have the values set this low in production, but since this will be a high volume server with some critical services on it. I suspect I will stick with 30 seconds or 1 min for the check interval but keep the zombie value at 20 seconds.
The check interval can be set lower without any problem. It's only one RADIUS packet.
So if a radius server dies or becomes unresponsive we don't wait around until we mark it zombie before we start authing everyone locally. Then have a reasonable backoff before we attempt to start authing again.
Yes. It's OK to set zombie_period to a low value. In any normal deployment, you'll be proxying many packets a second to a home server. If it doesn't respond to *any* packets for 10 seconds, you're pretty sure it's dead. 1 to 2 seconds is probably too low, as there may be transient network issues which are that long.
Many thanks again.
You're welcome. Alan DeKok.