Dynamic Routing Integration
Introduction
OVN integrates with dynamic routing protocols to enable automatic exchange of routing information between OVN logical networks and the physical network fabric. A key design principle is that OVN does not implement any routing protocol stack itself. Instead, OVN relies on external routing protocol daemons — such as FRR (Free Range Routing) — running on each hypervisor (chassis) to handle the protocol control plane. OVN is not intended to ever implement routing protocols (BGP, OSPF, or others) directly.
The routing protocol control plane lives entirely outside OVN. OVN
interacts with these external daemons indirectly through the Linux kernel
networking stack. Specifically, ovn-controller exchanges routes with
the kernel via Netlink and monitors network interfaces for neighbor
information. This separation of concerns keeps OVN focused on logical
network management while leveraging mature, feature-rich routing
implementations for protocol handling.
OVN supports two main categories of dynamic routing integration:
IP Route Exchange — Learning routes from and advertising routes to external routing peers through VRF routing tables on each chassis.
EVPN (Ethernet VPN) — Extending Layer 2 and Layer 3 connectivity across the fabric by learning remote VTEPs, MAC addresses, and IP neighbors through EVPN-capable routing daemons.
Architecture Overview
IP Route Exchange
The following diagram shows the interaction between components involved in
dynamic IP route exchange. The routing protocol daemon (e.g., FRR) and
ovn-controller both operate on each chassis. They communicate
indirectly through the kernel routing table in a VRF associated with each
logical router that has dynamic routing enabled.
Chassis (Hypervisor)
+------------------------------------------------------------------+
| |
| +---------------------+ +-----------------------------+ |
| | Routing Daemon | | ovn-controller | |
| | (e.g., FRR) | | | |
| | | | | |
| | Speaks BGP, OSPF, | | Monitors VRF tables via | |
| | etc. with external | | Netlink for learned routes | |
| | peers | | | |
| | | | Installs advertised routes | |
| | Installs learned | | into VRF tables via | |
| | routes into VRF | | Netlink (RTPROT_OVN) | |
| | tables | | | |
| | | | | |
| +----------+----------+ +-----+--+--------------------+ |
| | | | |
| | Netlink | | Netlink |
| | (install routes) | | (read/write routes) |
| | | | |
| +----------v-------------------------v--v--------------------+ |
| | Linux Kernel - VRF Routing Table | |
| | (dynamic-routing-vrf-id / datapath tunnel key) | |
| +------------------------------------------------------------+ |
| |
+------------------------------------------------------------------+
|
|
+------------------------------------------------------------------+
| OVN Southbound Database |
| |
| +-------------------------+ +------------------------------+ |
| | Learned_Route | | Advertised_Route | |
| | | | | |
| | Populated by | | Populated by ovn-northd | |
| | ovn-controller with | | based on LR config: | |
| | routes learned from | | - connected routes | |
| | the VRF routing table | | - connected-as-host routes | |
| | (dynamic protocols | | - static routes | |
| | only, not RTPROT_OVN) | | - NAT external IPs | |
| | | | - Load Balancer VIPs | |
| +-------------------------+ +------------------------------+ |
| |
+------------------------------------------------------------------+
|
|
+------------------------------------------------------------------+
| ovn-northd |
| |
| Reads Learned_Route records and generates logical flows in the |
| IP routing stage of the logical router pipeline. |
| |
| Reads NB Logical_Router configuration and populates |
| Advertised_Route records in the SB database. |
| |
+------------------------------------------------------------------+
EVPN (Ethernet VPN)
EVPN integration follows a different pattern from IP route exchange. An
important distinction is that dynamically learned EVPN information (remote
VTEPs, MAC addresses, IP neighbors) is not stored in the OVN
Southbound database. Instead, each ovn-controller instance processes
this information locally, in memory, based on what it learns through
Netlink from the kernel.
Chassis (Hypervisor)
+------------------------------------------------------------------+
| |
| +---------------------+ +-----------------------------+ |
| | Routing Daemon | | ovn-controller | |
| | (e.g., FRR) | | | |
| | | | Monitors bridge/vxlan/ | |
| | Speaks BGP EVPN | | advertise interfaces for | |
| | with peers | | EVPN-enabled LSes | |
| | | | | |
| | Populates bridge | | Learns: | |
| | FDB, ARP/ND neigh | | - Remote VTEPs (per VNI) | |
| | entries, and VXLAN | | - FDB entries (MAC addrs) | |
| | FDB via kernel | | - ARP/ND entries (IPs) | |
| | | | | |
| +----------+----------+ | Creates OVS VXLAN tunnels | |
| | | (flow-based) in br-int | |
| | Netlink | | |
| | (FDB/neighbor | Installs bridge FDB and | |
| | entries) | ARP/ND entries for local | |
| | | workloads (advertise) | |
| +----------v-----------+ | | |
| | Linux Kernel | +------+--+-------------------+ |
| | |<-- Netlink --+ | |
| | - Bridge FDB table | (monitor) | OVS VXLAN tunnels |
| | - ARP/ND neigh table | | |
| | - VXLAN interfaces | +---------v------------------+ |
| +----------------------+ | OVS br-int | |
| | - VXLAN tunnel ports | |
| | - OpenFlow rules for | |
| | encap/decap per VNI | |
| +----------------------------+ |
| |
+------------------------------------------------------------------+
IP Route Exchange
Deployment Scenario
The following diagram illustrates a typical deployment where a logical router has dynamic routing enabled. The router is connected to multiple logical switches hosting workloads, has NAT rules, load balancers, and static routes configured. Through dynamic routing, OVN advertises selected prefixes to the external fabric and learns external routes from routing peers.
External Network / Fabric
|
| BGP/OSPF peering
|
+------------------+-------------------+
| Routing Daemon (FRR) |
| on Chassis |
+------------------+-------------------+
|
VRF table
(Netlink exchange)
|
+------------------+-----------------------------------------------+
| ovn-controller |
| |
| Advertises routes Learns routes from VRF |
| into VRF table and writes to SB Learned_Route |
+------------------+-----------------------------------------------+
|
OVN SB Database
(Advertised_Route / Learned_Route)
|
+------------------+------------------------------------------------+
| ovn-northd |
+-------------------------------------------------------------------+
| |
| Logical Router (LR1) |
| dynamic-routing = true |
| dynamic-routing-redistribute = |
| connected,static,nat,lb |
| |
| Advertised prefixes: Learned routes: |
| |
| connected: From external peers: |
| 10.0.1.0/24 (from LS1) 203.0.113.0/24 |
| 10.0.2.0/24 (from LS2) via 192.168.1.1 |
| 10.0.3.0/24 (from LS3) 198.51.100.0/24 |
| via 192.168.1.2 |
| static: |
| 172.16.0.0/16 |
| via 10.0.1.1 |
| |
| nat (external IPs): |
| 192.168.50.10/32 (DNAT+SNAT) |
| 192.168.50.20/32 (SNAT) |
| |
| lb (VIPs): |
| 192.168.60.100/32 (LB VIP) |
| |
+--------+----------------+-----------------+-----------------------+
| | |
+--------+-------+ +------+--------+ +------+--------+
| Logical Switch | | Logical Switch| | Logical Switch|
| LS1 | | LS2 | | LS3 |
| 10.0.1.0/24 | | 10.0.2.0/24 | | 10.0.3.0/24 |
| | | | | |
| VM1 VM2 VM3 | | VM4 VM5 | | VM6 |
+----------------+ +---------------+ +---------------+
In this scenario ovn-northd populates the SB Advertised_Route
table with entries for each prefix type selected by
dynamic-routing-redistribute. On each chassis, ovn-controller
reads these records and installs the corresponding routes (as blackhole
by default, or with a specific nexthop if
dynamic-routing-v4/v6-prefix-nexthop is set) into the VRF routing
table associated with the logical router. The routing daemon picks up
these routes and advertises them to external peers.
Conversely, when the routing daemon learns routes from external peers, it
installs them into the same VRF table. ovn-controller detects these
new routes via Netlink (filtering out routes it installed itself using the
RTPROT_OVN protocol marker) and creates corresponding
Learned_Route records in the SB database. ovn-northd then
generates logical flows in the IP routing pipeline stage to implement
forwarding for these learned routes.
IP Route Advertisement
When a logical router has dynamic-routing set to true, ovn-northd
examines the router configuration and populates the Advertised_Route
table in the OVN Southbound database. The types of routes that are
advertised depend on the dynamic-routing-redistribute option, which
accepts a comma-separated list of the following values:
connected— Subnet prefixes directly connected to the logical router ports (e.g., 10.0.1.0/24 for a port with address 10.0.1.1/24).connected-as-host— Individual host routes (/32 for IPv4, /128 for IPv6) for each IP address on logical switch ports, router ports, and NAT entries associated with this router.static— AllLogical_Router_Static_Routeentries configured on the router.nat— The external IP of each NAT rule on this router and neighboring routers that share a distributed gateway port.lb— The VIP address of each load balancer associated with this router and neighboring routers.hub-spoke— Routes learned through OVN Interconnection (OVN-IC) from other routers, enabling hub-and-spoke propagation.
These options can also be set per logical router port, overriding the router-level setting for routes associated with that specific port.
Each Advertised_Route record includes:
datapath— The logical router datapath this route belongs to.logical_port— The port binding this route is associated with.ip_prefix— The IP prefix of this route (e.g., 192.168.100.0/24).tracked_port— Tracks the port OVN will forward packets for this destination to. An announcing chassis can use this to check if the destination is local and adjust route priorities accordingly.
Route Installation on the Chassis
On each chassis, ovn-controller reads the Advertised_Route
records from the Southbound database and installs corresponding routes
into the Linux VRF routing table associated with the logical router.
Routes are installed via Netlink with the RTPROT_OVN protocol marker
so that ovn-controller can distinguish OVN-managed routes from routes
installed by other sources. By default, advertised routes are installed
as blackhole routes (to attract traffic into OVN for processing). If
dynamic-routing-v4-prefix-nexthop or dynamic-routing-v6-prefix-nexthop
is set on the logical router, routes are installed with the specified
nexthop address instead.
Route Priority
When the tracked_port field is set on an Advertised_Route record,
ovn-controller adjusts the route metric based on whether the tracked
port is locally bound on this chassis. Routes for locally bound ports
receive a higher priority (lower metric value), which causes the routing
daemon to prefer the chassis that actually hosts the workload.
The dynamic-routing-redistribute-local-only option further refines
this behavior: when set to true, ovn-controller only installs
routes on the chassis where the tracked_port is locally bound,
preventing other chassis from advertising the route at all.
This is particularly useful with connected-as-host redistribution
to ensure host routes are only announced from the chassis that owns the
workload, providing optimal traffic forwarding and avoiding unnecessary
traffic tromboning.
IP Route Learning
ovn-controller monitors the VRF routing tables associated with
dynamic-routing-enabled logical routers for routes installed by external
routing daemons. This monitoring is performed via Netlink route
notifications (RTNLGRP_IPV4_ROUTE and RTNLGRP_IPV6_ROUTE).
When a route change is detected in a watched VRF table,
ovn-controller dumps the table contents and processes each route.
The following filtering rules apply:
Routes with protocol
RTPROT_OVNare skipped because they were installed byovn-controlleritself (advertised routes).Routes with protocol
RTPROT_STATICor lower are skipped because they are not dynamic routing protocol routes.Only routes installed by dynamic routing protocols (protocol value greater than
RTPROT_STATIC) are considered for learning.Link-local prefixes are skipped.
For each qualifying route, ovn-controller creates a Learned_Route
record in the Southbound database containing the datapath, logical port,
IP prefix, and nexthop.
Flow Generation by ovn-northd
ovn-northd reads the Learned_Route table and generates logical
flows in the IP routing stage of the logical router processing pipeline.
These flows implement longest-prefix-match forwarding for the learned
routes. Learned routes receive a lower priority than static routes,
ensuring that explicitly configured routes always take precedence.
Disabling Route Learning
Route learning can be disabled on a per-router or per-port basis by
setting the dynamic-routing-no-learning option to true. When
this option is enabled, ovn-controller does not create
Learned_Route records for the affected router or port and removes any
previously learned routes.
VRF Management
Each logical router with dynamic routing enabled is associated with a
Linux VRF (Virtual Routing and Forwarding) instance on each chassis.
The VRF provides an isolated routing table where ovn-controller and
the external routing daemon exchange routes.
VRF Table ID
The VRF routing table ID is determined by one of the following, in order of precedence:
The
dynamic-routing-vrf-idoption on the logical router, if set to a valid integer in the range (1-4294967294), excluding the reserved table IDs 252 (RT_TABLE_COMPAT), 253 (RT_TABLE_DEFAULT), 254 (RT_TABLE_MAIN), and 255 (RT_TABLE_LOCAL).The tunnel key of the logical router datapath, used as a fallback when
dynamic-routing-vrf-idis not configured.
VRF Naming
The VRF interface name is determined by the dynamic-routing-vrf-name
option on the logical router. If not set, the name defaults to
ovnvrf followed by the VRF table ID (e.g., ovnvrf42). The
name must be a valid Linux network interface name.
VRF Lifecycle
When the dynamic-routing-maintain-vrf option is set to true on
a logical router port, ovn-controller creates and manages the VRF
interface on the chassis where the port is bound. This includes:
Creating the VRF interface via a
RTM_NEWLINKNetlink message withIFLA_LINKINFOkindvrfand the appropriateIFLA_VRF_TABLEvalue.Deleting the VRF interface when dynamic routing is disabled or the port is unbound.
If dynamic-routing-maintain-vrf is false (the default), the VRF
is expected to already exist on the chassis, managed by external tooling
or configuration management.
Routing Protocol Redirect
OVN can optionally redirect routing protocol control plane traffic from a logical router port to a logical switch port where an external routing daemon is listening. This allows the routing daemon to peer using the router port’s IP addresses through an OVN-managed logical switch port.
Routing protocol redirect is entirely optional. The routing daemon can establish its BGP or BFD sessions completely outside of OVN — for example, on a separate physical interface, a loopback, or any other interface that is not managed by OVN. Use this feature only when you want the routing daemon to peer using the logical router port’s IP addresses through an OVN-managed logical switch port.
The routing-protocols option on a Logical_Router_Port specifies
which control plane protocols to redirect:
BGP— Redirects TCP port 179 (BGP session establishment and keepalives).BFD— Redirects UDP port 3784 (Bidirectional Forwarding Detection).
The routing-protocol-redirect option on the same port identifies the
logical switch port where the routing daemon is bound. OVN installs
logical flows to forward matching control plane traffic between the
router port and the specified switch port.
For BGP unnumbered deployments, periodic IPv6 Router Advertisements can be
enabled on the logical router port via the ipv6_ra_configs column.
This provides automatic link-local address discovery, which is required
for establishing BGP sessions over IPv6-only peering links that carry
both IPv4 and IPv6 routes. In order for this to function, automatic address
discovery needs to also be supported and configured on remote BGP peer.
Port-to-Interface Mapping
When a chassis has multiple links toward the fabric, each running BGP
independently, the dynamic-routing-port-name option on a logical
router port restricts route learning to a specific Linux interface.
ovn-controller resolves the port name to a Linux interface. If the
referenced port is bound locally, the interface name is discovered
automatically.
When automatic discovery is not available (for example, the port is not
bound locally), the dynamic-routing-port-mapping option on the
Open_vSwitch table provides an explicit mapping from logical port
names to Linux interface names.
EVPN (Ethernet VPN) Integration
EVPN extends OVN logical switches across the physical fabric using VXLAN
encapsulation and BGP EVPN for control-plane signaling. EVPN is enabled
on a logical switch by setting the dynamic-routing-vni option to a
valid VNI (VXLAN Network Identifier) value (0–16777215).
When EVPN is enabled on a logical switch, the following interface names must also be configured:
dynamic-routing-bridge-ifname— The Linux bridge interface associated with the EVPN domain.dynamic-routing-vxlan-ifname— One or more VXLAN device interface names used for EVPN integration.dynamic-routing-advertise-ifname— The interface used for advertising local MAC and IP bindings to the routing daemon.
Deployment Scenario
The following diagram illustrates a deployment with an EVPN-enabled logical switch. The logical switch is assigned a VNI (VXLAN Network Identifier) and is associated with bridge, VXLAN, and advertise interfaces on each chassis. Through EVPN, OVN discovers remote VTEPs and learns remote MAC and IP addresses without storing this information in the Southbound database.
Chassis A Chassis B
+-------------------------------+ +-------------------------------+
| | | |
| ovn-controller | | ovn-controller |
| | | |
| Logical Switch (LS-EVPN) | | Logical Switch (LS-EVPN) |
| dynamic-routing-vni = 1000 | | dynamic-routing-vni = 1000 |
| dynamic-routing-redistribute | | dynamic-routing-redistribute |
| = fdb,ip | | = fdb,ip |
| | | |
| Local workloads: | | Local workloads: |
| VM-A1: MAC-A1, 10.0.1.10 | | VM-B1: MAC-B1, 10.0.1.20 |
| VM-A2: MAC-A2, 10.0.1.11 | | VM-B2: MAC-B2, 10.0.1.21 |
| | | |
| Interfaces configured: | | Interfaces configured: |
| bridge-ifname: br-evpn | | bridge-ifname: br-evpn |
| vxlan-ifname: vxlan1000 | | vxlan-ifname: vxlan1000 |
| advertise-ifname: adv-evpn | | advertise-ifname: adv-evpn |
| | | |
+-------+-----------+-----------+ +-----------+-----------+-------+
| | | |
| | | |
+-------v-----------v-----------+ +-----------v-----------v-------+
| Linux Kernel | | Linux Kernel |
| | | |
| br-evpn (bridge) | | br-evpn (bridge) |
| vxlan1000 (VXLAN VNI 1000) | | vxlan1000 (VXLAN VNI 1000) |
| adv-evpn (advertise device) | | adv-evpn (advertise device) |
| | | |
| FDB: MAC-A1, MAC-A2 (local) | | FDB: MAC-B1, MAC-B2 (local) |
| Neigh: 10.0.1.10, .11 | | Neigh: 10.0.1.20, .21 |
| | | |
+-------+-----------------------+ +-----------------------+-------+
| |
+-------v-----------------------+ +-----------------------v-------+
| FRR (BGP EVPN) | | FRR (BGP EVPN) |
| | | |
| Reads local FDB/neigh | | Reads local FDB/neigh |
| entries and advertises | | entries and advertises |
| Type-2 (MAC+IP) routes | | Type-2 (MAC+IP) routes |
| to peers | | to peers |
| | | |
| Learns remote entries | | Learns remote entries |
| from peers and installs | | from peers and installs |
| them into kernel FDB/neigh | | them into kernel FDB/neigh |
| | | |
+-------+-----------------------+ +-----------------------+-------+
| |
| BGP EVPN peering |
+------------------------------------------------------+
On Chassis A, ovn-controller installs static bridge FDB entries and
ARP/ND neighbor entries for local workloads (VM-A1, VM-A2) into the
kernel via Netlink on the advertise interface. FRR reads these entries
and advertises them as EVPN Type-2 routes to its peers.
When FRR on Chassis A learns remote entries from Chassis B (MAC-B1,
MAC-B2, and their IPs), it installs them into the kernel bridge FDB and
neighbor tables. ovn-controller on Chassis A monitors the VXLAN and
bridge interfaces via Netlink to discover:
Remote VTEPs: the tunnel endpoints on Chassis B for VNI 1000.
Remote MACs: FDB entries for MAC-B1 and MAC-B2.
Remote IPs: ARP/ND entries for 10.0.1.20 and 10.0.1.21.
ovn-controller creates one flow-based OVS VXLAN tunnel port in
br-int for each configured EVPN VXLAN port and installs OpenFlow
rules to encapsulate traffic destined for remote MACs/IPs using the
appropriate VNI and VTEP destination.
Remote VTEP Discovery
ovn-controller monitors the VXLAN interfaces configured for each
EVPN-enabled logical switch via Netlink neighbor table notifications.
When the routing daemon (e.g., FRR) learns about remote VTEPs through
BGP EVPN peering, it installs neighbor entries in the kernel for the
VXLAN device. ovn-controller detects these entries and extracts the
remote VTEP IP address, destination port, and VNI.
ovn-controller creates one flow-based OVS VXLAN tunnel port in
br-int for each configured EVPN VXLAN port (configured via
ovn-evpn-vxlan-ports in the Open_vSwitch table).
For each discovered remote VTEP, ovn-controller:
Allocates a tunnel key for the binding.
Installs OpenFlow rules to encapsulate outbound traffic with the correct VNI and VTEP destination, and to decapsulate inbound traffic from the remote VTEP.
Creates multicast groups per VNI for BUM (Broadcast, Unknown unicast, Multicast) traffic flooding to all remote VTEPs in the same EVPN domain.
FDB and Neighbor Learning
In addition to remote VTEP discovery, ovn-controller monitors the
bridge and VXLAN interfaces for:
FDB (Forwarding Database) entries — MAC addresses learned through EVPN Type-2 routes, indicating which remote VTEP a given MAC address is reachable through.
ARP/ND neighbor entries — IP-to-MAC bindings learned through EVPN Type-2 MAC+IP routes, which
ovn-controllerinjects into the adjacent logical router pipeline for L3 forwarding.
The dynamic-routing-fdb-prefer-local option controls the lookup
order for FDB entries: when set to true, OVN first checks the
Southbound FDB table (populated through normal OVN mechanisms) before
falling back to the locally learned EVPN FDB cache. By default, the
EVPN-learned entries take precedence.
Similarly, the dynamic-routing-arp-prefer-local option controls the
lookup order for ARP/ND entries: when set to true, the Southbound
MAC_Binding table is checked before the EVPN-learned neighbor cache.
Unlike IP route exchange, dynamically learned EVPN information
(remote VTEPs, FDB entries, and ARP/ND neighbors) is not stored
in the OVN Southbound database. Each ovn-controller instance
processes this information locally, in memory. This design avoids
the overhead of synchronizing high-volume, rapidly changing L2/L3
state through the centralized database.
Local MAC and IP Advertisement
The dynamic-routing-redistribute option on EVPN-enabled logical
switches controls what local information ovn-controller advertises
to the routing daemon by installing static entries into the kernel:
fdb—ovn-controllerinstalls static bridge FDB entries for all local workloads (VIF ports, container ports, virtual ports, distributed gateway ports, and gateway router ports) on the advertise interface. The routing daemon reads these entries and advertises them as EVPN Type-2 MAC routes to its peers.ip—ovn-controllerinstalls static ARP/ND neighbor entries for all local IP-to-MAC bindings (VIF ports and router ports) on the advertise interface. The routing daemon advertises these as EVPN Type-2 MAC+IP routes.
Advertised MAC Binding
The Advertised_MAC_Binding table in the Southbound database is
populated by ovn-northd for EVPN-enabled logical switches. It
contains the IP and MAC address pairs that should be announced to the
external network fabric. Each record includes:
datapath— The logical switch this binding belongs to.logical_port— The port binding this entry is associated with.ip— The IP address to announce.mac— The MAC address to announce.
ovn-controller reads these records and installs the corresponding
static FDB and neighbor entries on the appropriate kernel interfaces,
making them available to the routing daemon for EVPN advertisement.
EVPN Source IP Configuration
The ovn-evpn-local-ip option in the Open_vSwitch table
external_ids configures the source IP addresses used for EVPN VXLAN
tunnels. The format supports per-VNI IP assignment:
vni0-IPv4,vni1-IPv4,vni1-IPv6,IPv4,IPv6
If no VNI-specific address is provided, the default IP address is used for all VNIs.