DHCP module and external DHCP relay

[Eugene Grosbein]

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