sql ip pool module assign IP 0.0.0.0 to users
aland at deployingradius.com
Fri Nov 19 16:35:15 CET 2021
On Nov 19, 2021, at 9:47 AM, Mirko Alberio via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> actually I was monitoring MYSQL server load and performance but it did not seem the bottleneck.
When the logs say:
Thu Nov 18 06:25:06 2021 : WARNING: (8349606) WARNING: Module rlm_sql became unblocked
That means that the SQL module sent a query to MySQL, and MySQL didn't respond for 5 seconds. That's a problem.
Plus, you said this happens when power goes off / on again. That is a huge spike of traffic, which can easily overload databases.
> The strange behaviour is that Radius successfully authenticates the users (so can read the radius users table)
Yes, which is just reading a table. That may work, but IP allocation is read/write. That can result in congestion, as many queries try to read/write locked rows.
One fix is to be sure that you're using the latest server, and the latest queries, and the latest schema. We've put work into optimizing this so it works better in high-load scenarios:
That page mentions DHCP, but we've done similar things for RADIUS. But even as you'll see there, it tops out at ~2K IPs allocated per second.
> but assign those 0.0.0.0 (and in some limit cases even actually public IPs, but the same to multiple users. See below.
FreeRADIUS does *not* assign 0.0.0.0 if something goes wrong. If the sqlippool module is unable to allocate an IP address, it returns FAIL or NOOP. It will *never* return a 0.0.0.0 IP address to the user.
> Also, I can say that POPs are sending Accounting on when rebooting.
> The problem seems is they are not sending Accounting off
That isn't an issue.
> and probably the IP assignation lingers there, or should (like you explained before) those sessione be marked as "dead" and so IP can be re-used?
The sessions will be marked dead when FreeRADIUS receives Accounting On.
More information about the Freeradius-Users