A native way of integrating OVN into the fabric through BGP-EVPN.#

Ales Musil (Red Hat), Dumitru Ceara (Red Hat)

• Why: OVN deployments have historically been islands attached to the physical fabric through gateways or external controllers. With native BGP in 25.03 and experimental BGP-EVPN in 25.09, OVN logical L2 domains now stretch directly into and across the DC fabric — the concrete mechanism by which the overlay joins the EVPN fabric.
• What: OVN-native EVPN support: a provider logical switch's L2 domain is extended across an IP fabric via VXLAN, with the BGP-EVPN control plane (run by FRR) distributing MAC/IP (type-2) and, planned for 26.03, type-5 routes. OVN learns remote VTEPs, remote FDBs, remote IPs (with ARP suppression) and remote routes; it advertises local workload MACs/IPs, connected networks and NAT IPs back into the fabric. L2 EVPN is implemented and experimental in 25.09; L3 EVPN per-VRF is the 26.03 plan.
• How: The CMS pre-configures br-$vni / lo-$vni / vxlan-$vni interfaces in the default network namespace; OVN monitors FRR/zebra state via NetLink and programs the OVS datapath: per-VTEP OpenFlow cookies on br-int, tun_id/tun_src/tun_dst loads, learn() actions with 30s hard timeouts for dynamic FDBs, and ARP-suppression flows on logical routers. Configuration is per logical switch via dynamic-routing-vni plus ovn-evpn-local-ip.
• Where applicable: Any OVN deployment needing L2/L3 fabric extension; datapath-agnostic (OVS kernel or DPDK) and hardware-offload friendly since VXLAN is terminated in OVS. Constraints: at most one local IP per EVPN tunnel today, fixed host-side interface naming (fine-grain naming is an open question), needs FRR on OVN nodes, and it is explicitly experimental with the authors soliciting design feedback.