sql ip pool module assign IP 0.0.0.0 to users
mirko.alberio at telemar.it
Fri Nov 19 15:47:43 CET 2021
thanks as always for your help,
actually I was monitoring MYSQL server load and performance but it did
not seem the bottleneck.
The strange behaviour is that Radius successfully authenticates the
users (so can read the radius users table) but assign those 0.0.0.0 (and
in some limit cases even actually public IPs, but the same to multiple
users. See below.
Also, I can say that POPs are sending Accounting on when rebooting. The
problem seems is they are not sending Accounting off 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?
Mirko Alberio - Assistenza tecnica
e-mail:mirko.alberio at telemar.it
Telemar SpA Internet Quality Provider
Via Enrico Fermi, 235 - 36100 Vicenza - Italia
Tel 0444 291302 - Fax 0444 566310 -www.telemar.it
Assistenza tecnica 0444 1420000
Reg. Imp. Di Vicenza /C.F./P.I. 02508710247
Cap. Soc. € 120.000,00 I.V.
Il 19/11/2021 13:47, Alan DeKok ha scritto:
> On Nov 19, 2021, at 5:03 AM, Mirko Alberio via Freeradius-Users<freeradius-users at lists.freeradius.org> wrote:
>> We have the following problem:
>> When many of out NAS (which are Wireless PPPOE POPs) that are Mikrotik based are rebooted (for maintanance, updates or maybe outages) and then simultaneously connect to our Freeradius instance to authenticate again we are experiencing the following rows in the logs:
>> Thu Nov 18 06:25:06 2021 : Error: Received conflicting packet from client OpenFiber port 50242 - ID: 114 due to unfinished request. Giving up on old request.
>> Thu Nov 18 06:25:06 2021 : Error: Received conflicting packet from client port 33577 - ID: 70 due to unfinished request. Giving up on old request.
>> Thu Nov 18 06:25:06 2021 : Error: Received conflicting packet from client port 37882 - ID: 21 due to unfinished request. Giving up on old request.
>> Thu Nov 18 06:25:06 2021 : Error: Received conflicting packet from client port 50131 - ID: 95 due to unfinished request. Giving up on old request.
>> Thu Nov 18 06:25:06 2021 : Error: Received conflicting packet from client port 40360 - ID: 211 due to unfinished request. Giving up on old request.
>> Thu Nov 18 06:25:06 2021 : WARNING: (8349606) WARNING: Module rlm_sql became unblocked
>> Thu Nov 18 06:25:06 2021 : WARNING: (8349607) WARNING: Module rlm_sql became unblocked
> This means that your SQL server can't keep up with the load. Add more CPU / disk / memory / replicas in order to fix it.
> No amount of poking FreeRADIUS will make your SQL server run faster.
>> And the customers PPPOE sessions are getting an assigned IP = 0.0.0.0 instead of one of the IP pool.
> The SQL IP pool module does not assign IP of 0.0.0.0 when the SQL server is down. Either you updated the FreeRADIUS configuration to do that, or FreeRADIUS is *not* returning an IP, and then the NAS is assigning that address itself.
>> We have some doubts that this could happen because the POPs are not sending the correct AccTerminate packets when rebooting, so it is not freeing up the pools. And also those sessions are not recognized as active because we are using NAS PORT ID as pool key and it changes, maybe would be better tu user the Mac Address as key?
> It's best to make the SQL databases run faster.
> If the POPs aren't sending Accounting-On when rebooting, then fix them so that they do that. This is a separate issue, but still a problem.
>> A final note: our IP pool is nearly exhausted, we have about 30 free IPs. Could this also give problems?
> That shouldn't be a problem, unless all of the IPs are used. The server should then *reject* the users requests, as IPs cannot be allocated.
> Alan DeKok.
More information about the Freeradius-Users