High-availability virtual-server not load balancing traffic

Bugs
1

This is with VyOS 1.5-rolling-202501110007. I’m trying to use high-availability virtual-server to balance HTTP traffic across multiple backends and it ends up sending 100% of the connections to a single backend unless I manually make changes via ipvsadm

Here’s the config:

virtual-server http {
     address 50.106.9.46
     algorithm weighted-round-robin
     delay-loop 1
     port 8080
     protocol tcp
     real-server 172.16.0.1 {
         port 80
     }
     real-server 172.16.0.2 {
         port 80
     }
     real-server 172.16.1.1 {
         port 80
     }
     real-server 172.16.1.2 {
         port 80
     }
     real-server 172.31.255.1 {
         connection-timeout 5
         port 80
     }
     real-server 172.31.255.2 {
         connection-timeout 5
         port 80
     }
 }

Running a load test from an external server with 256 open connections results in all of the traffic going to the same back end:

TCP  50.106.9.46:http-alt wrr
  -> 172.16.0.1:http              Masq    1      0          0
  -> 172.16.0.2:http              Masq    1      0          0
  -> 172.16.1.1:http              Masq    1      256        0
  -> 172.16.1.2:http              Masq    1      0          0
  -> scottstuff.net:http          Masq    1      0          0
  -> scottstuff.net:http          Masq    1      0          0

Exactly which backend gets the traffic varies from time to time, but it’s almost always a single backend. Changing the LB algorithm in VyOS doesn’t seem to matter.

However, manually changing the algorithm via ipvsadm and then changing it back makes future traffic balance correctly:

# ipvsadm -E -t 50.106.9.46:8080 -s rr
# ipvsadm -E -t 50.106.9.46:8080 -s wrr
... run test ...
TCP  50.106.9.46:http-alt wrr
  -> 172.16.0.1:http              Masq    1      42         0
  -> 172.16.0.2:http              Masq    1      43         0
  -> 172.16.1.1:http              Masq    1      43         256
  -> 172.16.1.2:http              Masq    1      42         0
  -> scottstuff.net:http          Masq    1      43         0
  -> scottstuff.net:http          Masq    1      43         0

I saw the same behavior with a nightly build from July and just upgraded, but still see the same basic problem even with the newest nightly.

2

Note that the slightly mis-matched connection-timeout settings are from adding additional backends to try to work around this problem; they don’t really seem to make any difference to the system’s behavior.