On 8/8/25 3:22 PM, Dumitru Ceara wrote: > 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).
I guess, the question is: is it normal for the MAC to not be advertised while we see traffic with this MAC? i.e. is it a misconfig/malfanction on the other end if this MAC is not advertised or is it a common thing to have in a properly configured EVPN setup? > >> Just curious. >> > > > Hope that answers your question. > >> Best regards, Ilya Maximets. >> > > > Regards, > Dumitru > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
