(RADIATOR) Duplicate request id: ignored

[Hugh Irvine]

Hello Angel -

Let me try to explain.

If Radiator is receiving the accounting requests, is processing them 
correctly, and is sending back an accounting-response - it then follows that 
there is no problem with Radiator itself.

The first thing to check is the local ethernet interface on the Radiator 
host, using snoop or tcpdump or ethereal or whatever. This is to make sure 
that the accounting-response is actually getting onto the wire and is not 
being blocked by local access rules or filters.

The second thing to check is the transmission path between the Radiator host 
and the remote proxy, again to make sure there are no filters or firewalls 
blocking the return path. Remember - just because you can receive a packet 
does not mean that a return packet can get back. 

The last thing to check is the remote proxy (or indeed NAS) to make sure that 
the accounting-response is getting back. If it is getting back, but the proxy 
(or NAS) resends another packet, then clearly the problem is there and 
requires either a bug fix or whatever. If the accounting-response is *not* 
getting back - then go back to point 2 above.

Tracking down these sorts of problems is time-consuming and tedious, but such 
is the life of a network engineer....

regards

Hugh


On Fri, 28 Jun 2002 11:47, Angel Bustos wrote:
> Hi Hugh, Dave et al,
>
> I'm receiving just accounting forward from a customer for further
> processing, and I've noticed the same problem; a lot of retransmissions
> (connectivity with our customer is really good however);
>
> I've followed your advice and i've set explicitly DupInterval to 2 seconds
> in our customer's NAS Client clause, and I can see in our logfile lots of
> INFO  messages:
>
> Thu Jun 27 22:30:56 2002: INFO: Duplicate request id 28 received from
> x.x.x.x(48766): ignored
>
> I understand from this the same thing  Dave pointed: Radiator just
> ignore and  discard retransmission without further action, but the
> retransmissions ocurred wasting BW in our case
>
> I saw the rfc's in Radiator /doc directory and it seems that radius
> protocol cannot sent "rejects" backward to avoid wasting BW by lots of
> UDP re-transmissions;
> Radiator by itself, could have another feature to avoid this waste of
> bandwidth or I'm missing completely the point?
>
> Best regards,
>
> Angel Bustos
> angelbustos at brujula.net
>
> On Thu, 27 Jun 2002, Hugh Irvine wrote:
> > Hello Dave -
> >
> > You normally configure the timeout and retransmit values in your NAS(s)
> > so there will only ever be a small number of retransmissions. If your NAS
> > sends more requests than you tell it to, it is an issue that must be
> > addressed by your supplier.
> >
> > BTW - the DupInterval configured in the Client clauses defines the number
> > of seconds in the sliding window during which a retransmission is
> > considered a duplicate.
> >
> > I suggest you read the RFC's for further information (included in the
> > Radiator distribution in the "doc" directory).
> >
> > regards
> >
> > Hugh
> >
> > On Thu, 27 Jun 2002 07:04, Dave Kitabjian wrote:
> > > "Wed Jun 26 16:03:16 2002: INFO: Duplicate request id 87
> > > received from 10.52.0.1(1026): ignored"
> > >
> > > This message was logged for an Accounting request that was clearly
> > > retransmitted since it had a large Acct-Delay-Time value.
> > >
> > > But if Radiator keeps ignoring the request, the NAS will keep
> > > retransmitting, and the circle of life will go on and on and on...
> > >
> > > Does the RFC say to ignore dups? Wouldn't it make more sense to Reject
> > > them somehow? Or, if the original one was already processed
> > > successfully, it could simply send back an Accept and then discard it
> > > as a dup?
> > >
> > > Dave
> > >
> > > ===
> > > Archive at http://www.open.com.au/archives/radiator/
> > > Announcements on radiator-announce at open.com.au
> > > To unsubscribe, email 'majordomo at open.com.au' with
> > > 'unsubscribe radiator' in the body of the message.
> >
> > --
> > Radiator: the most portable, flexible and configurable RADIUS server
> > anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
> > -
> > Nets: internetwork inventory and management - graphical, extensible,
> > flexible with hardware, software, platform and database independence.
> > ===
> > Archive at http://www.open.com.au/archives/radiator/
> > Announcements on radiator-announce at open.com.au
> > To unsubscribe, email 'majordomo at open.com.au' with
> > 'unsubscribe radiator' in the body of the message.
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.