(RADIATOR) Duplicate request id: ignored

[Hugh Irvine]

Hello Angel -

The port from which the reply is sent back is the same as the request was 
received on, which is specified by the AuthPort/AcctPort parameters (UDP 
1645/1646 by default).

regards

Hugh


On Wed, 3 Jul 2002 13:52, Angel Bustos wrote:
> Hi Hugh,
>
> Very clear your point.
> Just to begin a good search of this issue: do I begin searching for any
> specific port for the Radiator "sent-back" accounting response?
> I believe that I'll begin by disabling Redhat 7.2 default ipchains
> firewalling rules and I'd know the port or ports range that Radiator uses
> for sending back the accounting response, it will be helpful.
>
> Thanks again for your support,
>
>
> Angel Bustos
> email: angelbustos at brujula.net
>
> Hugh Irvine writes:
> > 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.
>
> ___________________________________________________________________________
>_
>
> Conéctese Gratis a Internet desde http://www.brujula.net/gratis

-- 
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.