Benjamin Marvin wrote:
Any other suggestions on where I should look to see why the servers
are marking the upstream servers as Zombie?
The only log message is that it's marking the server zombie. Until
it's marked zombie, it *might* be alive. The reason it's marked zombie
is because the
Benjamin Marvin wrote:
I don't believe this is my problem. The debug and packet captures
show all of the accounting packets are replied to within the
Response_Window and Max_Request_Time frames. (5-10 seconds being at
the extreme high end of response times.)
If the responses are all within
On Wed, Apr 21, 2010 at 05:47:43PM +0200, Alan DeKok wrote:
Without status_check, you rely on the timeouts - revive_interval and
zombie_period.
Which is much worse than status checks.
But, if you're talking to FR 1.1.7, that should be able to make it respond
negatively to a single
Josip Rodin wrote:
One thing that we talked I believe in private mail is good to point out on
the mailing list as well - the current request cleaning up logic isn't
really being kind to proxy settings and how the admins might interpret them
- meaning there is nothing in the proxying code that
Good day,
I'm trying to figure out why my servers continue to be marked zombie, even
though they continue to handle traffic. There appears to be no impact, just
seemingly erroneous - or at least unexplained - log entries.
I have three 2.1.8 servers that feeds accounting to a 4th server (via
On Tue, Apr 20, 2010 at 10:59:04PM -0800, Benjamin Marvin wrote:
The radius.log file for the primary servers show they are marking the 4th
and Cisco (upstream) servers as zombie quite regularly (but not
simultaneously);
I've set the response_window to as high as 60 seconds in the
Josip Rodin wrote:
On Tue, Apr 20, 2010 at 10:59:04PM -0800, Benjamin Marvin wrote:
I've also turned off the status_check feature as 1.1.7 and Cisco ACS do
not appear to support it.
You can configure a fake username password for status checks.
This *is* documented in raddb/proxy.conf.
Hi,
Yup. It's not that 2.x is bad without status checks, it's that there
is *no way* for anyone to do the right thing without status checks.
agreed - I'm behind status-checks all the way - either native
sattus-check or a user who gets rejected. both work fine for testing
upstream
8 matches
Mail list logo
