Good morning, We are using freeradius rlm_ippool to asign IPs in some VPN service. As our NAS (VPN server) do not support sending accounting packets to our radius, our assigned IPs do not get released properly with accounting-stop packets. So we have to release them "manually". In our previous freeradius (2.1.9) we used "rlm_ippool_tool -r db.ippool db.ipindex" to release them periodically. But with our actual freeradius (3.0.10) we are suffering some kind of corruption on db files if we used the tool "rlm_ippool_tool -r". With "kind of corruption" I meant that we are seeing that the pool size is getting smaller and smaller through time. [2] Very weird. So we tried some other ways to release the assigned IPs. We set maximum_timeout attribute on the ippool to 86400 seconds (1 day), in order to make the entries not active after a day, but it is not working either. We are not seeing any "active" (active:1) IP changing to "not active" (active:0). How is this timeout suppose to work? Reading the doc [3], it just says: "# maximum-timeout: If not zero specifies the maximum time in seconds an entry may be active." How is an active entry going to change its status from active:1 to active:0 ? How is it tracking how much time it is active? Does the module rlm_ippool needs to be called also in a special way? Or is it just releasing the IPs when it needs them because the pool is full? Or maybe we have just misunderstood the real use of this max_timeout attribute. Thank you very much for your help. Regards, [1] http://lists.freeradius.org/pipermail/freeradius-users/2014-September/073835... [2] We check the ippool status using: "rlm_ippool_tool -v db.ippool db.ipindex |wc -l" [3] http://wiki.freeradius.org/modules/Rlm_ippool *Oscar Remírez de Ganuza Satrústegui* IT Services Universidad de Navarra Tel. +34 948425600 x803130 http://www.unav.edu/web/it/
On Apr 22, 2016, at 7:57 AM, Óscar Remírez de Ganuza Satrústegui <oscarrdg@unav.es> wrote:
But with our actual freeradius (3.0.10) we are suffering some kind of corruption on db files if we used the tool "rlm_ippool_tool -r". With "kind of corruption" I meant that we are seeing that the pool size is getting smaller and smaller through time. [2] Very weird.
Honestly... just use rlm_sql_ippool. It's better, and you can use standard tools to administer the database.
Or maybe we have just misunderstood the real use of this max_timeout attribute.
Honestly, I'm not sure. I haven't used the non-SQL ippool module in a long time. We've even removed it in 3.1, because it doesn't make sense to have multiple implementations of the same thing. if you need a small on-disk IP pool, use rlm_sql_ippool, with the sqlite driver. It does a lot more than the rlm_ippool module, and is more stable. Alan DeKok.
On Fri, Apr 22, 2016 at 3:20 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Apr 22, 2016, at 7:57 AM, Óscar Remírez de Ganuza Satrústegui < oscarrdg@unav.es> wrote:
But with our actual freeradius (3.0.10) we are suffering some kind of corruption on db files if we used the tool "rlm_ippool_tool -r". With "kind of corruption" I meant that we are seeing that the pool size is getting smaller and smaller through time. [2] Very weird.
Honestly... just use rlm_sql_ippool. It's better, and you can use standard tools to administer the database.
Ok, thank you very much for your answer Alan. I will try moving to rlm_sql_ippool.
Or maybe we have just misunderstood the real use of this max_timeout attribute.
Honestly, I'm not sure. I haven't used the non-SQL ippool module in a long time. We've even removed it in 3.1, because it doesn't make sense to have multiple implementations of the same thing.
if you need a small on-disk IP pool, use rlm_sql_ippool, with the sqlite driver. It does a lot more than the rlm_ippool module, and is more stable.
Alan DeKok.
Thanks again. Regards, *Oscar Remírez de Ganuza Satrústegui* IT Services Universidad de Navarra Tel. +34 948425600 x803130 http://www.unav.edu/web/it/
participants (2)
-
Alan DeKok -
Óscar Remírez de Ganuza Satrústegui