On Mon, Apr 30, 2007 at 05:41:06PM +0200, Alan DeKok wrote:
> Kostas Zorbadelos wrote:

> > I had described a strange behavior in our large proxy setup. After
> > running the server in debug mode (radiusd -xxx) in our production
> > systems we found out what was causing our problems. The problem was
> > that the home server in our proxy setup was marked dead quite often
> > during the day and with a dead_time of 30 secs every request that came
> > within these 30 secs was rejected.
>   Yes.  In 1.x, the proxy code does this.  It's fixed in 2.0, which
> should be released real soon now.
> > +                       /*
> > +                        * If we are running in synchronous proxy mode, 
> > there's no point marking the target
> > +                        * server(s) dead, since this should be done by the 
> > radius client
>   Uh, no.  The RADIUS client doesn't know about the home servers.  It
> only knows about the server it's sending packets to.

Precicely. But when we work in 'synchronous' mode we want the NAS to
be in charge of the retransmision policy not our proxy server. If the
home server does not reply for any reason, we want the client (NAS) to
notice it and retransmit. Eventually, the client will mark our proxy
server dead not because it is its fault, but because the home server
is not responding.  

> > The purpose of this patch is to not have the freeradius server mark
> > the home server dead when working in synchronous mode. We believe that
> > in synchronous operation it is a good idea to leave the job of marking
> > the server dead to the NAS client.
>   Which server?  All your patch does is make sure that the NAS marks the
> proxying server as dead.

Eventually, yes this is what the NAS will do. All that is due to the
synchronous mode in proxy operation.

> ...
> > It seems that in some "strange" occations the code enters the above
> > path. A decision is made in case the current time is older than
> > mainconfig.proxy_retry_delay * mainconfig.proxy_retry_count. If this
> > is the case, the request is rejected and the code tries to disable the
> > realm. However in the proxy.conf configuration file it is mentioned:
>   All of that code is *gone* in 2.0.  The new code is so much better
> that it's really quite hard to describe how much better it is.
> > Please let me know your thoughts on these matters (also on the patch
> > we provide)
>   Take a look at the current CVS snapshot.  It should be pretty robust
> with some recent bug fixes, and it will solve *all* of your proxying
> problems.
>   And I do mean ALL of the problems.

I have read in the list about the major clean up version 2.0 of the
server will be. While reading the code of versions 1.x I could see
that there is great room for improvement. I will take a look in the
2.0 sources and I look forward to testing it when it becomes

Thanks a lot Alan.


>   Alan DeKok.
> --
>   http://deployingradius.com       - The web site of the book
>   http://deployingradius.com/blog/ - The blog
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to