On Mar 6, 2016, at 6:54 PM, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
I'm looking to add more robustness into my proxy architecture and noticed in the home_server_pool there is the option for "fallback = virtualrealm" so if all home servers fail then a last resort home_server is used with some config locally to always accept / reject customers based on the realm they are coming from. I'm not using the status_check
Then you can do "status_check = request". An Access-Accept or Access-Reject response will be accepted as an indication that the home server i alive.
as some of the downstream clients don't support status-server, but I will look into that to see if it makes a difference.
It should.
However for this situation I would expect if you are using or not using Status server checks shouldn't have any impact on how the fallback server works.
It does. A lot. The problem is that without Status-Server, FreeRADIUS has to *guess* when the home server is alive. And the guess is usually wrong. Because most guesses are wrong.
In the proxy.conf I have configured:
home_server ProxyDest { type = auth+acct ipaddr = 192.168.1.113 port = 1812 secret = password response_window = 1 require_message_authenticator = no zombie_period = 5 revive_interval = 10
That's really low. After 10s, just mark the home server alive? It should be 60s at the minimum. Maybe 5min.
But if the server is down the first request I get a reject as expected due to the home server being down.
That's good.
But the second and subsequent request I would expect to get proxied to the local fallback virtual server as the home_server has been marked as zombie. But that never seems to happen. It keeps on rejecting the requests and fallback never seems to be used.
Hmm... I'll take a look.
If I configure a second home server in the pool. ... Then the second server is failed over to when the first fails. Which is all good if I wanted to use the type fail-over, but if I wanted to use load-balance then I can't have my fallback server as a home server otherwise a percentage of requests will always be local which isn't ideal.
Yes. You can't do load-balance and fallback. You *can* put something into Post-Proxy-Type Fail. Which is probably what we should do. And remove the fallback virtual server. This allows the same behaviour for all packets, and simplifies the proxy code.
The other interesting thing with the failover is I set the check_interval to 10 seconds, or 30 seconds. But it only seems that the first client is re-checked after 60 seconds and assumed to be back up.
Because you have revive_interval set.
Waking up in 0.2 seconds. Marking home server 192.168.1.113 port 1812 alive again... we have no idea if it really is alive or not.
And that message is printed only when you have revive_interval set. The solution is to *not* set revive_interval. And use Status-Server exclusively.
Waking up in 1.0 seconds.
I would have thought that
zombie_period = 5 revive_interval = 10 check_interval = 10
Would mean that the client would be re-checked in 10 seconds.
check_interval and revive_interval should be mutually exclusive. It just doesn't make sense to both check that the home server is alive every 10s, and then *always* mark it as alive after 10s.
Am I mis-understanding how fallback is supposed to work?
A bit. But the fallback virtual server should work. Tho I'm inclined to remove it in 3.1, as it makes everything more complicated. Alan DeKok.