Hi! I have a question regarding proxy failover in FreeRadius 1.x. Proxy code chooses first active home server for realm and send packet to that one. If no reply is received after configured number of retries, request is rejected, other servers are *not* tried. Does version 2.0 have the same behavior? According to comments in sample proxy.conf it seems new version will also try only one server and reject request if no reply is received. I have made a quick modification of request_list.c, so that request_reject is not called when try_count drops to 0. After that, when NAS retries, different home server is selected. Can not calling request_reject have any negative impact (memory leak, internal structures inconsistency, ...)? Wouldn't it make sense to make configuration parameter, which will instruct radiusd whether it should reject or silently drop request, for which it has not received reply from home server? For realms with single home server, it won't make much difference, as request will be rejected on next NAS retry (all home servers are marked dead), but for realms with multiple home servers, reject will not be sent just because one of the home servers is not responding. Ideas? th.
Tomas Hoger wrote:
I have a question regarding proxy failover in FreeRadius 1.x. Proxy code chooses first active home server for realm and send packet to that one. If no reply is received after configured number of retries, request is rejected, other servers are *not* tried.
Yes.
Does version 2.0 have the same behavior? According to comments in sample proxy.conf it seems new version will also try only one server and reject request if no reply is received.
That's not what the documentation says. It says that a request will be rejected once it has timed out. If the home server is marked dead while the request is still alive, AND the NAS retransmits, then the request will be sent to another home server.
I have made a quick modification of request_list.c, so that request_reject is not called when try_count drops to 0. After that, when NAS retries, different home server is selected. Can not calling request_reject have any negative impact (memory leak, internal structures inconsistency, ...)?
No.
Wouldn't it make sense to make configuration parameter, which will instruct radiusd whether it should reject or silently drop request, for which it has not received reply from home server?
In 2.0.0, the request is automatically sent to another home server in the same server pool. If there is no response, the post-proxy-type "fail" section is run.
For realms with single home server, it won't make much difference, as request will be rejected on next NAS retry (all home servers are marked dead), but for realms with multiple home servers, reject will not be sent just because one of the home servers is not responding.
Various hacks can be added to 1.1.x, but the problem is deeper than that. The code in 1.1.x isn't easy to debug or modify. The code in 2.x is much clearer, better organized, and supports *much* more functionality than 1.1.x. At this point, new features will not be added to 1.1.x. If you want new features, use 2.0.0 when it comes out. Alan DeKok.
HI Alan! On 5/27/07, Alan Dekok <aland@deployingradius.com> wrote:
That's not what the documentation says. It says that a request will be rejected once it has timed out. If the home server is marked dead while the request is still alive, AND the NAS retransmits, then the request will be sent to another home server.
Ok. Sorry, I was probably misled into believing behavior of 2.0 is similar to behavior of 1.x by following part of sample proxy.conf: # # If the home server doesn't respond to the request within # this time, this server will consider the request dead, and # respond to the NAS with an Access-Reject. # # Useful range of values: 5 to 60 response_window = 20
Various hacks can be added to 1.1.x, but the problem is deeper than that. The code in 1.1.x isn't easy to debug or modify. The code in 2.x is much clearer, better organized, and supports *much* more functionality than 1.1.x.
At this point, new features will not be added to 1.1.x. If you want new features, use 2.0.0 when it comes out.
Yes, I do am aware of the fact that 2.0 has a lot of improvements in proxy code and I do understand that all effort is put into new version. I just need to hack 1.1.x to match my needs until 2.0 is released. You can also ignore my feature proposal, as it was based on wrong assumption that new code has the same "problem" as new one. Many thanks for your reply as it answered my questions! th.
participants (2)
-
Alan Dekok -
Tomas Hoger