Hi Felix, Em seg., 5 de ago. de 2024 às 10:07, Felix Huettner <felix.huettner@mail.schwarz> escreveu:
> 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 I saw it, it's a great proposal. Thanks! > > > > > 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. > Sure, this really simplifies the CMS part !. I need to look into migrating existing provider networks to a more pluggable adaptation using an additional router/network layer but this is not a big problem. The important thing is to be able to distribute traffic in a balanced way to multiple chassis (for FIPs using dnat_and_snat NAT entries). > > 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 part of SNAT worries me a lot considering that snat in the case of a router running in a cloud environment is the most significant part of traffic - as workloads tend to use more egress to the internet than ingress (dnat_and_snat). So, not being able to balance snat becomes a very bad thing IMO. Of course, if a workload has a FIP this would not be a problem but large workloads use solutions like a kubernetes cluster (control and worker nodes without public IPs). Well, if k8s uses a load balancer with a public IP (FIP) the fact of snat becomes irrelevant here too and dnat_and_snat can solve it. That said, I can't see a major impediment to the snat case at this point. Maybe someone else can help here with use cases that could be impacted by having centralized SNAT. Thanks, Roberto > > > > 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 > > > -- _‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho inicial. Se você não está listado nos endereços constantes no cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão imediatamente anuladas e proibidas’._ * **‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
