On 12/18/24 4:54 PM, Felix Huettner via dev wrote: > Hi everyone, > Hi Felix,
> this is the active-active part of the OVN Fabric integration series > https://mail.openvswitch.org/pipermail/ovs-dev/2024-November/418554.html. > > This is separate from the other northd and ovn-controller series about > route advertisement and learning. > The goal of this series is rather to allow users to easily setup an > architecture that allows for a deep routing integration into the fabric. > > Additionally the information we learn using this integration allows us > to improve the routing of packets in OVN. > > --- > > The feature is intended to be used in deployments that have multiple > gateway chassis, potentially with multiple nics, connected to one > external network. > The users could then configure point-to-point links with BGP from their > network fabric to each of the nics. They would then be plugged into an > OVS bridge which is mapped using ovn-bridge-mappings. It can then be > mapped to the overlay with a LS (physnet) and a localnet port. > > Now instead of the CMS directly using the LS physnet to connect e.g. VMs > or Router we introduce another layer. > > The LS physnet will be connected to an LR (fabricrouter) which is connected to > another LS (e.g. my-net-for-cms). The CMS would then use the "my-net-for-cms" > LS as "external" network instead of LS physnet. > > The LR fabricrouter will then be connected via individual LRPs to each > of the fabric switches outside of OVN. The LRPs is bound to the > appropriate gateway chassis where the nic actually resides. The > routing-protocol-redirect as well as the Route learning/advertising features > of the other parts of this patchset can then be used to integrate to the > fabric > from a routing perspective. > > The LR fabricrouter has one other LRP towards the LS "my-net-for-cms". > It effectively takes the previous position of the fabric switches on > this LS. > > The previously mentioned individual LRPs on LR fabricrouter for each nic > are needed so that we get accurate routing information to and from the > fabric. It allows us to install separate default routes for the LR via > each of the nics. This means that e.g. a single nic failure will > directly impact the routing decission taken by the LR. > This mirrors the logic of phyiscal routers and switches that learn ECMP > routes. > Also this means that a route in the OVN overlay will actually be > propagated from each of the nics. This allows the fabric to do ECMP. > > --- > > To now get to the main goal of this patchset: > The ip and mac setting on each of the LRPs of fabricrouter that are > connected to the nics must be in sync with the configuration and routing > daemons running on the gateway chassis hosting the respective nic. > In order for BGP to run the mac and ip address of the linux interface > running the bgp daemon and the settings on the matching LRP must be in > sync. > > This information is specific to each individual gateway chassis and is > also not of much relevance outside of this gateay chassis. > > In the past such chassis specific settings have been handled locally on > each chassis instead of requiring the CMS to handle them. E.g. for > ovn-bridge-mappings, ovn-chassis-mac-mappings, ovn-transport-zones. > > This patchset proposes a similar mechansim for configuring the LRPs. > It introduces "ovn-active-active-mappings" which allows northd to > generated the required LRPs with the appropriate settings. > > Additionally the CMS can still use a single LS as an "external network". > We just change from LS physnet to LS "my-net-for-cms". This means that > the effort to use all these features on the CMS side is greatly reduced. > > --- > > Felix Huettner (4): > controller: Publish ovn-active-active-mappings. > northd: Support active-active lrps. > northd: Support active-active bgp redirects. > northd: ECMP prefer local routes if possible. > > NEWS | 10 + > controller/chassis.c | 22 ++ > controller/ovn-controller.8.xml | 30 +++ > lib/automake.mk | 2 + > lib/lrp-index.c | 43 +++ > lib/lrp-index.h | 25 ++ > lib/ovn-util.c | 97 +++++++ > lib/ovn-util.h | 11 + > northd/en-northd.c | 4 + > northd/inc-proc-northd.c | 6 + > northd/northd.c | 456 ++++++++++++++++++++++++++++++-- > northd/northd.h | 10 + > ovn-nb.xml | 31 +++ > tests/ovn-macros.at | 17 ++ > tests/ovn-northd.at | 65 ++--- > tests/ovn.at | 353 ++++++++++++++++++++++++ It would be nice if the formal version of this patchset includes system and multinode tests to cover the supported e2e scenario. After going through the patch set, I have some concerns about the architecture you're introducing here. I shared those in my comments on patch 2/4. Thanks, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
