(RADIATOR) Duplicate detection doesn't use source port

Ash Garg ash at telstra.net
Tue Sep 6 01:07:53 CDT 2005


Guys,

Cisco's implementation is described in:

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5187/products_comm
and_reference_chapter09186a008017cf1c.html#wp1107199


Ash
Network Engineer
Telstra

-----Original Message-----
From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au]On
Behalf Of Jonathan Kinred
Sent: Tuesday, 6 September 2005 2:51 PM
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->identifier}

to:
$self->{RecentIdentifiers}->{$p->{RecvFromAddress}}->{$p->{RecvFromPort}}->{
$code.$p->identifier}
or:
$self->{RecentIdentifiers}->{$p->{RecvFromAddress}.$p->{RecvFromPort}}->{$co
de.$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.

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


More information about the radiator mailing list