I can't see any easy way around this, other than to write some custom queries, or perhaps a stored procedure in the database. Or alternatively, what about setting up the address pools on the NAS?
regards
Hugh
On Tuesday, August 20, 2002, at 05:32 AM, Brian Morris wrote:
I think in the case of DSL clients though this is not quite correct.
�
We have several 000's of DSL clients but only about 25% of them are online at any one time.� Sure they CAN be permanent, but they usually are not.
�
It is a waste of IP space to allocate a static IP to all of them.� In some business cases it is even desirous not to allocate them a static IP - but rather make it�an 'additional' purchase ;-)�
�
We have sometimes run into a problem where if the NAS fails, or the customers DSL router messes up and tries to login hundreds of times a minute we soon run out of available IP addresses in RADPOOL� - upon inspection of RADPOOL it shows that the same user has dozens or more ip addresses allocated to them with a state of (1).
�
It would be good if there was some method of clearing these up - currently, we run a script which sets the state of all but the most receint allocation to (0) for any user with more than one entry in RADPOOL.� (We don't allow simultaneous logins on our DSL service)
�
Has anyone else has similar problems and/or found a solution?
�
Regards,� Brian.
�
�
----- Original Message -----
From: Hugh Irvine
To: Ayotunde Itayemi
Cc: [EMAIL PROTECTED]
Sent: Monday, August 19, 2002 11:48 PM
Subject: Re: (RADIATOR) Re: DefaultLeasePeriod
Hello Tunde -
By definition a customer with a permanent connection would not use a dynamic address.
You should allocate such users static addresses instead.
regards
Hugh
NB: I am travelling this week, so there may be delays in our correspondence.
--
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.
