Eugene Grosbein wrote:
We use FreeRADIUS 2.2.0 as DHCP server with rlm_perl to connect to external database to run stored procedure there that returns IP/mask/DNS etc for option82-enabled requests.
Why rlm_perl? Why not use rlm_sql directly? You can update the SQL qeuries to run a stored procedure. Then, make sure that the stored procedure returns "Attribute = value". The SQL module will then take care of parsing those attributes, and adding them to the reply.
The database is pretty fast and serves hundreds of parallel requests in 1 second or less.
That's bad. One second is *not* a fast response time for a database.
FreeRADIUS receives all DHCP requests from external high loaded DHCP relay and threats them all as coming from single DHCP client.
Our perl script does extensive logging through direct syslog connection and I see that there is great delay between the moment of DHCP request arrival as shown by tcpdump and the moment when post_auth perl function is invoked by FreeRADIUS.
Run FreeRADIUS in debugging mode to see why.
This delay is about 6 seconds and some DHCP clients do not wait for so long.
Is it possible to eliminate these delays? Here are lines from radiusd log:
Yes. Fix your database so it's fast. Remove the rlm_perl step.
Request 14280134 has been waiting in the processing queue for 6 seconds. Check that all databases are running properly!
That message is pretty definitive.
Discarding duplicate request from client dhcp port 67 - ID: 1381353109 due to unfinished request 14280311
Again, our database processes most request in less than 1 second and very seldom in 2 seconds but mentioned problem is persistent.
I'm not sure what else to say. FreeRADIUS can handle 50K requests/s all by itself. So if you're seeing responses delayed more than 20 microseconds, it's not FreeRADIUS. My guess is that it's a combination of (a) your database being slow, and (b) the Perl code not using the database efficiently. Alan DeKok.