| Message ID | 20250812145658.1528144-1-amusil@redhat.com |
|---|---|
| Headers | show |
| Series | Add support for basic EVPN L2. | expand |
Hi Ales, Dumitru Besides the few small nits I just sent, and provided that "ovn v3 04/14 controller: Add I-P to monitor host interfaces and synchronize neighbors." is fixed in a similar way as the route-exchange fix <http://patchwork.ozlabs.org/project/ovn/patch/20250813155350.1169298-1-dceara@redhat.com/>, all patches can be Acked-by: Xavier Simonart <xsimonar@redhat.com> Thanks for your hard work. Xavier On Tue, Aug 12, 2025 at 4:57 PM Ales Musil via dev <ovs-dev@openvswitch.org> 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 Musil (8): > controller: Add support for remote VTEP learning. > controller: Create EVPN tunnel based on new option. > 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 (6): > 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. > multinode.at: Factor configuration of BGP FRR speakers and OVN > topology. > multinode.at: Add EVPN L2 test. > > Makefile.am | 5 +- > NEWS | 13 + > TODO.rst | 10 + > controller/automake.mk | 19 +- > controller/chassis.c | 37 ++ > controller/encaps.c | 115 +++- > controller/evpn-binding.c | 416 +++++++++++++ > 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 | 161 +++++ > controller/host-if-monitor.h | 30 + > controller/lflow.c | 1 + > controller/lflow.h | 8 +- > controller/neighbor-exchange-netlink.c | 487 ++++++++++++++++ > controller/neighbor-exchange-netlink.h | 62 ++ > controller/neighbor-exchange-stub.c | 47 ++ > controller/neighbor-exchange.c | 249 ++++++++ > 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 | 275 +++++++++ > controller/neighbor.h | 98 ++++ > controller/ovn-controller.8.xml | 28 + > controller/ovn-controller.c | 745 +++++++++++++++++++++++- > controller/physical.c | 339 ++++++++++- > controller/physical.h | 12 + > controller/test-ovn-netlink.c | 197 +++++++ > include/ovn/actions.h | 3 + > include/ovn/logical-fields.h | 3 + > lib/actions.c | 53 +- > lib/logical-fields.c | 5 + > lib/ovn-util.c | 24 +- > lib/ovn-util.h | 6 + > northd/northd.c | 98 +++- > northd/northd.h | 6 +- > ovn-nb.xml | 61 ++ > tests/automake.mk | 16 +- > tests/multinode-bgp-macros.at | 370 ++++++++++++ > tests/multinode-testsuite.at | 1 + > tests/multinode.at | 317 +++++----- > tests/ovn-controller.at | 57 ++ > tests/ovn-macros.at | 10 +- > tests/ovn-northd.at | 59 ++ > tests/ovn.at | 21 +- > tests/system-common-macros.at | 16 + > tests/system-dpdk-testsuite.at | 1 + > tests/system-kmod-testsuite.at | 1 + > tests/system-ovn-netlink.at | 257 ++++++++ > tests/system-ovn.at | 233 ++++++++ > tests/system-userspace-testsuite.at | 1 + > tests/test-ovn.c | 1 + > tests/test-utils.c | 36 ++ > tests/test-utils.h | 10 +- > utilities/ovn-trace.c | 6 + > 57 files changed, 5534 insertions(+), 248 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 > create mode 100644 controller/test-ovn-netlink.c > create mode 100644 tests/multinode-bgp-macros.at > create mode 100644 tests/system-ovn-netlink.at > > -- > 2.50.1 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > >
On 8/12/25 4:56 PM, Ales Musil via dev 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 Musil (8): > controller: Add support for remote VTEP learning. > controller: Create EVPN tunnel based on new option. > 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 (6): > 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. > multinode.at: Factor configuration of BGP FRR speakers and OVN > topology. > multinode.at: Add EVPN L2 test. Thanks, Ales and Dumitru. I'm done with reviewing this set, mostly looks good, larger comments I posted are for the first patch, the rest are mostly style nits and small mistakes. Thanks! Best regards, Ilya Maximets.
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 Musil (8): controller: Add support for remote VTEP learning. controller: Create EVPN tunnel based on new option. 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 (6): 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. multinode.at: Factor configuration of BGP FRR speakers and OVN topology. multinode.at: Add EVPN L2 test. Makefile.am | 5 +- NEWS | 13 + TODO.rst | 10 + controller/automake.mk | 19 +- controller/chassis.c | 37 ++ controller/encaps.c | 115 +++- controller/evpn-binding.c | 416 +++++++++++++ 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 | 161 +++++ controller/host-if-monitor.h | 30 + controller/lflow.c | 1 + controller/lflow.h | 8 +- controller/neighbor-exchange-netlink.c | 487 ++++++++++++++++ controller/neighbor-exchange-netlink.h | 62 ++ controller/neighbor-exchange-stub.c | 47 ++ controller/neighbor-exchange.c | 249 ++++++++ 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 | 275 +++++++++ controller/neighbor.h | 98 ++++ controller/ovn-controller.8.xml | 28 + controller/ovn-controller.c | 745 +++++++++++++++++++++++- controller/physical.c | 339 ++++++++++- controller/physical.h | 12 + controller/test-ovn-netlink.c | 197 +++++++ include/ovn/actions.h | 3 + include/ovn/logical-fields.h | 3 + lib/actions.c | 53 +- lib/logical-fields.c | 5 + lib/ovn-util.c | 24 +- lib/ovn-util.h | 6 + northd/northd.c | 98 +++- northd/northd.h | 6 +- ovn-nb.xml | 61 ++ tests/automake.mk | 16 +- tests/multinode-bgp-macros.at | 370 ++++++++++++ tests/multinode-testsuite.at | 1 + tests/multinode.at | 317 +++++----- tests/ovn-controller.at | 57 ++ tests/ovn-macros.at | 10 +- tests/ovn-northd.at | 59 ++ tests/ovn.at | 21 +- tests/system-common-macros.at | 16 + tests/system-dpdk-testsuite.at | 1 + tests/system-kmod-testsuite.at | 1 + tests/system-ovn-netlink.at | 257 ++++++++ tests/system-ovn.at | 233 ++++++++ tests/system-userspace-testsuite.at | 1 + tests/test-ovn.c | 1 + tests/test-utils.c | 36 ++ tests/test-utils.h | 10 +- utilities/ovn-trace.c | 6 + 57 files changed, 5534 insertions(+), 248 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 create mode 100644 controller/test-ovn-netlink.c create mode 100644 tests/multinode-bgp-macros.at create mode 100644 tests/system-ovn-netlink.at