(RADIATOR) IP assignment by RADIATOR / delay between IP reuse
ingvarbj at centrum.is
Fri Jun 6 09:39:38 CDT 2003
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
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.
----- 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
> > after this time in different applications).
> > As radiator does not support this at the moment as a feature I've
> > about the following solution:
> > *) 3rd state in the rad_pool table (<AddressAllocator SQL>) => set
> > when accounting STOP records are received (customized DeallocateQuery)
> > *) a cron job (every 5 minutes), which checks if (sysdate - TIMESTAMP) >
> > minutes => set STATEs to 0
> > What do you guys think about this scenario - is it worth a feature
> > for the next radiator release (similar to Reclaim implementation)?
> Could it be implemented just be customising the SQL queries?
> > 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.
More information about the radiator