Well, for the purpose of this issue, we have to assume that for one reason
or another a duplicate packet did, in fact, arrive at Radiator's accounting
port. That's the only way this concern even comes into play. After all, why
build duplicate packet detection into Radiator unless it can detect
duplicate packets.
I really suspect I'm misunderstanding something here, so please explain it
to me, because what I'm hearing is this scenario:
1. The only way Radiator sees a dup is if, for some reason, Radiator's ack
packet doesn't make it back to the NAS, thereby causing a retransmission.
2. Any time the NAS retransmits, it's going to have a different
Acct-Delay-Time (time has, after all, passed).
3. Any duplicate Radiator received will therefore have a different
Acct-Delay-Time.
4. Radiator compares (a checksum of) the whole packet when checking for
duplicates.
5. Therefore, Radiator will perforce fail to recognize the duplication of
any accounting packets.
I know I'm going to kick myself when I hear this. :)
Mike Nerone <mailto:[EMAIL PROTECTED]>
Network Operations Manager
Internet Direct, Inc. <http://www.idworld.net/>
> -----Original Message-----
> From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 08, 2000 3:08 PM
> To: Mike Nerone; [EMAIL PROTECTED]
> Subject: IMPORTANT - RE: (RADIATOR) Duplicates Packets
>
> 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.
===
Archive at http://www.starport.net/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
