R: R: R: Ip pool lease migration
> You didn't say that... Sorry, I thought it wasn't so relevant. :-) > Use sqlippool. It's the easiest way to get what you want. Ok, thanks for helping. Francesco. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: R: R: Ip pool lease migration
Francesco Cristofori wrote: > The sql server is actually a mysql master/master replication cluster > with one virtual IP address I pointed the servers to. > I think this solution avoids s.p.o.f., isn't it? You didn't say that... > H... But ip pools are managed through local files on each radius > server, the sql backend stores sessions but not ip assignement. Do I > miss something? Use sqlippool. It's the easiest way to get what you want. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
R: R: Ip pool lease migration
> Then there's a lot less reason to run two servers. You > still have one central point of failure: the SQL server. The sql server is actually a mysql master/master replication cluster with one virtual IP address I pointed the servers to. I think this solution avoids s.p.o.f., isn't it? > If you're insistent on running just one SQL server, you > don't need to do anything on the RADIUS side for IP pools. > Just point both RADIUS servers to the same SQL DB and tables, > and the SQL server will sort it out. H... But ip pools are managed through local files on each radius server, the sql backend stores sessions but not ip assignement. Do I miss something? Thanks, Francesco. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html