(RADIATOR) Duplicate detection doesn't use source port

Tue Sep 6 01:38:39 CDT 2005

We use the Ericsson GGSN J20 towards RADIATOR and find that at times of
high load we also experience duplicate packets due to the same
identifier being received in the same second.

The Dupinterval was set to zero and this sorted out our problem,
temporarily.

We would also have the requirement to accept packets based on source
address, and source ports and identifiers, in this way greatly improving
the capacity of RADIATOR.

We now have a problem when proxying accounting requests to the WAP
gateway. The high load causes the WAP gateway to receive "duplicate"
packets and the WAP gateway then tends to swap THE msisdn received. This
makes it impossible to download your MMS messages as the auth then
fails.

Anyone, experiencing similar problems?

Regards

-----Original Message-----
From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au] On
Behalf Of Jonathan Kinred
Sent: Tuesday, 06 September 2005 6:51 AM
To: Hugh Irvine
Cc: radiator at open.com.au
Subject: Re: (RADIATOR) Duplicate detection doesn't use source port

Hi Hugh,

I will see what i can do regarding the information from Cisco.

In the meantime i have found that the number of source ports is only 
200, i had previously been informed that it was in the 10's of thousands

:). So i think the potential memory usage per NAS would be 200 ports x 
255 identifiers x 2 request types x sizeof(RecvTime) which is ok for us.

Saying that, we'd have to hack the Client.pm code to extend the 
RecentIdentifiers hash to include a source port:

From:
$self->{RecentIdentifiers}->{$p->{RecvFromAddress}}->{$code.$p->identifi
er}

to:
$self->{RecentIdentifiers}->{$p->{RecvFromAddress}}->{$p->{RecvFromPort}
}->{$code.$p->identifier}
or:
$self->{RecentIdentifiers}->{$p->{RecvFromAddress}.$p->{RecvFromPort}}->
{$code.$p->identifier}

We're not that keen on tracking this change through radiator versions so

ideally we'd like to see an option like DupSourcePortCheck which turns 
this on.

What do you think?

Jonathan

Hugh Irvine wrote:
> 
> Hello Jonathon -
> 
> If you can find out from Cisco how they indicate that a particular  
> request is a duplicate when extended source ports are turned on, we  
> will be only too happy to implement their algorithm. Note that the
RFC 
> does not cover the case of different source ports for each  request.
In 
> the absence of any other information, setting DupInterval  0 is your 
> only option in the Radiator configuration file (or  NoIgnoreDuplicates

> for finer grained control).
> 
> regards
> 
> Hugh
> 
> 
> On 6 Sep 2005, at 11:43, Jonathan Kinred wrote:
> 
>> Hi,
>>
>> During testing we discovered that the source port of a request is
not 
>> taken into account for duplicate detection. With the default  
>> DupInterval of 2 seconds this means that Radiator will start
ignoring 
>> packets as dupes when a NAS sends more than ~128 requests  per
second. 
>> We are using a Cisco SSG and want to turn on extended  source ports, 
>> so we're definitely going to run into the excessive  memory problem 
>> below.
>>
>> I'm wondering if there is a more elegant way for Radiator to handle  
>> this rather than breaking the RFC and not using the source port. I
am 
>> thinking along the lines of having requests purged from the  
>> RecentIdentifiers hash when they exceed DupInterval. It sounds like  
>> an expensive operation but as i see it our only option for these  
>> NAS's is to enable NoIgnoreDuplicates or live with the 128 per
second 
>> limit.
>>
>> I'd also like to hear if someone has a better solution using the  
>> current Radiator versions.
>>
>> -- 
>> Jonathan Kinred
>> System Administrator
>> Dot Communications
>>
>>
>> Revision 3.6 (2003-04-14 Significant improvements to wireless
support)
>> Client duplicate detection now ignores the source port, due to some  
>> clients (notably Cisco APs) using a different port for every
request, 
>> resulting in excessive memory usage.
>>
>> Revision 2.16.2 (21/8/00) Minor fixes
>> Duplicate checking now takes the client port into account, as  
>> required by RFC 2865.
>>
>> -- 
>> 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.
>>
> 
> 
> NB:
> 
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive (www.open.com.au/archives/ 
> radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
> 

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

NOTE: This e-mail message is subject to the MTN Group disclaimer see http://www.mtn.co.za/disclaimer

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