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. 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. [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 -- 2.50.0 _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
