(RADIATOR) Duplicate request id: ignored

Tue Jul 2 22:52:07 CDT 2002

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