Hi Willy, Thanks for the information. Actually, our UDP traffic are radius requests to be forwarded to 1812, and 1813 UDP ports. we need to load balance these requests. Can we load balance these UDP requests?
Best Regards, Shehan Jayawardane Head of Engineering sheh...@nvision.lk www.thryvz.com<http://www.thryvz.com/> [cid:fb31532f-27cb-4f27-8464-61339a52893d] ________________________________ From: Willy Tarreau <w...@1wt.eu> Sent: 02 January 2025 17:27 To: Shehan Jayawardane <sheh...@nvision.lk> Cc: Joshua Turnbull <jos...@loadbalancer.org>; haproxy@formilux.org <haproxy@formilux.org>; Dev Ops <dev...@nvision.lk>; Sathiska Udayanga <sathi...@nvision.lk> Subject: Re: HAproxy load balancing query Hi Shehan, On Thu, Jan 02, 2025 at 11:25:25AM +0000, Shehan Jayawardane wrote: > Hi Willy, > > Good day to you. > After long time I'm requesting this query as well. > with HA proxy are we able to load balance udp traffic? There isn't such a thing as "udp traffic" but there are udp-based services and that makes a huge difference. Haproxy supports load-balancing syslog messages that it can receive over udp/tcp and send to udp/tcp, possibly even completing them (e.g. prepend the source address). For the rest, you'll almost always need service-specific handling since some services are message-based, others connection-based, uni- or bi- directional. Most services depend on the source address being joinable by the server, or may alter the behavior based on the source IP address (e.g. syslog, dns if using zones/geoip). There are already a number of dedicated proxies for various UDP-based services, which will always do the job better than a generic proxy. For example, for syslog, a tool such as rsyslog will be able to use the RELP protocol for reliable delivery and even to queue messages to avoid losses. For DNS there's dnsdist etc. For completeness, there's a module dealing with all these particularities in as much a generic way as possible in the haproxy enterprise packages, and I'm personally glad I don't have to maintain that because it's very far away from haproxy's scope. For more details and background on all of this, and some of the technical challenges, I invite you to read the discussion in this issue: https://github.com/haproxy/haproxy/issues/62 Hoping this helps, Willy
