On Fri, Mar 27, 2026 at 5:17 PM Dumitru Ceara via dev < [email protected]> wrote:
> Add a new Documentation/topics/dynamic-routing/ section covering: > - OVN's integration model with external routing daemons > - Architecture diagrams for IP route exchange and EVPN > - Deployment scenario diagrams for both IP routing and EVPN > - IP route advertisement and learning mechanisms > - VRF management > - EVPN remote VTEP discovery, FDB/neighbor learning, and > Advertised MAC Binding > > Reported-at: https://redhat.atlassian.net/browse/FDP-3118 > Assisted-by: Claude, with model: claude-opus-4-6 > Signed-off-by: Dumitru Ceara <[email protected]> > --- > Hi Dumitru, thank you for the patch, this is nice addition, I have just two small comments down below. > Documentation/automake.mk | 2 + > .../topics/dynamic-routing/architecture.rst | 621 ++++++++++++++++++ > .../topics/dynamic-routing/index.rst | 31 + > Documentation/topics/index.rst | 1 + > 4 files changed, 655 insertions(+) > create mode 100644 Documentation/topics/dynamic-routing/architecture.rst > create mode 100644 Documentation/topics/dynamic-routing/index.rst > > diff --git a/Documentation/automake.mk b/Documentation/automake.mk > index 1bc9478bf3..7bd65cbe9f 100644 > --- a/Documentation/automake.mk > +++ b/Documentation/automake.mk > @@ -27,6 +27,8 @@ DOC_SOURCE = \ > Documentation/topics/testing.rst \ > Documentation/topics/test-development.rst \ > Documentation/topics/high-availability.rst \ > + Documentation/topics/dynamic-routing/architecture.rst \ > + Documentation/topics/dynamic-routing/index.rst \ > > Documentation/topics/incremental-processing/datapath-sync-graph.png \ > Documentation/topics/incremental-processing/evpn-arp-graph.png \ > Documentation/topics/incremental-processing/ic-graph.png \ > diff --git a/Documentation/topics/dynamic-routing/architecture.rst > b/Documentation/topics/dynamic-routing/architecture.rst > new file mode 100644 > index 0000000000..2473a8d154 > --- /dev/null > +++ b/Documentation/topics/dynamic-routing/architecture.rst > @@ -0,0 +1,621 @@ > +.. > + Licensed under the Apache License, Version 2.0 (the "License"); you > may > + not use this file except in compliance with the License. You may > obtain > + a copy of the License at > + > + http://www.apache.org/licenses/LICENSE-2.0 > + > + Unless required by applicable law or agreed to in writing, software > + distributed under the License is distributed on an "AS IS" BASIS, > WITHOUT > + WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > See the > + License for the specific language governing permissions and > limitations > + under the License. > + > + Convention for heading levels in OVN documentation: > + > + ======= Heading 0 (reserved for the title in a document) > + ------- Heading 1 > + ~~~~~~~ Heading 2 > + +++++++ Heading 3 > + ''''''' Heading 4 > + > + Avoid deeper levels because they do not render well. > + > +=========================== > +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`` --- All ``Logical_Router_Static_Route`` entries 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. > + > +These options can also be set per logical router port, overriding the > +router-level setting for routes associated with that specific port. > + > +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. This > +mechanism is particularly useful for host routes generated by the > +``connected-as-host`` redistribution mode. > + > +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. > + > +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_OVN`` are **skipped** because they were > + installed by ``ovn-controller`` itself (advertised routes). > + > +- Routes with protocol ``RTPROT_STATIC`` or 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: > + > +1. The ``dynamic-routing-vrf-id`` option on the logical router, if set to > + a valid integer (1-4294967295, excluding reserved table IDs such as > + ``RT_TABLE_MAIN`` and ``RT_TABLE_LOCAL``). > + > +2. The tunnel key of the logical router datapath, used as a fallback > + when ``dynamic-routing-vrf-id`` is 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_NEWLINK`` Netlink message with > + ``IFLA_LINKINFO`` kind ``vrf`` and the appropriate ``IFLA_VRF_TABLE`` > + value. > + > +- 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. > + > +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``: > + > +1. Allocates a tunnel key for the binding. > + > +2. Installs OpenFlow rules to encapsulate outbound traffic with the > + correct VNI and VTEP destination, and to decapsulate inbound traffic > + from the remote VTEP. > + > +3. 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-controller`` injects 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-controller`` installs 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-controller`` installs 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. > This is slightly incosistent, the "Advertised_Route" explanation is lacking the column explanation. Maybe we should add that too WDYT? + > +``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:: > nit: Double colon. > + > + vni0-IPv4,vni1-IPv4,vni1-IPv6,IPv4,IPv6 > + > +If no VNI-specific address is provided, the default IP address is used > +for all VNIs. > diff --git a/Documentation/topics/dynamic-routing/index.rst > b/Documentation/topics/dynamic-routing/index.rst > new file mode 100644 > index 0000000000..eb61afb4a3 > --- /dev/null > +++ b/Documentation/topics/dynamic-routing/index.rst > @@ -0,0 +1,31 @@ > +.. > + Licensed under the Apache License, Version 2.0 (the "License"); you > may > + not use this file except in compliance with the License. You may > obtain > + a copy of the License at > + > + http://www.apache.org/licenses/LICENSE-2.0 > + > + Unless required by applicable law or agreed to in writing, software > + distributed under the License is distributed on an "AS IS" BASIS, > WITHOUT > + WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > See the > + License for the specific language governing permissions and > limitations > + under the License. > + > + Convention for heading levels in OVN documentation: > + > + ======= Heading 0 (reserved for the title in a document) > + ------- Heading 1 > + ~~~~~~~ Heading 2 > + +++++++ Heading 3 > + ''''''' Heading 4 > + > + Avoid deeper levels because they do not render well. > + > +=============== > +Dynamic Routing > +=============== > + > +.. toctree:: > + :maxdepth: 2 > + > + architecture > diff --git a/Documentation/topics/index.rst > b/Documentation/topics/index.rst > index a5748445f7..e5ba92b7ba 100644 > --- a/Documentation/topics/index.rst > +++ b/Documentation/topics/index.rst > @@ -37,6 +37,7 @@ OVN > :maxdepth: 2 > > integration.rst > + dynamic-routing/index > incremental-processing/index > high-availability > role-based-access-control > -- > 2.53.0 > > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > Regards, Ales _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
