On Fri, Jan 10, 2025 at 9:03 AM Evgenii Kovalev via discuss < ovs-discuss@openvswitch.org> wrote:
> Hi Team, > > I need some advice on using the LB in OVN as a distributed/decentralized > Load Balancer. > > I have a simple infrastructure on a single HV: > 1 LR with 3 LS: > 172.31.0.0/24 - for LB VIPs > 172.31.1.0/24 - for LB Backends > 172.31.2.0/24 - for the source client making requests to the LB > > The LB is added to the LR, and the LR doesn't have any DGW ports. > > Addresses: > LB: 172.31.0.100:200 (tcp) > Client: 172.31.2.4 (vm) > Backend: 172.31.1.4:10880 (vm) > > > When I tried to request the LB, I observed the following behavior at the > client interface: > 16:09:37.771981 IP 172.31.2.4.57820 > 172.31.0.100.200: Flags [S], seq > 719162884, win 29200, options [mss 1460,sackOK,TS val 8275435 ecr > 0,nop,wscale 7], length 0 > > 16:09:37.775229 IP 172.31.1.4.10880 > 172.31.2.4.57820: Flags [S.], seq > 4108291295, ack 719162885, win 28960, options [mss 1460,sackOK,TS val > 8332101 ecr 8275435,nop,wscale 7], length 0 > > 16:09:37.776244 IP 172.31.2.4.57820 > 172.31.1.4.10880: Flags [R], seq > 719162885, win 0, length 0 > > The SYNACK is coming from 172.31.1.4:10880, which is the original > backend address, and it hasn't been unDNATed. As expected, the client > sends an RST to the backend because it is waiting for traffic with the > source address 172.31.0.100, the Load Balancer VIP address. > This is expected. When the backend sends the reply, source IP is 172.31.1.4 and destination IP is - 172.31.2.4, the source IP - 172.31.1.4 is NOT undnatted to 172.31.0.100. That's because - logical flow to undnat is added in the egress pipeline of the router - but before that, in the ingress pipeline routing happens due to this logical flow table=14(lr_in_ip_routing ), priority=124 , match=(ip4.dst == 172.31.2.24), action=(ip.ttl--; reg8[0..15] = 0; reg0 = ip4.dst; reg5 = 172.31.2..1; eth.src = <LRP_MAC_connecting_to_172.31.2.0_logical_switch; outport = "router_port_connecting_to_172.31.2.0_ls> ; flags.loopback = 1; reg9[9] = 1; next;) Even if you have a DGW port in your router, you'd still see the same behavior. Only way to have it work is for you to associate this load balancer to all the 3 logical switches. Thanks Numan > I also observed different, where is zone 31 it's dnat_zone of LR and > zone 52 it's client interface. I guess, it could be a problem: > 1st event: > [NEW] tcp 6 120 SYN_SENT src=172.31.2.4 dst=172.31.0.100 > sport=57776 dport=200 [UNREPLIED] src=172.31.1.4 dst=172.31.2.4 > sport=10880 dport=57776 zone=31 > > 2nd event: > [NEW] tcp 6 120 SYN_SENT src=172.31.2.4 dst=172.31.0.100 > sport=57776 dport=200 [UNREPLIED] src=172.31.0.100 dst=172.31.2.4 > sport=200 dport=57776 zone=52 > > > So, in my view it should be work from "box" with single HV, but for > distributed LB it should be also work at source client HV, I mean > backend return origin traffic without unDNAT to HV where is located > client and after that check that is traffic as load balancing and make > unDNAT on client HV. > > The main question - is it possible to configure a scheme for > decentralized LB based on LR, or is it only possible if an accurate > > chassis is set? > > -- > Best regards, > Evgenii Kovalev > > _______________________________________________ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
