DHCP module and external DHCP relay

[Alan DeKok]

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.