On Fri, Aug 02, 2024 at 09:36:47AM -0300, Roberto Bartzen Acosta wrote: > Hey Felix, Frode, anyone else who might be interested. > > We have looked at your proposal Felix[1], thanks for bringing this > discussion up. We have been thinking about solutions to this problem for a > while, however, each alternative has its own implications and > implementation requirements.
Hi Roberto, there is now a new version that might fit your case a lot better: https://mail.openvswitch.org/pipermail/ovs-dev/2024-August/416263.html > > The most recent idea we are exploring would be to use multiple provider > networks (one for each DGP) and connect the DGPs to the "external" LRPs of > the routers. So, the North/South traffic would be balanced via ECMP between > the multiple DGPs but without a conntrack state for them... so we would > need to create stateless NAT rules to meet this requirement. I guess the multiple DGPs can be simplified with my proposal above. So the DGPs are still there in the background, but neutron would not need to know about them. Also the additional layer i have in my proposal prevents you from needing to add all these DGPs to all of your routers, you just need one per routing domain. Additionally it solves the MAC Address explosion you mention in the document. With your stateless NAT dnat_and_snat entries you should then already run through all gateway chassis in parallel. I guess the datapaths running on the compute chassis would be: <project LS> -> <project LR> -> <public LS> -> <public LR> -> redirect to gateway chassis. However the snat entries would still be centralized on the <project LR> single chassis as otherwise there is no way to reliably match connections. Alternatively if you also want this to run through multiple chassis you could go for multiple public snat IPs. > > This way, the changes on the OVN side are minimal, however on the CMS side > it increases complexity a lot... On the other hand, your proposal is very > interesting because it reduces the complexity on the CMS side but there are > open points. Our biggest concern is about the L2 domain in the > communication between the DGP router and the "leaf switches" using the same > MAC! considering that 4,8 or more gw chassis will be connected on the same > pair of switches, for example. With the above proposal you should no longer need any significant CMS changes. Additionally this same MAC issue is fixed with the new version. > > We will share with you some ideas and tests we carried out in the attached > document (Thanks Tiago Pires). > > Please feel free to send feedback and suggestions. Let me know what you think. Thanks Felix > > Kind regards, > Roberto > > [1] > https://github.com/ovn-org/ovn/compare/main...felixhuettner:ovn:test_active_active_routing > _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss