Fw: Discard duplicate requests if received within a specified period
ranil.santhish at gmail.com
Fri May 2 17:55:28 CEST 2008
> 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 at 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?
More information about the Freeradius-Users