Fw: Discard duplicate requests if received within a specified period

[rsg]

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 at 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 at 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
>  >
>