timeout and period values are rounded
Hello, I'm trying to play with timeouts and periods in my proxy setup. Changing values: zombie_period, response_window in debug log getting warnings: WARNING: Ignoring "response_window = 60.000000", forcing to "response_window = 30.000000" WARNING: Ignoring "zombie_period = 10", forcing to "zombie_period = 30" experimented a bit and found that if I set response_window = 70, it will be rounded to 60 i.e WARNING: Ignoring "response_window = 70.000000", forcing to "response_window = 60.000000" if I set zombie_period = 0, it will be rounded to 1: WARNING: Ignoring "zombie_period = 0", forcing to "zombie_period = 1" but didn't find any way to get any other values, like zombie_period = 15 or response_window = 50. they're always rounded to some other value, and I was not able to find in docs how/why it's rounded. freeradius 3.0.12 Also I have wider/general question: Are there any "best practices" for high latency links with proxy setup. When NAS'es are far from home server. Actually adjusting timeouts and periods I'm trying to fight continuous zombie/alive issue: Sun Jul 9 08:55:51 2017 : ERROR: (503) ERROR: Failing proxied request for user "user1", due to lack of any response from home server 46.111.128.2 port 1813 Sun Jul 9 08:57:17 2017 : Proxy: (515) Marking home server 46.111.128.2 port 1813 alive -- Denis
On 9 Jul 2017, at 06:04, denis <den.zinevich@gmail.com> wrote:
Hello,
I'm trying to play with timeouts and periods in my proxy setup. Changing values: zombie_period, response_window in debug log getting warnings: WARNING: Ignoring "response_window = 60.000000", forcing to "response_window = 30.000000" WARNING: Ignoring "zombie_period = 10", forcing to "zombie_period = 30"
experimented a bit and found that if I set response_window = 70, it will be rounded to 60 i.e WARNING: Ignoring "response_window = 70.000000", forcing to "response_window = 60.000000"
if I set zombie_period = 0, it will be rounded to 1: WARNING: Ignoring "zombie_period = 0", forcing to "zombie_period = 1"
but didn't find any way to get any other values, like zombie_period = 15 or response_window = 50. they're always rounded to some other value, and I was not able to find in docs how/why it's rounded. freeradius 3.0.12
It’s not being rounded. The values provided by the users are bounds checked, and the value is changed to the upper or lower bound if it’s outside of the acceptable range.
Also I have wider/general question: Are there any "best practices" for high latency links with proxy setup. When NAS'es are far from home server. Actually adjusting timeouts and periods I'm trying to fight continuous zombie/alive issue: Sun Jul 9 08:55:51 2017 : ERROR: (503) ERROR: Failing proxied request for user "user1", due to lack of any response from home server 46.111.128.2 port 1813 Sun Jul 9 08:57:17 2017 : Proxy: (515) Marking home server 46.111.128.2 port 1813 alive
If the response comes later than 30 seconds, it’s not network latency, it’s a broken home server. Fix the issue with the home server. -Arran
I thought about bounds, but experiment showed that value is valid. As I wrote in first mail: WARNING: Ignoring "response_window = 60.000000", forcing to "response_window = 30.000000" (response_window=60 in config) WARNING: Ignoring "response_window = 70.000000", forcing to "response_window = 60.000000" (response_window=70 in config) so 60 seems to be valid value, it's just not set with response_window=60 values response_window=25 or response_window=35 do not work as well -- Denis On 9 July 2017 at 15:00, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 9 Jul 2017, at 06:04, denis <den.zinevich@gmail.com> wrote:
Hello,
I'm trying to play with timeouts and periods in my proxy setup. Changing values: zombie_period, response_window in debug log getting warnings: WARNING: Ignoring "response_window = 60.000000", forcing to "response_window = 30.000000" WARNING: Ignoring "zombie_period = 10", forcing to "zombie_period = 30"
experimented a bit and found that if I set response_window = 70, it will be rounded to 60 i.e WARNING: Ignoring "response_window = 70.000000", forcing to "response_window = 60.000000"
if I set zombie_period = 0, it will be rounded to 1: WARNING: Ignoring "zombie_period = 0", forcing to "zombie_period = 1"
but didn't find any way to get any other values, like zombie_period = 15 or response_window = 50. they're always rounded to some other value, and I was not able to find in docs how/why it's rounded. freeradius 3.0.12
It’s not being rounded. The values provided by the users are bounds checked, and the value is changed to the upper or lower bound if it’s outside of the acceptable range.
Also I have wider/general question: Are there any "best practices" for high latency links with proxy setup. When NAS'es are far from home server. Actually adjusting timeouts and periods I'm trying to fight continuous zombie/alive issue: Sun Jul 9 08:55:51 2017 : ERROR: (503) ERROR: Failing proxied request for user "user1", due to lack of any response from home server 46.111.128.2 port 1813 Sun Jul 9 08:57:17 2017 : Proxy: (515) Marking home server 46.111.128.2 port 1813 alive
If the response comes later than 30 seconds, it’s not network latency, it’s a broken home server. Fix the issue with the home server.
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Jul 9, 2017, at 2:07 PM, denis <den.zinevich@gmail.com> wrote:
I thought about bounds, but experiment showed that value is valid. As I wrote in first mail: WARNING: Ignoring "response_window = 60.000000", forcing to "response_window = 30.000000" (response_window=60 in config) WARNING: Ignoring "response_window = 70.000000", forcing to "response_window = 60.000000" (response_window=70 in config)
so 60 seems to be valid value, it's just not set with response_window=60 values response_window=25 or response_window=35 do not work as well
The response_window has to be lower than 60. It also has to be lower than max_request_time. And, you ignored Arran's other comments. Stop arguing about irrelevant details. Go fix the home server so that it doesn't take 30 seconds to respond. No amount of poking the FreeRADIUS proxy will make the home server magically respond more quickly. There is no possible value of "response_window" which will fix the problem. Go fix the home server. Stop arguing, and stop trying to create work-arounds. Go fix the problem. Alan DeKok.
"It also has to be lower than max_request_time" - I did not see that in docs.. may be missed. If I said nothing about home server does not mean I'm not investigating it's behaviour to get it fixed. Besides home server issue those warning still looks questionable, so even if it's not related I'd like at least to understand what's happening with timeouts. i.e for some reason even with max_request_time=30, setting response_window=70 makes it 60, and 55 makes it 30. zombie_period - setting 29 is fine, no warning. setting 20 - makes it 25. so looks like in both cases there are some rules/additional dependencies that are not in docs. regards home server itself - reason I asked for undefined/non-specific question about "best practices" is because yet I can't identify any specific problem on home server. if proxy did not receive any response from home server means either home did not get request, or response was not received at all or came out of time range. home server stats looks good for me: # echo "Message-Authenticator = 0x00, FreeRADIUS-Statistics-Type = 2, Response-Packet-Type = Access-Accept" | radclient -x localhost:18121 status adminsecret Sent Status-Server Id 9 from 0.0.0.0:54995 to 127.0.0.1:18121 length 50 Message-Authenticator = 0x00 FreeRADIUS-Statistics-Type = Accounting Response-Packet-Type = Access-Accept Received Access-Accept Id 9 from 127.0.0.1:18121 to 0.0.0.0:0 length 104 FreeRADIUS-Total-Accounting-Requests = 99554 FreeRADIUS-Total-Accounting-Responses = 99507 FreeRADIUS-Total-Acct-Duplicate-Requests = 0 FreeRADIUS-Total-Acct-Malformed-Requests = 0 FreeRADIUS-Total-Acct-Invalid-Requests = 0 FreeRADIUS-Total-Acct-Dropped-Requests = 0 FreeRADIUS-Total-Acct-Unknown-Types = 0 i.e in case of problems I guess Total-Acct-Dropped-Requests will increase, right ? so if you have any hints how to diagnose issue on home server - tel me please. for now I have only suggestion try to switch to tcp instead of udp. -- Denis On 9 July 2017 at 21:29, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 9, 2017, at 2:07 PM, denis <den.zinevich@gmail.com> wrote:
I thought about bounds, but experiment showed that value is valid. As I wrote in first mail: WARNING: Ignoring "response_window = 60.000000", forcing to "response_window = 30.000000" (response_window=60 in config) WARNING: Ignoring "response_window = 70.000000", forcing to "response_window = 60.000000" (response_window=70 in config)
so 60 seems to be valid value, it's just not set with response_window=60 values response_window=25 or response_window=35 do not work as well
The response_window has to be lower than 60. It also has to be lower than max_request_time.
And, you ignored Arran's other comments.
Stop arguing about irrelevant details. Go fix the home server so that it doesn't take 30 seconds to respond.
No amount of poking the FreeRADIUS proxy will make the home server magically respond more quickly.
There is no possible value of "response_window" which will fix the problem.
Go fix the home server. Stop arguing, and stop trying to create work-arounds. Go fix the problem.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Jul 9, 2017, at 5:31 PM, denis <den.zinevich@gmail.com> wrote:
"It also has to be lower than max_request_time" - I did not see that in docs.. may be missed.
The documentation says that "max_request_time" is the maximum time for a request. After that time, the server gives up on the request. Please explain how it makes sense to set "response_window" larger than that makes sense.
If I said nothing about home server does not mean I'm not investigating it's behaviour to get it fixed.
I can only go by what you post. If you ignore comments about fixing the home server, I can only assume you're ignoring the idea to fix the home server.
Besides home server issue those warning still looks questionable, so even if it's not related I'd like at least to understand what's happening with timeouts.
Please explain how the warning is "questionable". If the home server doesn't respond for 30 seconds, it's broken, down, or it never received the request.
i.e for some reason even with max_request_time=30, setting response_window=70 makes it 60, and 55 makes it 30. zombie_period - setting 29 is fine, no warning. setting 20 - makes it 25. so looks like in both cases there are some rules/additional dependencies that are not in docs.
Maybe it's a bug. Or maybe you're reading the debug output incorrectly. Since you're not posting the whole debug output...
regards home server itself - reason I asked for undefined/non-specific question about "best practices" is because yet I can't identify any specific problem on home server.
It takes 30s to respond. That's bad. You've been told this repeatedly. How can you conclude "there's no specific problem on the home server?"
if proxy did not receive any response from home server means either home did not get request, or response was not received at all or came out of time range.
Again, if the home server takes 30s to respond, it's broken. If the home server responds after the proxy has given up on the request, the proxy will print a message saying that.
home server stats looks good for me:
i.e. You're not following a packet from the proxy to the home server and back again. You're looking at something *else*.
i.e in case of problems I guess Total-Acct-Dropped-Requests will increase, right ?
No.
so if you have any hints how to diagnose issue on home server - tel me please.
Run the server in debugging mode as suggested in the FAQ, "man" page, web pages, and daily on this list. Run BOTH servers in debugging mode. Send the proxy a packet. See if the packet makes it to the home server. This shouldn't be difficult.
for now I have only suggestion try to switch to tcp instead of udp.
TCP won't fix routing or firewall problems. Making random changes won't help you understand the problem, or to fix it. You have to figure out what's going wrong, and then fix that. Alan DeKok.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
denis