2.4.1 Checking for Duplicate Requests

As described above (see section How Radius Operates), a NAS may decide to retransmit the request under certain circumstances. This behavior ensures that no requests are lost. For example, consider the following scenario:

1. The NAS sends a request to the server.
2. The server processes it and sends back the reply.
3. The reply is lost due to a network outage, or the load average of the NAS is too high and it drops the response.
4. The NAS retransmits the request.

Thus the RADIUS server will receive and process the same request twice. This probably won't do any harm if the request in question is an authentication one, but for accounting requests it will lead to duplicate accounting. To avoid such an undesirable effect, radiusd keeps a queue of received requests. When an incoming request arrives, radiusd first scans the request queue to see if the request is a duplicate. If so, it drops the request; otherwise, it inserts the request into the queue for processing. After the request is completed, it will still reside in the queue for a preconfigured interval of time (see section auth statement, parameter request-cleanup-delay).

By default, radiusd considers two requests to be equal if the following conditions are met:

1. Both requests come from the same NAS.
2. They are of the same type.
3. The request identifier is the same for both requests.
4. The request authenticator is the same for both requests.

Additionally, radiusd may be configured to take into account the contents of both requests. This may be necessary, since some NASes modify the request authenticator or request identifier before retransmitting the request, so the method described above fails to recognize the request as a duplicate. This extended comparison is described in detail in Extended Comparison.

This document was generated by Sergey Poznyakoff on December, 6 2008 using texi2html 1.78.