Hi everyone, i justed wanted to share a update on what happened in the last two months.
On Mon, Aug 05, 2024 at 12:08:33PM +0200, Felix Huettner via dev wrote: > Hi everyone, > > i now have a new and completely different version built based on the > learnings from the last one and internal discussions. > > The code builds upon Numans patch for centralized routing of dgp: > https://patchwork.ozlabs.org/project/ovn/patch/[email protected]/ > It is available here: > https://github.com/ovn-org/ovn/compare/main...felixhuettner:ovn:test_active_active_routing_v3?expand=1 > (Yes it is named v3, don't ask about v2). > Only the last 5 patches are actually specific to this change. All > previous ones are cleanups to make this work. The new version is available here: https://github.com/felixhuettner/ovn/commits/test_active_active_routing_v4 with the OVS repo needed being here: https://github.com/felixhuettner/ovs/commits/test_active_active_routing_v4 There are now changes to the ovs repo as i decided that it is easier to change so netlink clients directly there then to copy paste them to ovn. I am aware that the history is quite messy and this will be my focus for the future. > > The chassis setup itself is the same as above. > The new OVN Northbound content now is: > * a normal neutron project setup with a (same as above): > * LSP for a VM (LSP-VM) > * LS for the network (LS-internal) > * LR for the router (R1) > * LSP to the router (LSP-internal-R1) > * LRP to the network (LRP-R1-internal) > * a nat rule on R1 representing a floating ip > * The router R1 has an LRP (LRP-R1-public) with a ha_chassis_group > configured to point to both gateways with different priorities (same > as above) > * We now have an integration LS (public) which is just a normal logical > switch. This is the neutron external network > * LS public has a LSP (LSP-public-R1) that connects to LRP-R1-public > * There is a LR (magic-router) > * LR magic-router is connected via a normal LSP/LRP combination with LS > public > * There is a logical switch (LS-public-for-real) > * LS-public-for-real has a LSP (physnet) of type localnet and > network_name set to "phys" > * LS-public-for-real has a LSP (LSP-public-for-real-magic-router) > * LR public has an LRP (LRP-magic-router-public-for-real). It has set: > * an ha_chassis_group set to point to both gateway chassis is the > same or different priorities > * mac set to "active-active" > * networks set to "[active-active]" > * option:active-active-lrp=true > * LSP-public-for-real-magic-router and LRP-magic-router-public-for-real are > connected > > Additionally on local ovsdb of gtw01 we have configured: > * ovn-aa-port-mappings="phys;00:fe:fe:fe:fe:01,172.16.0.10/25" > * ovn-bridge-mappings="phys:physnet" > > Additionally on local ovsdb of gtw02 we have configured: > * ovn-aa-port-mappings="phys;00:fe:fe:fe:fe:11,172.16.0.139/25" > * ovn-bridge-mappings="phys:physnet" > > The magic that makes this setup then working comes from: > 1. Numans patch for centralized routing which i patched to not need a > setting anymore > 2. Logic in northd to generate dervied Port Bindings for > LSP-public-for-real-magic-router and LRP-magic-router-public-for-real > for each entry in ovn-aa-port-mappings if the port is an > active-active-lrp > > As a result this behaves very similar to the implementation of Frode in > https://mail.openvswitch.org/pipermail/ovs-dev/2024-July/415343.html > The major change is that there is no need to specify all ports in the > northbound. This allows chasis specific settings to be configured on the > chassis itself, instead of configuring it via northbound. > > The setting has the format "<network_name>;<mac>,<ip>;<mac>,<ip>". > It thereby allows multiple ports for a single network per chassis. OVN > will generate multiple LRPs for this. However they are connected to the > same localnet port, so to the same external bridge. It is up to the user > to then split them out to real phyiscal ports. > > The above also means that this feature should work extremely well with > existing CMS like neutron. There are just a few things that would need > changes in comparison to a normal neutron setup: > 1. The external network needs to be switched out for a new overlay-only > network with an additional router behind it. This should be easily > doable, it is just not common at the moment. > 2. Setting the option:active-active-lrp=true on the > LRP-magic-router-public-for-real > 3. Setting the ovn-aa-port-mappings > > This means that such active-active routing should be quite easily > adaptable for existing deployments (in comparison to all others). > > ## Improvements over the previous version > > * Matches more closely what a general public cloud deployment looks like > today and what existing neutron can do > * There is no need anymore for the external mac and ip addresses to be > identical everywhere > * Multiple external ports per chassis can be handled but are not yet > nice. They require additional flows on the external bridge > * The routes for each external port can be different. This also allows > users to disable external traffic on a gateway chassis while still > using it for ovn internal traffic. > * Uses more existing logic on the individual chassis. This is mostly a > northd change. * support for bgp redirects on active-active ports * support for announcing routes in vrfs and network namespaces (partially based on Frodes patches) * support for learning routes in vrfs and network namespaces * support to announce host routes with different prios based on the location of the lrp > > ## Current Limitations > > * It breaks some testcases. I did not investigate them yet > * It definately broke incremental processing as i did not add anything > there some parts are implemented, but probably stuff is still missing > * Routing is not yet dynamic between the magic-router and the physical > world. I wanted to test Martin and Frodes changes for this this is done now > * Communication between all LRs connected to LS public need manual > routes to be set everywhere (if you do not do nat) > Also thanks a lot to rbartzen for testing (and fixing) these patches already. My plans for now are to do start cleaning up the changes and then send out a very first version to the mailing list. Thanks Felix _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
