When HAProxy is already running, setting load-balancing haproxy vrf is accepted and the service is reloaded, but HAProxy stays in its old VRF. Listeners are opened outside the configured VRF, and clients in the VRF can't reach them.

Starting point: VRF V exists with eth1.66 (10.66.2.1/24) in it; HAProxy is running with a frontend on 10.66.1.1:2281 in the default VRF.

set load-balancing haproxy vrf V
set load-balancing haproxy backend BKV server s1 address 10.66.2.2
set load-balancing haproxy backend BKV server s1 port 8066
set load-balancing haproxy service S6 port 2276
set load-balancing haproxy service S6 backend BKV
(+ mode tcp)
commit        # accepted

$ sudo ss -ltnp | grep -E ':(2276|2281) '
LISTEN 0 4096 10.66.1.1:2281 0.0.0.0:* users:(("haproxy",pid=16285,fd=10))
LISTEN 0 4096         *:2276       : users:(("haproxy",pid=16285,fd=11))
$ echo haproxy-vrf=[$(ip vrf identify $(pgrep -o haproxy))]
haproxy-vrf=[]

The new frontend listens as *:2276 in the default VRF (not *%V:2276), HAProxy's main process is unchanged and not in VRF V, and a client in VRF V can't connect to 10.66.2.1:2276. After saving and rebooting, HAProxy starts in VRF V and serves correctly.

Cause: the VRF is applied only when the service starts (ip vrf exec <vrf> in the unit's start command), but on a config change HAProxy is reloaded, which keeps the running process in the VRF it started in. Other services handle this; NTP, for example, restarts instead of reloading when its VRF changes.

Expected: when load-balancing haproxy vrf is added, changed or removed, HAProxy is restarted so that it runs in the configured VRF.