Hi Ales, MJ, Frode, On 7/25/25 8:03 AM, Ales Musil wrote: > The series adds support for basic EVPN L2. This is done by allowing > users to specify VNI on logical switches. That switch is considered > to be connected into the EVPN network. There are some prerequisites > that we expect to be configured. The should provide three interfaces > in the frr VRF, loopback called lo-$vni, vxlan interface called > vxlan-$vni and bridge that will control both of those interfaces, > called br-$vni. Those three interfaces are necessary to learn and > advertise the remote VTEPs and their FDBs. On top of that user is > expected to create OvS tunnel interface that will be used by OVN to > send/receive the traffic from EVPN. > > The series has four key parts, first is the netlink interaction > that allows us to learn the neighbors and create a new ones when > needed. Second part takes care of learning the remote VTEPs with > the physical flow creation that will ensure that the traffic is > properly handled in OVN. The third part takes care of learning the > remote FDBs that are provided by frr through the vxlan-$vni > interface, creating physical flows accordingly to learned FDBs. > The last part takes care of exposing OVN LSPs MAC addresses for > interfaces connected to the LS with VNI. > > All of those structures and their processing is happening strictly > on each ovn-controller. In other words there is no persistence, > all of this is in memory. This shouldn't affect restarts as we are > able to construct the data within single engine run so we wouldn't > flush the flows. The reason for that is mainly scalability. Storing > all those data in SB would lead to duplicates that would be different > only in the assigned chassis. If there is a need for better > persistence we can consider a local database. > > Please note that all of those config options are marked as > experimental, there is a chance that it might be changed or slightly > adjusted. The expectation is the feature would be tested within the > 25.09 release and possibly marked as stable in the 26.03 release. > > There are some things that should be considered for 26.03 that would > extend the functionality. For example the current approach allows us > to learn only static FDBs. But it would be definitely useful to allow > also dynamic FDB learning from incoming ARP as we do normally in OVN > pipeline. >
Ales, thanks a lot for all the hard work of implementing this! Just a note so we don't forget, we should make sure all this is listed in TODO.rst. We should probably also list the lack of support for L3 EVPN there as I think it's something we need before we can remove the "experimental" tag. > Currently there are no tests in the series, the aim is to add system > tests in later revisions for the specific steps. We have also > prepared multinode test, however that relies on at the moment > unmerged patch for BGP as it reuses some of the infrastructure. The > multinode test is available in WIP state [0] and the whole series > was regularly tested against that. > MJ, Frode, on this part (the multinode test), I was thinking of ways of streamlining the integration of original e2e BGP unnumbered test patch. Ales and I, we've been using the infrastructure it adds (in a slightly modified way) in our EVPN development branches, and I think it would be great to have it in the tree. Here's a proposal: we can accept the patch as it was originally submitted and Ales (or I) can post a follow up (as part of the next version of the EVPN series) that factors out the bits we need for FRR integration and addresses the comments that were raised on MJ's original patch. Would that be OK with you guys? Regards, Dumitru > [0] https://github.com/almusil/ovn/tree/refs/heads/bgp-evpn-multinode > > Ales Musil (7): > controller: Add support for remote VTEP learning. > controller: Pair remote VTEPs with datapaths. > controller: Create physical flows based on EVPN structures. > northd: Add an option to specify EVPN vni in logical switches. > controller: Create physical flows based on the advertised EVPN FDBs. > controller, northd: Add logical flows to use the EVPN static FDBs. > controller, northd: Add an option to advertise FDB over EVPN. > > Dumitru Ceara (4): > controller: Support monitoring/updating neighbor entries through > Netlink. > controller: Watch for (Linux) neighbor changes. > controller: Add host-if-monitor to track (Linux) interface indices. > controller: Add I-P to monitor host interfaces and synchronize > neighbors. > > NEWS | 8 + > TODO.rst | 4 + > controller/automake.mk | 19 +- > controller/chassis.c | 19 + > controller/evpn-binding.c | 427 ++++++++++++++ > controller/evpn-binding.h | 88 +++ > controller/evpn-fdb.c | 151 +++++ > controller/evpn-fdb.h | 59 ++ > controller/host-if-monitor-stub.c | 43 ++ > controller/host-if-monitor.c | 150 +++++ > controller/host-if-monitor.h | 30 + > controller/lflow.c | 1 + > controller/lflow.h | 8 +- > controller/neighbor-exchange-netlink.c | 475 +++++++++++++++ > controller/neighbor-exchange-netlink.h | 66 +++ > controller/neighbor-exchange-stub.c | 47 ++ > controller/neighbor-exchange.c | 265 +++++++++ > controller/neighbor-exchange.h | 69 +++ > controller/neighbor-table-notify-stub.c | 57 ++ > controller/neighbor-table-notify.c | 244 ++++++++ > controller/neighbor-table-notify.h | 45 ++ > controller/neighbor.c | 278 +++++++++ > controller/neighbor.h | 96 +++ > controller/ovn-controller.8.xml | 8 + > controller/ovn-controller.c | 743 +++++++++++++++++++++++- > controller/physical.c | 345 +++++++++-- > controller/physical.h | 12 + > include/ovn/actions.h | 3 + > include/ovn/logical-fields.h | 3 + > lib/actions.c | 53 +- > lib/logical-fields.c | 5 + > lib/ovn-util.c | 26 +- > lib/ovn-util.h | 7 + > northd/northd.c | 72 ++- > northd/northd.h | 6 +- > ovn-nb.xml | 47 ++ > tests/ovn-macros.at | 6 +- > tests/ovn.at | 21 +- > tests/test-ovn.c | 1 + > utilities/ovn-trace.c | 6 + > 40 files changed, 3947 insertions(+), 66 deletions(-) > create mode 100644 controller/evpn-binding.c > create mode 100644 controller/evpn-binding.h > create mode 100644 controller/evpn-fdb.c > create mode 100644 controller/evpn-fdb.h > create mode 100644 controller/host-if-monitor-stub.c > create mode 100644 controller/host-if-monitor.c > create mode 100644 controller/host-if-monitor.h > create mode 100644 controller/neighbor-exchange-netlink.c > create mode 100644 controller/neighbor-exchange-netlink.h > create mode 100644 controller/neighbor-exchange-stub.c > create mode 100644 controller/neighbor-exchange.c > create mode 100644 controller/neighbor-exchange.h > create mode 100644 controller/neighbor-table-notify-stub.c > create mode 100644 controller/neighbor-table-notify.c > create mode 100644 controller/neighbor-table-notify.h > create mode 100644 controller/neighbor.c > create mode 100644 controller/neighbor.h > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
