Hopefully an easy one to answer by the experts..... I've read some old posts, but just want to confirm. 1. When proxying requests FreeRadius will not perform any retries? But will forward retries received from clients? 2. The only retries are when status-checks are being done? Many thanks. Adrian Smith.
On 6 Feb 2014, at 13:39, adrian.p.smith@bt.com wrote:
Hopefully an easy one to answer by the experts…..
I’ve read some old posts, but just want to confirm.
1. When proxying requests FreeRadius will not perform any retries? But will forward retries received from clients?
It won't perform retries, it won't always forward retries depending on it's own timeouts. There is code to implement retransmission independent of the NAS, but it's not public.
2. The only retries are when status-checks are being done?
Yes. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi,
1. When proxying requests FreeRadius will not perform any retries? But will forward retries received from clients?
correct, its just a proxy.
2. The only retries are when status-checks are being done?
no. it will send status-server checks just to check if the remote proxy/server is alive...and put it back into alive queue (rather than zombie or dead)....so the next retry will go to a server known to be working) alan
On 6 Feb 2014, at 14:44, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
1. When proxying requests FreeRadius will not perform any retries? But will forward retries received from clients?
correct, its just a proxy.
Hm, ok I was wrong, it does always forward retries, it's only when the request is waiting to be processed or being processed by a worker that it ignores the retransmissions. Doesn't seem that's entirely sensible, or consistent, but ok...
2. The only retries are when status-checks are being done?
no. it will send status-server checks just to check if the remote proxy/server is alive...and put it back into alive queue (rather than zombie or dead)....so the next retry will go to a server known to be working)
But the status checks themselves will be retried. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Arran Cudbard-Bell wrote:
Hm, ok I was wrong, it does always forward retries, it's only when the request is waiting to be processed or being processed by a worker that it ignores the retransmissions.
Yes. That was the subject of some debate in the IETF RADIUS working group. The proxy acts as a "pass through" device for retransmits. But if the server is still working on the reqeust, the answer is *unknown*. So it can't proxy it, it can't respond, and it can't do anything other than ignore the retransmit.
Doesn't seem that's entirely sensible, or consistent, but ok...
It's really the only choice. The server could do re-transmits itself. It did that in version 1. But the code was complicated and fragile. And the other people in the RADIUS WG though doing that would break things in the network.
But the status checks themselves will be retried.
Because FreeRADIUS originated the packet, and is acting like a client. Clients do retransmits... Alan DeKok.
On 6 Feb 2014, at 18:55, Alan DeKok <aland@deployingradius.com> wrote:
Arran Cudbard-Bell wrote:
Hm, ok I was wrong, it does always forward retries, it's only when the request is waiting to be processed or being processed by a worker that it ignores the retransmissions.
Yes. That was the subject of some debate in the IETF RADIUS working group. The proxy acts as a "pass through" device for retransmits.
I guess that's the root of the fragment reassembly debate.
But if the server is still working on the reqeust, the answer is *unknown*. So it can't proxy it, it can't respond, and it can't do anything other than ignore the retransmit.
Yes.
Doesn't seem that's entirely sensible, or consistent, but ok...
It's really the only choice.
The server could do re-transmits itself. It did that in version 1. But the code was complicated and fragile. And the other people in the RADIUS WG though doing that would break things in the network.
I was more thinking about it in terms of the server imposing a cap on the retransmit rate. I've had NAS go crazy and repeatedly spam the server with Auth and Acct requests, and it'd be nice to stop that craziness from accidentally DoSing the proxy chain.
But the status checks themselves will be retried.
Because FreeRADIUS originated the packet, and is acting like a client. Clients do retransmits...
Sure. I was just clarifying Buxey's response. It was unclear whether the OP was asking whether retransmits of Access-Requests were performed when status-server checks were enabled, or whether the status-server messages were retransmitted. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
That sparked off quite a debate! Thanks everyone. Adrian -----Original Message----- From: freeradius-users-bounces+adrian.p.smith=bt.com@lists.freeradius.org [mailto:freeradius-users-bounces+adrian.p.smith=bt.com@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: 07 February 2014 11:58 To: FreeRadius users mailing list Subject: Re: proxy question On 6 Feb 2014, at 18:55, Alan DeKok <aland@deployingradius.com> wrote:
Arran Cudbard-Bell wrote:
Hm, ok I was wrong, it does always forward retries, it's only when the request is waiting to be processed or being processed by a worker that it ignores the retransmissions.
Yes. That was the subject of some debate in the IETF RADIUS working group. The proxy acts as a "pass through" device for retransmits.
I guess that's the root of the fragment reassembly debate.
But if the server is still working on the reqeust, the answer is *unknown*. So it can't proxy it, it can't respond, and it can't do anything other than ignore the retransmit.
Yes.
Doesn't seem that's entirely sensible, or consistent, but ok...
It's really the only choice.
The server could do re-transmits itself. It did that in version 1. But the code was complicated and fragile. And the other people in the RADIUS WG though doing that would break things in the network.
I was more thinking about it in terms of the server imposing a cap on the retransmit rate. I've had NAS go crazy and repeatedly spam the server with Auth and Acct requests, and it'd be nice to stop that craziness from accidentally DoSing the proxy chain.
But the status checks themselves will be retried.
Because FreeRADIUS originated the packet, and is acting like a client. Clients do retransmits...
Sure. I was just clarifying Buxey's response. It was unclear whether the OP was asking whether retransmits of Access-Requests were performed when status-server checks were enabled, or whether the status-server messages were retransmitted. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Arran Cudbard-Bell wrote:
I guess that's the root of the fragment reassembly debate.
Yes.
I was more thinking about it in terms of the server imposing a cap on the retransmit rate.
Hmm... good point.
I've had NAS go crazy and repeatedly spam the server with Auth and Acct requests, and it'd be nice to stop that craziness from accidentally DoSing the proxy chain.
I'll push a fix.
Sure. I was just clarifying Buxey's response. It was unclear whether the OP was asking whether retransmits of Access-Requests were performed when status-server checks were enabled, or whether the status-server messages were retransmitted.
Proxying is completely separate from status-server checks. They don't affect each other at all. Alan DeKok.
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
adrian.p.smith＠bt.com -
Alan DeKok -
Arran Cudbard-Bell