On 8/8/25 2:25 PM, Ilya Maximets wrote: > 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! >
Hi Ilya, Thanks for reviewing this series! > 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. > That's a fair point. The ovn-controller "evpn tunnel key" is indeed just a port key/id. We should rename it accordingly. We'll do that in v3. > - 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. > Ack. > - 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. > Makes sense. While the fact that the feature is "experimental" allows us to break compatibility in the future it's probably best to accommodate this from the beginning. The "evpn-vxlan-port" NB config sounds like a good idea. We'll do that in v3. > - 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 Ack, we'll document this in v3. > 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. I'm not sure we'll get to this in v3 but if not we'll definitely add a TODO item for it to be covered in the next release. > > - 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. > I'll work on adding tests for the neighbor library in v3. > - And yes, some more documentation in a form of a small tutorial > for a basic configuration steps would definitely help. > Yes, this too. :) > - 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? Maybe the TODO item is not explicit enough. If the remote MAC is advertised through BGP-EVPN (i.e., there's a type-2 EVPN route advertised by the remote side for that MAC) FRR will install an extern_learn neighbor entry for it on the bridge ovn-controller monitors. In that case we'll learn it and use it (so no broadcast). However, if traffic enters OVN through an EVPN VXLAN tunnel and the source MAC of the inner packet is not advertised through a type-2 OVN will not dynamically learn that MAC address (yet). > Just curious. > Hope that answers your question. > Best regards, Ilya Maximets. > Regards, Dumitru _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
