(RADIATOR) IP assignment by RADIATOR / delay between IP reuse

[Ingvar Bjarnason]

Hi Rainer,

    We have a similar scheme here that so far has been working well for us.
Our strategy is simply to always use the ip from the pool that has been
unused for the longest period.   That way you dont run into the potential
problem of "running out" of IP numbers if you have a high rotation rate in
your pool and a large number of your addresses are still held up while
technically being free for reuse.   But if the requirement for the 10
minutes is strict your way is probably better.

To do what we are doing requires a slight modification of the find query as
follows :

FindQuery   select TIME_STAMP, YIADDR, SUBNETMASK, DNSSERVER from RADPOOL
where POOL='%0' and STATE=0 order by TIME_STAMP LIMIT 1

Basically add the "order by TIME_STAMP" to the query.

    Best regards,
                                Ingvar

------
Ingvar Bjarnason
Engineer/Data division
Iceland Telecom

----- Original Message -----
From: "Mike McCauley" <mikem at open.com.au>
To: <rainer.huber at gmx.at>; <radiator at open.com.au>
Sent: Friday, June 06, 2003 12:08 AM
Subject: Re: (RADIATOR) IP assignment by RADIATOR / delay between IP reuse


> Hello Rainer,
>
> I cant seem to find you in my records.
> Will you please let me know the name of the Radiator licensee involved?
>
> On Fri, 6 Jun 2003 04:01 am, Huber, Rainer wrote:
> > Hi List,
> >
> > In the near future I'll have to switch a radiator configuration (2
> > radiators/OracleDB) to IP assignment by RADIUS.
> >
> > There is one special requirement, which has to be implemented: The IP
> > addresses have to be kept back a defined period of time before they are
> > reassigned to new sessions (ex. 10 min => IP<->username caches are
cleared
> > after this time in different applications).
> >
> > As radiator does not support this at the moment as a feature I've
thought
> > about the following solution:
> > *) 3rd state in the rad_pool table (<AddressAllocator SQL>) => set
STATE=2
> > when accounting STOP records are received (customized DeallocateQuery)
> > *) a cron job (every 5 minutes), which checks if (sysdate - TIMESTAMP) >
10
> > minutes => set STATEs to 0
> >
> > What do you guys think about this scenario - is it worth a feature
request
> > for the next radiator release (similar to Reclaim implementation)?
>
> Could it be implemented just be customising the SQL queries?
>
> Cheers.
>
>
> >
> >
> > Regards,
> >
> > Rainer
> >
> > ===
> > 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.
>
> --
> Mike McCauley                               mikem at open.com.au
> Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
> 24 Bateman St Hampton, VIC 3188 Australia   http://www.open.com.au
> Phone +61 3 9598-0985                       Fax   +61 3 9598-0955
>
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS, PEAP etc on Unix, Windows, MacOS etc.
>
> ===
> 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.