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.