sql ip pool module assign IP 0.0.0.0 to users

[Alan DeKok]

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:

https://networkradius.com/articles/2021/05/20/DHCP-enhancements-in-FreeRADIUS-3.html

  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.

  That's fine.

> 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.

  Alan DeKok.