On 2/13/26 10:37 AM, Rukomoinikova Aleksandra wrote: > On 11.02.2026 17:22, Alexandra Rukomoinikova wrote: >> On 11.02.2026 17:11, Dumitru Ceara wrote: >>> On 2/9/26 3:06 PM, Ales Musil via dev wrote: >>>> On Wed, Feb 4, 2026 at 12:08 PM Alexandra Rukomoinikova >>>> <[email protected]> wrote: >>>> >>>>> 1) Added new option "distributed" for load balancers. >>>>> With this feature, balancers will work distributedly across compute >>>>> nodes, >>>>> balancing to only local backends (excluded east-west traffic) >>>>> >>>>> 2) If load balancer is running on a router with dgp, the router will no >>>>> longer be centralized on gateway - this means that access to physical >>>>> network will also be available from hosts where the distributed balancer >>>>> backends are located. >>>>> >>>>> 3) Configuration requirement for distributed load balancers: >>>>> 1) ip_port_mapping must be specified >>>>> 2) Balancing in underlay fabric between hosts with backends >>>>> >>>>> Example: >>>>> Load Balancer: lb1 with VIP 1.1.1.1 and distributed option enabled. >>>>> Fabric is configured with a static ECMP route for 10.255.0.1/32: >>>>> nexthop via ip_host1 weight 1 (hosts backend1) >>>>> nexthop via ip_host2 weight 1 (hosts backend2) >>>>> nexthop via ip_host3 weight 2 (hosts backend3 and backend4) >>>>> >>>>> As part of testing, following estimates of distribution of requests to >>>>> balancers were obtained: >>>>> for i in $(seq 5000); do curlhttp://10.255.0.1:80 2>/dev/null ; echo ; >>>>> done | awk '{print $2}' | sort | uniq -c >>>>> 1265 “backend 4", >>>>> 1260 “backend 3", >>>>> 1224 “backend 2", >>>>> 1251 “backend 1", >>>>> Thus, requests using ecmp balancing are distributed between backends >>>>> approximately evenly. >>>>> >>>>> Suggested-by: Vladislav Odintsov<[email protected]> >>>>> Signed-off-by: Alexandra Rukomoinikova<[email protected]> >>>>> -- >>>>> v6 --> v7: fixed Ales comments >>>>> --- >>>>> >>>> Hi Alexandra, >>>> >>>> thank you for v7. I have some small nits down below. >>>> >>>> >>>> >>> [...] >>>> I took care of the nits and merged this into main. >>>> >>>> Regards, >>>> Ales >>> Hi Alexandra, Ales, >>> >>> I didn't check in too much depth but it seems that this patch is causing >>> the following multinode test to fail: >>> >>> 14: ovn multinode load-balancer with multiple DGPs and multiple chassis >>> - ECMP environment FAILED (ovs-macros.at:258) >>> >>> It seems all runs since this patch have been red: >>> https://github.com/ovn-org/ovn/actions/workflows/ovn-fake-multinode-tests.yml >>> >>> I did a quick test with this patch reverted and the test passed 1st try >>> in my fork: >>> >>> https://github.com/dceara/ovn/actions/runs/21906624033/attempts/1 >>> >>> While I'm doing some more runs, would you have time by any chance to >>> look into it? >>> >>> Thanks, >>> Dumitru >>> >> Hi! Oh, sorry for one more problem..... I didn't run all the multinode >> tests before sending it, only mine, my fail. Yes, I'll take a look and >> fix everything ASAP >> >> -- >> regards, >> Alexandra. > > Hi! Sorry this test is still red. I honestly haven't figured out what > the problem is yet, it's a strange and non-obvious issue, at least for > me. I hope I'll figure it out by Monday and send a patch. I'm just a > little worried about red tests on GitHub, I hope it's not that critical. >
Hi Alexandra, Thanks for working on this! It's not great if we have perma-failing tests but on the other hand it's also not critical (yet). This problem is only on the main branch and we have another 5 weeks (1 week of soft freeze + 4 weeks after branching) to figure out what's causing this test to fail. Once again, thanks for looking into this! Please let me know if you get stuck, I can try to help. Regards, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
