Hello Mike -
On Thu, 09 Mar 2000, Mike Nerone wrote:
> I am in the process of implementing Radiator at the moment (converting from
> hacked Livingston radiusd), and I wanted to make sure this isn't a problem.
> It seems unlikely that this has not already been addressed, but here goes
> anyway:
>
> I have looked at my detail logs, and I see varying Acct-Delay-Time fields in
> duplicate packets for all of these types of NAS's:
>
> Lucent (Livingston) Portmaster 2
> Lucent (Livingston) Portmaster 3
> Total Control
> Ascend Max 4000
>
> Happily, I don't see any for our Nortel CVX 1800, but it's conceivable that
> there just haven't BEEN any duplicates (some of the counts for the other
> NAS's were quite low, as well).
>
Perhaps a brief description of the Radius protocol is in order here as I have
seen a number of questions about Acct-Delay-Time recently.
The problem you are seeing occurs because Radius uses the UDP transport
protocol for all its packet forwarding. If the NAS sends a Radius accounting
packet when a session terminates (accounting Stop), it sets the Acct-Delay-Time
to zero (0) - ie. the event happened now. If the NAS does not receive a reply
from the Radius server, either because the packet was lost in transit, or
because there was a packet collision on an ethernet, or whatever, the NAS will
timeout on the first transmission (according to the retransmission timer and
the retry count) and send another accounting packet. However, time has moved on
since the first transmission, so by definition the Acct-Delay-Time has changed
- ie. the event occurred some number of seconds ago. Therefore, the contents of
the packet have changed, therefore Radiator thinks it is seeing a new packet.
Note that the above is only a problem if Radiator has already seen the first
packet, but the reply either did not arrive at the NAS, or the reply arrived
too late, ie. after the retransmission timer on the NAS had expired.
What all of the above indicates is that you need to be very careful in your
network design and in your choice of retransmission timers and backend
processing to make sure that it is not your design that is causing the problem.
hth
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
