Hi, On 6/9/25 22:45, Maciej Zdeb wrote: > Hi, > I have HAProxy 3.0.8 running on a system with two network interfaces (eno1 > 1.2.3.4 and eno2 10.0.10.10). > > The default route is on eno1. > More specific route to 10.0.0.0/8 is on eno2 - this is used for dns > resolution in HAProxy. > > When the eno2 interface goes down (e.g. port on the network switch is > disabled) then HAProxy tries to do hostname resolution by sending requests > through eno1, which is expected as the more specific route is not available > anymore. > > The issue is that when eno2 port is UP and running again, HAProxy still > tries to resolve hostnames through eno1.
When eno2 port is UP again, is the more general route (through eno1) still available? If yes then it is expected that haproxy still uses the previously working route, it will not re-attempt to connect if the existing socket still works > > It looks like HAProxy is creating a UDP socket once and is recreated only > when: > - HAProxy is reloaded > - the network interface state is changed. haproxy considers the socket is not usable anymore if the send() fails and the error is not retryable. In this case a new socket should be re-created on next attempt. > > The issue is pretty nasty, because after 100 retries (HAPoxy reports DNS > timeout which are expected) on eno1 HAProxy is giving up and it never goes > back to using the proper eno2 interface. I don't understand, so the switch from eno1 to eno2 (when eno2 becomes unavailable) would work, but not the switch from eno1 to eno2 (when eno1 becomes unavailable)? Aurelien
