Haproxy load-balancing VIP address

General questions
1

I’m trying to define haproxy load-balancing rules for a MariaDB cluster, but I’m running into an issue with defining the VIP address (listen-address).

[edit]
vyos@srvr2-fw# commit
[ load-balancing haproxy ]
listen-address "172.18.10.99" not assigned on any interface!
[[load-balancing haproxy]] failed
Commit failed

Off course it is not assigned, it is a virtual address.

I have defined

set system sysctl parameter net.ipv4.ip_nonlocal_bind value 1

so I don’t have to, but appearently the CLI checks for an existing interface address?

How do I work around this limitation?

2

Issue is similar to ⚓ T4992 Incorrect check is_local_address for bgp neighbor with option ip_nonlocal_bind set

3

And another issue, I can’t seem to delete the haproxy config I created:

vyos@srvr2-fw:~$ configure 
[edit]
vyos@srvr2-fw# delete load-balancing haproxy backend REF_PACLOAHTTPTODATAB 
[edit]
vyos@srvr2-fw# delete load-balancing haproxy service REF_PACLOAHTTPTODATAB 
[edit]
vyos@esrv2-fw# commit
[ load-balancing haproxy ]
Both "service" and "backend" must be configured!
[[load-balancing haproxy]] failed
Commit failed

Uh?

4

Another issue, with this config:

set load-balancing haproxy service REF_PACLOAMYSQLTOINTER mode tcp
set load-balancing haproxy service REF_PACLOAMYSQLTOINTER port 3306
set load-balancing haproxy service REF_PACLOAMYSQLTOINTER backend REF_PACLOAMYSQLTOINTER
set load-balancing haproxy service REF_PACLOAMYSQLTOINTER listen-address 78.xxx.xxx.xxx
set load-balancing haproxy service REF_PACLOAMYSQLTOINTER listen-address 2001:1b40:4000:xxx:xxx:xxx:xxx

I get a “commit failed” saying that port 3306 on IP 2001:1b40:4000:xxx:xxx:xxx:xxx is already used. Which is not true, does it fail to see that this is a dual-stack interface with both an IPv4 and IPv6 listener?

5

Regarding config deletion: you are supposed to either clear the whole haproxy section, or leave some dummy backend/service entries behind. I.e. just run delete load-balancing haproxy if you don’t have any other haproxy configurations active.

I can’t help you with the other issues unfortunately.

6

Yeah, I’ve figured that after I did a compare.

As to the other issue: for some reason linux does not allow a bind on an IPv6 address if the associated interface is down, although it has no issue with an IPv4 bind on the same interface.
I found this out after I noticed everything I have running failed to bind on IPv6. The issue disappeared when I connected the interface to a dummy VLAN (as I have a live config running, but don’t want to go live yet).

7

p.s. For others finding this topic: I’ve worked around the CLI shortcomings by creating a dummy haproxy config (so VyOS starts haproxy on boot), and then created my own haproxy.cfg in /config, which is copied to /var/run/haproxy on boot in the boot post-config script (which also does a reload-or-restart to activate that config).

I found it a bit silly to install haproxy in a container as a workaround, knowing haproxy is already available in VyOS.

8

Please file this over at https://vyos.dev

9

What do you mean by “this”? The fact the CLI checks the listen IP address?

10

Im thinking above if there isnt some sysctl that perhaps should be set by default in VyOS to get the same behaviour between IPv4 and IPv6 service?

Or if this is a syntaxthingy for IPv6 services like listenaddress should be %ethX or such to bind it even if the interface is down instead of the IPv6 address itself or such?