Alan DeKok ha scritto: 
nick wrote:
  
At the moment we have a freeradius 1.1.3 server on CentOS which is
functioning fine, but due to circumstances, and the devices we are using
as NASes, the ip pools are located on the NAS instead of being
centralized on the RADIUS server as we'd like it.
    

  You should really upgrade to a more recent version.

That's the plan :)
  
We'd now like to make things a bit more robust, including a clustered
MySQL backend for AAA, and, if possible, load balanced freeradius
servers on the front end.

We'd also like to use SQL ip pools. I am only unsure about one thing
though. If we have a shared pool available via DB, what prevents the two
load balanced radius instances from giving out the same ip address?
    

  For one, SQL IP pools are likely to *not* work in 1.1.3.  There were a
number of fixes put into 2.x that solved those problems.

Certainly, the idea is to upgrade the whole infrastructure, to allow for more flexibility, and redundancy. 

  

    
I've been doing a fair bit of googling, but without a whole lot of luck
in this respect.
    

  

  

  MySQL is a DB.  If it exports a transactional API, then it doesn't
matter if two RADIUS servers are allocating IP's simultaneously.

  Alan DeKok.
  



I may have misphrased the question, if the ip pool is a single one,
containing say 192.168.1.1 - 192.168.1.50, is there a way that the
second Radius server can know the IPs distributed by the first Radius
server to avoid duplicate IP assignments?



Or is the only way to have two separate ip pools without overlap?





  
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html