Hi Alan, Thanks for the quick response and sorry for the delay in writing back. I've tested with the increased buffer sizes(in dhcp.relay server and also linux kernel) as below(25 MB) and still the result is same, couldn't go beyond 2000-2500 4 way transactions (CPU of all the cores on my relay server is fully occupied, which I've missed mentioning in the initial mail). # sysctl net.core.wmem_max net.core.wmem_max = 26214400 # sysctl net.core.wmem_default net.core.wmem_default = 26214400 # sysctl net.core.rmem_max net.core.rmem_max = 26214400 # sysctl net.core.rmem_default net.core.rmem_default = 26214400 server dhcp.eth1 { listen { ipaddr = * port = 67 type = dhcp interface = eth1 recv_buff = 26214400 Please advise on further steps/enhancements. Thanks in advance, Vikram. -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+vikram.katuri=viasat.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Thursday, March 28, 2019 4:56 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Chinnapaiyan, Nagamani <Nagamani.Chinnapaiyan@viasat.com>; Munhall, Damon <Damon.Munhall@viasat.com> Subject: Re: seeking info on max.rate supported by dhcp.relay in v3.0.0.19 On Mar 28, 2019, at 7:19 AM, Katuri, Vikram <Vikram.Katuri@viasat.com> wrote:
May I please know the max.supported rate for dhcp.relay(with load balancing) in version 3.0.19.
There is no pre-set limit on the rate of DHCP relay. It depends on the OS, CPU, etc.
I see its getting capped at 5000 incoming discovers and only 2500 of them are able to complete the 4 way DORA(via dhcp.relay). 3700 with discover and request alone handled by the dhcp.relay and request and ack directly sent by the dhcp server to the client bypassing the relay(by not filling in the gateway address, server sends to the ciaddr). Setup details: 5 clients running perfdhcp each trying dhcp transactions at a rate of 1000/sec. Dhcp.relay on v3.0.19 running on c4.2xlarge instance (8 CPUs) on AWS cloud, 3 v4 dhcp servers behind it running on t2.medium instances on AWS cloud.
That seems a bit low. I've tested v3 at 20K packets/s for RADIUS proxying. One thing you may try changing is the "recv_buff" setting in the listener. See sites-available/default for an example. The same setting should work for DHCP, too. The default kernel receive buffer size is set very low. If you increase it, UDP performance can go up significantly. Alan DeKok. - List info/subscribe/unsubscribe? See https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeradius.org_list_...