Hello Roobesh,
On Wed, 26 Dec 2018 at 11:49, Mohandass, Roobesh <[email protected]> wrote: > RGM: This is reproducible anywhere production/lab but when we see this > behavior is a questions > as I said out of so many large number of requests only for some we will > observe this behavior > (but can be caught very quickly in less than 30mins span of time). Thanks for clarifying. I don't have the time to reproduce this today, but could you try the attached patch please? It changes the logic around those calls, uses the getsockopt/SO_ORIGINAL_DST first, checks the return value and then calls getsockname(). Previously we did not check the return value of the getsockopt/SO_ORIGINAL_DST. My hope is that that call returns an error when it returns wrong data - if that's the case, the patch should fix the issue without sacrificing other haproxy features. If that doesn't fix the problem we probably have to talk to the kernel/netfilter folks. Thanks, Lukas
1.8-SO_ORIGINAL_DST-change.diff
Description: Binary data
