Disable multiple bindings on same port

Hi all,

I recently discovered it is possible to have multiple front-ends which bind to the same ip/port combination. I was surprised to find this was even possible - I would have expected an error on start-up in this scenario. I see from some discussion here is that the likely behaviour is that traffic will be (non deterministically?) distributed between the front-ends by the kernel.

Not sure why this behaviour is even allowed, why would ever want to do this. Wondering if this less of a deliberate behaviour and more of a side effect of the way multi threaded/multi process mode works?

In any case, my key question is whether these is any way to disable this and/or force a validation error on start-up in such a situation? The reason I ask is that we generate our config automatically from other sources and the process can sometime introduce such a situation, leading to unpredictable behaviour. It would preferable if this just failed. If no other option we will just update our config generation processes to validate for this!




Add the configuration directive noreuseport to your global section.

The SO_REUSEPORT socket setting is necessary for some of the features related to process reloads.

Hi Lukas, thanks for the quick response! Makes sense, I figured it was something like that. I don’t think that option would be a good one in my case, as I also make a lot of use of the process reload features.

Out of curiosity, would you agree that there is no sensible use case for explicitly binding the same port twice within config - i.e. it should only be used within the internals of the haproxy for reload etc as you mentioned? If so, perhaps such config should cause a config validation failure?


No, I would not agree.

You may want to specify different cores or threads on a particular socket, and have the kernel load balance between the two.

Some config validation heuristic is of course possible to improve the situation, but I do not believe anyone is actively working on this at this point.

Thanks again - good to understand this in morn detail. Appreciate you taking the time to respond!

For example, I do not see any use-case of binding to the same port in different frontends, I agree this should cause configuration warnings or alerts. But then again, we need to be aware that the user can bind to different IP addresses, which is perfectly valid and actually very common.

Implementing such a heuristic in the configuration checker is error prone.