On 04.04.2014 20:04, Alan DeKok wrote:
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.
There is more logic in my perl script. It keeps pool of persistent connections to database, restarts them if they fail and fallbacks to local indexed storage if database does not respond at all.
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.
Generally, response time is much less than 1 second.
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.
You missed the point. Perl script and database process request pretty fast and I have hundreds of free threads in the rlm_perl's pool. But FreeRADIUS dhcp module thinks that all requests from the same source are request from single client. This is plain wrong in case of DHCP relay in between DHCP clients and FreeRADIUS that is located in an isolated vlan. So, FreeRADIUS queues requests and does not pass them to rlm_perl instantly as it should. 6 seconds is delay between DHCP request arrival to the box via network interface and invoke of post_auth perl function. Basically, I'd like dhcp module running mode in which it would pass ALL requests to rlm_perl without duplicate checks and queueing as I perform thread-safe in-memory caching of results distinguishing cliens using DHCP Option 82 details. Or, another mode of dhcp module in which it would be able to check existance of the Option 82 in the request and use it to no treat requests from distinct clients as coming from single source. Something like that. Eugene Grosbein