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,
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
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 [EMAIL PROTECTED] piše:
Hi,
Since RADIUS is UDP based this seems to be quite
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
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
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
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
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
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 [EMAIL PROTECTED] wrote:
Accounting packets are not re-transmitted. The contents change, so
they
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 [EMAIL PROTECTED] wrote:
Or is there a possibility to Prioritize Accounting-Response over new
Auth queries so that
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.
On Fri, May 2, 2008 at 6:17 PM, Alan DeKok [EMAIL PROTECTED] 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
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
13 matches
Mail list logo
