DHCP module and external DHCP relay

[Alan DeKok]

Eugene Grosbein wrote:
> 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.

  Which re-implements a lot of the code in the server core.

  Re-inventing the wheel is a lot of work.  Sometimes you can make a
mistake.

> 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.

  <shrug>  The default configuration can assign 10K IP addresses per
second from the "mac2ip" module.  So the problem isn't FreeRADIUS.  It's
your local changes.

  Also, having hundreds of threads is a problem.  You shouldn't need
that many.

> 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.

  I don't see how that's a problem.  The DHCP code doesn't use client
definitions.  The server core doesn't queue requests by client.

> 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.

  So... what, FreeRADIUS does *nothing* with the packets for 6 seconds?
 That doesn't make sense.

  When the server receives a packet, the packet gets put onto a queue.
The queue is ordered, so first-in, first-out.  The queue doesn't care
whether the packet is RADIUS, DHCP, VMPS, or which client the packet
came from.

  When a thread is done with one request, it pulls the next one from the
queue.  Again, the thread doesn't care what kind of packet it is, or
which client it came from.

  The ONLY reason for the server to block is if all threads are
unresponsive.  The ONLY reason that the threads become unresponsive is
if they're doing some non-default action... which blocks the server.

> 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.

  It's not doing duplicate checks.  It DOES do queueing, because that's
how the server works.  The DHCP code does NOT look at Option 82.  The
DHCP code does NOT do any queuing of DHCP packets.

  Honestly, if you're going to re-implement everything in Perl, you're
probably better off writing your own DHCP server in Perl.

> 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.

  The DHCP module does NOT do that.  I have no idea why you think it does.

  The server does NOT work how you think.  I can't emphasize this
enough.  There is no magic queuing of packets for 6 seconds.  There are
no "DHCP clients".  There is no special treatment of packets with Option 82

  The ONLY reason FreeRADIUS is taking 6 seconds to respond is that YOU
changed the configuration.

  Honestly, try using the "mac2ip" module.  Pull the MACs and IPs from
your database. and put them into the mac2ip file.  Configure the mac2ip
module, and disable your Perl script.

  You will see that the response time of FreeRADIUS drop to 40ms or so.
 It will be able to do about 10K DHCP packets per second.

  I don't know how else to explain this.  Your Perl script is causing
the problem.

  Alan DeKok.