Hello, I don't see how my solution is broken by design. I see that
net.ipv4.ip_nonlocal_bind=1 is superior and widely used, so i'm using that happily. But i still believe there's a bug or misdocumentation somewhere in bind interface. Consider my setup: eth0: external ip address, used to ssh into the server eth1: internal ip address (10.0.1.10), will also recieve the virtual ip (10.0.1.9) from keepalived The server we look at is the backup server, so when haproxy starts, it doesn't have the VIP The server is configured to listen to all traffic on eth1 to a specific port (12340), so either traffic sent to its normal internal ip adress or to its VIP address, in case keepalived assigned it to us will result in haproxy receiving traffic on 12340. That's theory. In practice,, i've got the following problem: - Take the master server down, our server will now receive the virtual ip - portscan the virtual ip (nmap -p 12340 10.0.1.9) - expected: 12340 should be open, as the stats-page of haproxy shows the frontend is open - received result: 12340 is closed most of the time. Sometimes, it's open. Yes that's vague, but i have no idea on what it depends, as consecutive runs of nmap (~1s interval) show different states for the port. As the port is closed most of the time, haproxy with this configuation is unusable. The behauvior is thus also fully reproducible. We run haproxy with in debug+foreground mode, but the log shows nothing, neither for a portscan which results in an open port, nor for a closed port. Do you need more information? Cornelius Riemenschneider -- ITscope GmbH Ludwig-Erhard-Alle 20 76131 Karlsruhe Email: [email protected] https://www.itscope.com Handelsregister: AG Mannheim, HRB 232782 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Alexander Münkel, Benjamin Mund, Stefan Reger -----Original message----- To:Cornelius Riemenschneider <[email protected]>; [email protected]; From:Lukas Tribus <[email protected]> Sent:Mon 11-02-2013 19:08 Subject:RE: Problems with 1.5-dev17 and bind to interface > frontend nodes > maxconn 2400 > bind :12340 interface eth1 > default_backend nodes > > > but portscans from another node in the internal network show that 12340 is > sometimes open, but most of the it is closed. > > We believe this is a bug in haproxy. Probably haproxy starts when the VIP is not bound to the interface, and since haproxy only binds when starting the daemon, the bind behavior depends on your VIP status. I would strongly suggest to use hardcoded IP addresses in the bind line (+ net.ipv4.ip_nonlocal_bind=1) if you use virtual IP addresses (imho the configuration you are using is broken by design). > But nevertheless, bind interface seems to be buggy, isn't it? Well, you will need to be more specific and do some troubleshooting. "is sometimes open, but most of the it is closed" is more than vague. Does the "bind interface" configuration work as expected with normal, non-virtual IP addresses? Is the behavior reproducible depending on your VIP status when the haproxy daemon was started?
