On Sat, May 07, 2022 at 09:11:30AM -0600, Shawn Heisey wrote: > If you look closely at the tcpdump output, you'll notice that when haproxy > replies, it replies from the actual IP address of the machine (.200) rather > than the ucarp VIP (.170) where it received the request. Is this something > that can be fixed?
Oh that's an excellent point! I remember having faced that in the past on other services (e.g. DNS). That's why most UDP-based services require that you enforce the exact address on the interface (e.g. 10.2.3.4 instead of 0.0.0.0). There's no good solution to this, except by forcing the exact address yourself. The BSD socket API doesn't permit to send UDP packets from a specific source, so the commonly used approach for clients is to bind while sending the first packet, but that doesn't work for a server that faces many clients, as it would restrict the traffic to the first IP used. Note that in order for the two haproxy nodes to bind to the virtual address you'll likely have to enable ip_nonlocal_bind, but I guess you already have it. I think that for the short term we could forbid binding on 0.0.0.0 but that would annoy most users by complicating config deployments. Thus maybe the best we can do is document this limitation. Thanks for reporting this! Willy
