On 8/6/25 8:26 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 (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 (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.
Hi, Ales and Dumitru. Thanks for working on this feature! Instead of replying to individual patches, I'll summarize here some high level feedback that I have after reading through the set: - The names of some of the parameters of evpn tunnels are confusing. There is a vni and a tunnel_key associated with evpn bindings, however, normally in OVN we would have vni to be a tunnel key and this evpn tunnel key is also more like a port key. So, for someone familiar a bit with the OVN terminology, this all looks strange and confusing. I'd suggest to use some different name instead of the tunnel_key when describing properties of evpn tunnels. - The code that looks for the vxlan tunnel seem a little error-prone as it just checks the configuration expecting it to look in a certain way. It may be better to have an external id marking instead, just to make things clear for the user. - The requirement for CMS to create a very specific vxlan tunnel port is a bit awkward and may be problematic in the future if we'll want to change the underlying implementation. I was thinking about interoperability of evpn support and ipsec. And if we ever want to support ipsec encryption for evpn tunnels, we may need to have a separate tunnel port per learned vtep. evpn over ipsec is a bit ugly today as one need to know the names of remote vteps in order to have a proper certificate configuration, so it's definitely not something we need to support right now. But the fact that vteps are dynamically learned by ovn-controller makes the ovn-controller the only entity that can create separate tunnels per vtep, if we want to support ipsec on them in the future, as each of these tunnels will need a separate remote_name and ip in order to setup libreswan connections properly. And upgrading from "CMS creates a tunnel" to "ovn-controller creates tunnels dynamically" may be more complicated than if ovn-controller handled the tunnel creation on its own from the start. The only parameter we need from CMS is the destination port, so that can be an option evpn-vxlan-port along with vni. This way if we need to change the underlying implementation in the future, we could do that more easily without having to change the CMS. - Speaking of ipsec. If the setup has ipsec enabled with a policy to drop unencrypted tunneled traffic, that will break evpn tunnels. We need to at least document that. The way to resolve the problem would be to provide an option like evpn-skb-mark, so users can set it up according to ipsec_skb_mark in the OVS configuration to explicitly allow evpn traffic to leave the node unencrypted. This skb mark will need to be set for the outgoing evpn traffic though OpenFlow. - The patch set introduces a library to receive and parse neighbor notifications from the kernel. But it has very limited test coverage through a couple of system tests that are not doing much. OVN side of things is similar to the amount of tests we have for route notifications, except that we have much more testing for route notifications in OVS, see tests/test-lib-route-table.c in the OVS sources and the tests that use it. It would be good to have this kind of coverage for the new neighbor library in OVN. There are more tests in OVS' tests/system-route.at, but at least some basic notification/dump tests that include creation and removal of the entries and maybe handling of creation and removal of ports these entries belong to would be good to have. - And yes, some more documentation in a form of a small tutorial for a basic configuration steps would definitely help. - There is a TODO item for learning FDB from evpn tunnels, but isn't the whole point of EVPN is having MAC/IP learning via BGP control plane instead of traditional broadcast that doesn't scale well? Just curious. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
