On Fri, Aug 15, 2025 at 1:36 PM Ilya Maximets <i.maxim...@ovn.org> wrote:
> On 8/14/25 7:36 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, Dumitru and Ales for the update! > > I posted a few small nits for individual patches. They can likely be > just fixed on commit. With these addressed, for the set: > > Acked-by: Ilya Maximets <i.maxim...@ovn.org> > Thank you Dumitru, Xavier and Ilya, I went ahead and applied the series into main with the nits addressed. Regards, Ales _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
