On Jul 10, 2009, at 4:05 AM, Ivan Kalik wrote:
I'm trying to setup a robust RADIUS authentication proxy. All this
radius will do is proxy all auth requests to a set of four backend
RADIUS handlers. I have a 2.1.6 server that I've configured with
four
home_server entries and one home_server_pool that load-balances
across
the four. It works when all four backends are up, but if any 1 of
the
backend goes down, then requests that get directed to that backend
result in an Access-Reject packet being returned to the NAS. Is
there
a way to configure freeradius so that instead of returning an Access-
Reject packet, the server will instead switch to the next configured
server and retry the request there? It may mean that it takes a
little longer for the request to be handled, but that's better than
it
being rejected.
No, but you can enable do_not_respond policy (see policy.conf). Server
then won't respond to the NAS. That should result in repeated request
which should (chances are) end up with different home server. This
would
be in effect during zombie period. Once the home server is marked
dead no
requests will go to it.
Yeah,that's what I'm doing. The problem is that the retries are not
being sent to a different home server (or any home server). They are
being dropped as retransmits because internally, freeradius is
tracking that no reply was sent to them earlier. I have tried
treaking cleanup_delay to 0 or 1 to flush these out sooner, but it
does not work -- they do not appear to be tracked the same way as
normal responses. Here are the debug messages from radiusd -X:
rad_recv: Access-Request packet from host 127.0.0.1 port 47163,
id=155, length=59
Ignoring retransmit from client SERVERS port 47163 - ID: 155, no reply
was configured
Is there any way to prevent an ignored response from being tracked
this way so that retransmits will be treated as new requests? Or am I
just not sending enough retransmits?
Philip
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
