>From the documentation, DupInterval is applied to the client, ie the
host sending the request, eventually an intermediate proxy.
>From reading the Client.pm source code I see following :
$self->{RecentIdentifiers}->{$nas_id . $code}[$p->identifier]
$nas_id is there supposed to be the NAS-IP-Address, or if not
available NAS-Identifier, which is possibly not the proxy. Only
if none of these attributes are present $nas_id will contain the IP
address of the Client. The $code identifies the type of request, so
on a standard setup that gives a 256 packets history for each kind of
request.
If my understanding is correct this is somewhat different from what
the documentation as well as the comment at the beginning of Client.pm
say.
Now let's go to my particular situation : I have an central accountng Radius
server which gets all accounting packets from the proxys. Whenever this
machine gets really odd (or just out of CPU) the proxies start doing
retransmissions, and then the NASes also start retransmitting (via
a different proxy). By having a really high DupInterval (19) on this
accounting Radius I reduce the number of duplicate records in the
accounting files on that machine, but my clients won't get their
Accounting-Accept because Radiator believes it comes from the same client.
I would conclude that my design is wrong and that I should reduce the
DupInterval on the accounting Radius a lot and have the scripts who
handle the accounting files manage to eliminate the duplicate. Can
someone more knowledgable confirm me this is the way I should go ?
--
Christophe Wolfhugel -+- [EMAIL PROTECTED] -+- France Telecom Oleane
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
