Discard duplicate requests if received within a specified period
Hi, I would like to discard duplicate Auth requests based on certain attributes other than the NAS-IP-Address (e.g. Calling-Station-Id, Pool-Name). For example if there are two requests originating from 2 NASes which corresponds to a particular client, I would like to discard the second request if it is received during a threshold time value (eg. 15 seconds) Specially I find that when using SQL for authorization this situation occurs as it takes a while to perform authorization using SQL. Thanks for your guidance, rg
Hi, Since RADIUS is UDP based this seems to be quite sensitive to the delay in response from AAA to NAS and merely depends on the processing delay of the AAA/SQL in Authorization. Has anyone tried performing load tests? Could you tell me how duplicate requests are handled? On Wed, Apr 30, 2008 at 4:02 PM, rsg <ranil.santhish@gmail.com> wrote:
Hi,
I would like to discard duplicate Auth requests based on certain attributes other than the NAS-IP-Address (e.g. Calling-Station-Id, Pool-Name).
For example if there are two requests originating from 2 NASes which corresponds to a particular client, I would like to discard the second request if it is received during a threshold time value (eg. 15 seconds)
Specially I find that when using SQL for authorization this situation occurs as it takes a while to perform authorization using SQL.
Thanks for your guidance,
rg
rsg wrote:
Has anyone tried performing load tests?
Yes. Lots.
Could you tell me how duplicate requests are handled?
As per RFC 5080, which I co-authored. FreeRADIUS has been handling duplicate requests this way since the start. Some commercial servers started doing this only after RFC 5080 was published. Alan DeKok.
They are discarded. Standard setting on most radius clients is to resend the request after 2 seconds without reply. And for most of them it can be configured. Ivan Kalik Kalik Informatika ISP Dana 2/5/2008, "rsg" <ranil.santhish@gmail.com> piše:
Hi,
Since RADIUS is UDP based this seems to be quite sensitive to the delay in response from AAA to NAS and merely depends on the processing delay of the AAA/SQL in Authorization.
Has anyone tried performing load tests? Could you tell me how duplicate requests are handled?
On Wed, Apr 30, 2008 at 4:02 PM, rsg <ranil.santhish@gmail.com> wrote:
Hi,
I would like to discard duplicate Auth requests based on certain attributes other than the NAS-IP-Address (e.g. Calling-Station-Id, Pool-Name).
For example if there are two requests originating from 2 NASes which corresponds to a particular client, I would like to discard the second request if it is received during a threshold time value (eg. 15 seconds)
Specially I find that when using SQL for authorization this situation occurs as it takes a while to perform authorization using SQL.
Thanks for your guidance,
rg
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Ivan Kalik wrote:
They are discarded. Standard setting on most radius clients is to resend the request after 2 seconds without reply. And for most of them it can be configured.
RFC 5080 also specifies a better way to handle retransmits, than the old "try T times, with delay of D seconds between each try". Of course, FreeRADIUS implements it. :) Alan DeKok.
Hi, Many thanks for the reference and explanations. Here's what I see. The following flows correspond to a single transaction. Duplicate Packets are marked based on the id. However, I'm actually talking about retransmissions. Please Refer to Accounting-Request IDs 142,134 and 236. They are retransmissions due to delay in response. -------------- NAS - 10.10.10.17; AAA Server 1.1.1.4 # SRC DST RADIUS 1 10.10.10.17 1.1.1.4 Access-Request(1) (id=185, l=135 2 10.10.10.17 1.1.1.4 Access-Request(1) (id=185, l=135), Duplicate Request ID:185 3 1.1.1.4 10.10.10.17 Access-Accept(2) (id=185, l=38) 4 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=142, l=215) 5 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=142, l=215), Duplicate Request ID:142 6 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=142, l=215), Duplicate Request ID:142 7 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=134, l=257) 8 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=134, l=257), Duplicate Request ID:134 9 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=134, l=257) 10 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=236, l=257) 11 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=236, l=257), Duplicate Request ID:236 12 1.1.1.4 10.10.10.17 Accounting-Response(5) (id=142, l=20) 13 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=236, l=257) 14 1.1.1.4 10.10.10.17 Accounting-Response(5) (id=134, l=20) 15 1.1.1.4 10.10.10.17 Accounting-Response(5) (id=236, l=20) Auth process fails at the client end. Simply speaking, the client does not get the Framed-IP-Address. This occurs, when the (NAS <=> AAA) response delay exceeds ~5 seconds. So according to RFC 5080: Is this an example of "Note that changing the Request ID for a retransmission may have undesirable side effects." ? How could one tackle with this issue? As Ivan described could "NAS retransmit timer" be increased to handle delayed responses? Thanks, If duplicate requests are identified (based on the identifier), On Fri, May 2, 2008 at 3:47 PM, Alan DeKok <aland@deployingradius.com> wrote:
Ivan Kalik wrote:
They are discarded. Standard setting on most radius clients is to resend the request after 2 seconds without reply. And for most of them it can be configured.
RFC 5080 also specifies a better way to handle retransmits, than the old "try T times, with delay of D seconds between each try".
Of course, FreeRADIUS implements it. :)
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Or is there a possibility to Prioritize "Accounting-Response" over new Auth queries so that response delay could be minimized? On Fri, May 2, 2008 at 4:34 PM, rsg <ranil.santhish@gmail.com> wrote:
Hi, Many thanks for the reference and explanations.
Here's what I see. The following flows correspond to a single transaction. Duplicate Packets are marked based on the id.
However, I'm actually talking about retransmissions. Please Refer to Accounting-Request IDs 142,134 and 236. They are retransmissions due to delay in response.
-------------- NAS - 10.10.10.17; AAA Server 1.1.1.4
# SRC DST RADIUS 1 10.10.10.17 1.1.1.4 Access-Request(1) (id=185, l=135 2 10.10.10.17 1.1.1.4 Access-Request(1) (id=185, l=135), Duplicate Request ID:185 3 1.1.1.4 10.10.10.17 Access-Accept(2) (id=185, l=38)
4 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=142, l=215) 5 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=142, l=215), Duplicate Request ID:142 6 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=142, l=215), Duplicate Request ID:142 7 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=134, l=257) 8 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=134, l=257), Duplicate Request ID:134 9 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=134, l=257) 10 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=236, l=257) 11 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=236, l=257), Duplicate Request ID:236 12 1.1.1.4 10.10.10.17 Accounting-Response(5) (id=142, l=20) 13 10.10.10.17 1.1.1.4 Accounting-Request(4) (id=236, l=257) 14 1.1.1.4 10.10.10.17 Accounting-Response(5) (id=134, l=20) 15 1.1.1.4 10.10.10.17 Accounting-Response(5) (id=236, l=20)
Auth process fails at the client end. Simply speaking, the client does not get the Framed-IP-Address.
This occurs, when the (NAS <=> AAA) response delay exceeds ~5 seconds.
So according to RFC 5080: Is this an example of "Note that changing the Request ID for a retransmission may have undesirable side effects." ?
How could one tackle with this issue?
As Ivan described could "NAS retransmit timer" be increased to handle delayed responses?
Thanks,
If duplicate requests are identified (based on the identifier),
On Fri, May 2, 2008 at 3:47 PM, Alan DeKok <aland@deployingradius.com> wrote:
Ivan Kalik wrote:
They are discarded. Standard setting on most radius clients is to resend the request after 2 seconds without reply. And for most of them it can be configured.
RFC 5080 also specifies a better way to handle retransmits, than the old "try T times, with delay of D seconds between each try".
Of course, FreeRADIUS implements it. :)
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Or is there a possibility to Prioritize "Accounting-Response" over new Auth queries so that response delay could be minimized?
I would look into why it takes so long to process Accounting-Requests. Something is seriously wrong there. How long does it take to do an insert for a Start packet? Ivan Kalik Kalik Informatika ISP
I'm trying to process multiple queries at the same time and when it exceeds 32 this delay occurs. SQLIPPOOL is being used for Autz. On Fri, May 2, 2008 at 5:39 PM, Ivan Kalik <tnt@kalik.net> wrote:
Or is there a possibility to Prioritize "Accounting-Response" over new Auth queries so that response delay could be minimized?
I would look into why it takes so long to process Accounting-Requests. Something is seriously wrong there. How long does it take to do an insert for a Start packet?
Ivan Kalik Kalik Informatika ISP
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rsg wrote:
However, I'm actually talking about retransmissions. Please Refer to Accounting-Request IDs 142,134 and 236. They are retransmissions due to delay in response.
Accounting packets are not re-transmitted. The contents change, so they get allocated a new Id.
Auth process fails at the client end. Simply speaking, the client does not get the Framed-IP-Address.
This occurs, when the (NAS <=> AAA) response delay exceeds ~5 seconds.
Fix your NAS. 5 seconds SHOULD be an acceptable timeout for the NAS. If the NAS is on the same LAN as the RADIUS server, 5 seconds is *way* too long for the RADIUS server to respond.
So according to RFC 5080: Is this an example of "Note that changing the Request ID for a retransmission may have undesirable side effects." ?
No.
How could one tackle with this issue?
As Ivan described could "NAS retransmit timer" be increased to handle delayed responses?
Yes. See your NAS documentation. Alan DeKok.
rsg wrote:
However, I'm actually talking about retransmissions. Please Refer to Accounting-Request IDs 142,134 and 236. They are retransmissions due to delay in response.
Alan DeKok <aland@deployingradius.com> wrote: Accounting packets are not re-transmitted. The contents change, so they get allocated a new Id.
OK, I understand. They 142 is a "Start" message whereas 134, and 236 are "Stop" messages with different Acct-Session-Ids.
Auth process fails at the client end. Simply speaking, the client does not get the Framed-IP-Address.
This occurs, when the (NAS <=> AAA) response delay exceeds ~5 seconds.
Fix your NAS. 5 seconds SHOULD be an acceptable timeout for the NAS.
If the NAS is on the same LAN as the RADIUS server, 5 seconds is *way* too long for the RADIUS server to respond.
They are not on the same LAN. This delay is induced by SQL based IP assignment. Specially when around 30 concurrent Auth queries are made, the accounting response (Start) takes about 30 seconds (Delayed by New Auth requests) to reach NAS leading to the ultimate Auth failures.
How could one tackle with this issue?
As Ivan described could "NAS retransmit timer" be increased to handle delayed responses?
Yes. See your NAS documentation.
Could Accouting-Responses be prioritized over New Auth-queries? Many Thanks.
rsg wrote:
They are not on the same LAN. This delay is induced by SQL based IP assignment.
Specially when around 30 concurrent Auth queries are made, the accounting response (Start) takes about 30 seconds (Delayed by New Auth requests) to reach NAS leading to the ultimate Auth failures.
Huh? You're saying that the NAS rejects the user because it can't send an Accounting-Request packet? That's broken.
Could Accouting-Responses be prioritized over New Auth-queries?
No. (1) Your SQL server seems to have problems. 32 queries/s isn't a lot. (2) Your NAS seems to have problems. Users should NOT be rejected because it doesn't get an accounting response packet (3) Even if it *did* prioritize accounting responses, all you would be doing is trading off rejecting one user for rejecting another user. Something is broken in your system. It's not FreeRADIUS. Alan DeKok.
On Fri, May 2, 2008 at 6:17 PM, Alan DeKok <aland@deployingradius.com> wrote:
rsg wrote:
They are not on the same LAN. This delay is induced by SQL based IP assignment.
Specially when around 30 concurrent Auth queries are made, the accounting response (Start) takes about 30 seconds (Delayed by New Auth requests) to reach NAS leading to the ultimate Auth failures.
Huh? You're saying that the NAS rejects the user because it can't send an Accounting-Request packet? That's broken.
No, NAS doesn't receive the Accounting-Response from AAA in time.
Could Accouting-Responses be prioritized over New Auth-queries?
No.
(1) Your SQL server seems to have problems. 32 queries/s isn't a lot. (2) Your NAS seems to have problems. Users should NOT be rejected because it doesn't get an accounting response packet (3) Even if it *did* prioritize accounting responses, all you would be doing is trading off rejecting one user for rejecting another user.
Something is broken in your system. It's not FreeRADIUS.
Thanks. Will have a closer look into the SQL first..
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan DeKok wrote:
rsg wrote:
They are not on the same LAN. This delay is induced by SQL based IP assignment.
Specially when around 30 concurrent Auth queries are made, the accounting response (Start) takes about 30 seconds (Delayed by New Auth requests) to reach NAS leading to the ultimate Auth failures.
Huh? You're saying that the NAS rejects the user because it can't send an Accounting-Request packet? That's broken.
I've seen NASes where this is configurable behaviour e.g. 3Com Superstack III switches. Thankfully the default is to be sensible
participants (4)
-
Alan DeKok -
Ivan Kalik -
Phil Mayers -
rsg