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.
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. ...
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. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog