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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html