This totally breaks remote console access for me on 1.2.6, FWIW, so I consider it a fairly serious bug.

Any chance of motion on this?

What's the probability of seeing a 1.1.9 release sometime soon with this fix in it? I have a bunch of machines I'd like to upgrade to 1.1.8+, but it seems irritating to have to manually install an updated .deb on each of them.

Do you want me to add it to T403 or make a new ticket?

virtual_ipaddress_excluded is basically a list of lines that keepalived passes to ip addr add / ip addr del when the main VRRP state changes. Typically, it's used to manage more than 20 addresses with keepalived (only the first 20 go in virtual_ipaddress, which is in the actual VRRP packet; the rest are failed over through this out-of-band configuration). According to that thread (and past experience), it should work for this case.

If I make a patch to use virtual_ipaddress_excluded, do you prefer an arcanist diff or a github pull request?

Oh man, that's going to be a disaster for all the companies out there relying on mixed v4/v6 blocks (which is extremely common in v6 setups).

Also, here's the config that I'm running on my VyOS test VMs (with R33:5bccce5948cc44e76f8c9da93f1a1cf8f1212bca ):

Try it with vrrp_version 2; I believe that will work. It seems to default to standards-compliant behavior (that is to say, no mixed-virtual-addresses) in v3. Not sure if there's a way to turn that off or not. Here's what the config at my current employer looks like

We need extra VRRP instances for IPv4 and IPv6, keepalived can only have virtual_addresses of the instances native address family.