<div dir="ltr">Hi all,<div><br></div><div>Based on some problems that we've detected at scale, I've been doing an analysis of how logical flows are distributed on a system which makes heavy use of Floating IPs (dnat_and_snat NAT entries) and DVR.</div><div><br></div><div>[root@central ~]# ovn-nbctl list NAT|grep dnat_and_snat -c<br>985<br></div><div><br></div><div>With 985 Floating IPs (and ~1.2K ACLs), I can see that 680K logical flows are generated. This is creating a terribly stress everywhere (ovsdb-server, ovn-northd, ovn-controller) especially upon reconnection of ovn-controllers to the SB database which have to read ~0.7 million of logical flows and process them:</div><div><br></div><div>[root@central ~]# time ovn-sbctl list logical_flow > logical_flows.txt<br>real    1m17.465s<br>user    0m41.916s<br>sys     0m1.996s<br></div><div>[root@central ~]# grep _uuid logical_flows.txt -c<br>680276<br></div><div><br></div><div>The problem is even worse when a lot of clients are simultaneously reading the dump from the SB DB server (this could be certainly alleviated by using RAFT but we're not there yet) causing even OOM killers on ovsdb-server/ovn-northd and a severe delay of the control plane to be operational again.</div><div> </div><div>I have investigated a little bit the lflows generated and their distribution per stage finding that 62.2% are in the lr_out_egr_loop and 31.1% are in the lr_in_ip_routing stage:</div><div><br></div><div>[root@central ~]# head -n 10 logical_flows_distribution_sorted.txt<br>lr_out_egr_loop: 423414  62.24%<br>lr_in_ip_routing: 212199  31.19%<br>lr_in_ip_input: 10831  1.59%<br>ls_out_acl: 4831  0.71%<br>ls_in_port_sec_ip: 3471  0.51%<br>ls_in_l2_lkup: 2360  0.34%<br></div><div>....</div><div><br></div><div>Tackling first the lflows in lr_out_egr_loop I can see that there are mainly two lflow types:</div><div><br></div><div>1)</div><div><br>external_ids        : {source="ovn-northd.c:8807", stage-name=lr_out_egr_loop}<br>logical_datapath    : 261206d2-72c5-4e79-ae5c-669e6ee4e71a<br>match               : "ip4.src == 10.142.140.39 && ip4.dst == 10.142.140.112"<br>pipeline            : egress<br>priority            : 200<br>table_id            : 2<br>hash                : 0<br></div><div><br></div><div>2)</div><div>actions             : "inport = outport; outport = \"\"; flags = 0; flags.loopback = 1; reg9[1] = 1; next(pipeline=ingress, table=0); "<br>external_ids        : {source="ovn-northd.c:8799", stage-name=lr_out_egr_loop}<br>logical_datapath    : 161206d2-72c5-4e79-ae5c-669e6ee4e71a<br>match               : "is_chassis_resident(\"42f64a6c-a52d-4712-8c56-876e8fb30c03\") && ip4.src == 10.142.140.39 && ip4.dst == 10.142.141.19"<br></div><div>pipeline            : egress<br>priority            : 300<br></div><div><br></div><div>Looks like these lflows are added by this commit:</div><div><a href="https://github.com/ovn-org/ovn/commit/551e3d989557bd2249d5bbe0978b44b775c5e619">https://github.com/ovn-org/ovn/commit/551e3d989557bd2249d5bbe0978b44b775c5e619</a><br></div><div><br></div><div><br></div><div>And each Floating IP contributes to ~1.2K lflows (of course this grows as the number of FIPs grow):</div><div><br></div><div>[root@central ~]# grep 10.142.140.39  lr_out_egr_loop.txt |grep match  -c<br>1233<br></div><div><br></div><div>Similarly, for the lr_in_ip_routing stage, we find the same pattern:</div><div><br></div><div>1)</div><div>actions             : "outport = \"lrp-d2d745f5-91f0-4626-81c0-715c63d35716\"; eth.src = fa:16:3e:22:02:29; eth.dst = fa:16:5e:6f:36:e4; reg0 = ip4.dst; reg1 = 10.142.143.147; reg9[2] = 1; reg9[0] = 0; next;"<br>external_ids        : {source="ovn-northd.c:6782", stage-name=lr_in_ip_routing}<br>logical_datapath    : 161206d2-72c5-4e79-ae5c-669e6ee4e71a<br>match               : "inport == \"lrp-09f7eba5-54b7-48f4-9820-80423b65c608\" && ip4.src == 10.1.0.170 && ip4.dst == 10.142.140.39"<br></div><div>pipeline            : ingress<br>priority            : 400<br></div><div><br></div><div>Looks like these last flows are added by this commit:</div><div><a href="https://github.com/ovn-org/ovn/commit/8244c6b6bd8802a018e4ec3d3665510ebb16a9c7">https://github.com/ovn-org/ovn/commit/8244c6b6bd8802a018e4ec3d3665510ebb16a9c7</a><br></div><div><br></div><div>Each FIP contributes to 599 LFlows in this stage:</div><div><br></div><div>[root@central ~]# grep -c 10.142.140.39  lr_in_ip_routing.txt<br>599<br></div><div>[root@central ~]# grep -c 10.142.140.185  lr_in_ip_routing.txt<br>599<br></div><div><br></div><div>In order to figure out the relationship between the # of FIPs and the lflows, I removed a few of them and still the % of lflows in both stages remain constant.</div><div><br></div><div><br></div><div>[root@central ~]# ovn-nbctl find NAT type=dnat_and_snat | grep -c  _uuid<br>833<br></div><div><br></div><div>[root@central ~]# grep _uuid logical_flows_2.txt -c<br>611640<br></div><div><br></div><div>lr_out_egr_loop: 379740  62.08%<br>lr_in_ip_routing: 190295   31.11%<br></div><div><br></div><div><br></div><div>I'd like to gather feedback around the mentioned commits to see if there's a way we can avoid to insert those lflows or somehow offload the calculation to ovn-controller on the chassis where the logical port is bound to. This way we'll avoid stress on ovsdb-server and ovn-northd.</div><div><br></div><div>Any thoughts?</div><div><br></div><div>Thanks,</div><div>Daniel</div></div>