On 5/29/26 9:12 PM, Mark Michelson wrote: > Hi Dumitru, I have comments below. >
Hi Mark (and Lorenzo), Thanks for the reviews! > On Fri, May 29, 2026 at 8:16 AM Dumitru Ceara via dev > <[email protected]> wrote: >> >> Add a configuration and usage guide for OVN's dynamic routing >> feature covering IP route exchange with external routing >> daemons. >> >> The guide is incomplete on purpose, all of these configuration options >> are already described in the main ovn-nb man page. The added value is >> some more details and a few examples. >> >> The guide includes: >> - Configuration reference for Logical_Router and >> Logical_Router_Port dynamic routing options. >> - VRF management, route redistribution, route learning, >> and routing protocol redirect configuration. >> - Two worked examples: gateway router with BGP and >> distributed router with gateway ports. >> - Verification/troubleshooting commands and best practices. >> >> Reported-at: https://redhat.atlassian.net/browse/FDP-3119 >> Assisted-by: Claude Opus 4.6, Claude Code >> Signed-off-by: Dumitru Ceara <[email protected]> >> --- >> NOTE: I'm still not 100% sure that the added value of this documentation >> is worth the change. AI tended to be very thorough in adding >> (unnecessarily detailed) information. I did my best to trim it down to >> something that might be interesting to have in the OVN tree. >> I'll leave it up to reviewers to share their opinions. >> --- > > Generally speaking, I don't think this document adds much value beyond > what is already in topics/dynamic-routing/architecture.rst (I'll call > it "the architecture document" from here on). This document has some > information missing from the architecture document, but I think that > just means the architecture document should be updated with this > information instead. See my individual notes below. > You're right, this patch is sloppier than it should've been, sorry about that. > I think the Usage Examples section is the one section in here that > justifies adding a new document. I know that I like to use concrete > examples as a learning tool, so seeing a network being built out with > ovn-nbctl commands is quite useful when trying to see how I would > practically build out a network with dynamic routing. A document that > contains usage examples with comments explaining the options being set > would be very nice. > That makes sense, I'll do that in v2. >> Documentation/automake.mk | 1 + >> .../topics/dynamic-routing/configuration.rst | 586 ++++++++++++++++++ >> .../topics/dynamic-routing/index.rst | 1 + >> 3 files changed, 588 insertions(+) >> create mode 100644 Documentation/topics/dynamic-routing/configuration.rst >> >> diff --git a/Documentation/automake.mk b/Documentation/automake.mk >> index aa286ebd9c..60e64c7c6d 100644 >> --- a/Documentation/automake.mk >> +++ b/Documentation/automake.mk >> @@ -27,6 +27,7 @@ DOC_SOURCE = \ >> Documentation/topics/test-development.rst \ >> Documentation/topics/high-availability.rst \ >> Documentation/topics/dynamic-routing/architecture.rst \ >> + Documentation/topics/dynamic-routing/configuration.rst \ >> Documentation/topics/dynamic-routing/index.rst \ >> Documentation/topics/incremental-processing/datapath-sync-graph.png \ >> Documentation/topics/incremental-processing/evpn-arp-graph.png \ >> diff --git a/Documentation/topics/dynamic-routing/configuration.rst >> b/Documentation/topics/dynamic-routing/configuration.rst >> new file mode 100644 >> index 0000000000..e9b3c937ca >> --- /dev/null >> +++ b/Documentation/topics/dynamic-routing/configuration.rst >> @@ -0,0 +1,586 @@ >> +.. >> + 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 Configuration and Usage >> +======================================= >> + >> +Introduction >> +------------ >> + >> +This guide covers some common examples of how to configure OVN's IP >> +route exchange feature with an external routing daemon such as FRR >> +(Free Range Routing). For the underlying architecture and data flow >> +details, see :doc:`/topics/dynamic-routing/architecture`. >> + >> +Prerequisites >> +------------- >> + >> +Before configuring dynamic routing, ensure the following are in place: >> + >> +- A running OVN deployment. >> + >> +- FRR (or another routing daemon) installed on each chassis that will >> + participate in dynamic routing. >> + >> +IP Route Exchange >> +----------------- >> + >> +IP route exchange allows OVN to advertise logical network prefixes to >> +external routing peers and learn external routes back into the OVN >> +logical topology. >> + >> +Enabling Dynamic Routing on a Logical Router >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +Enable dynamic routing by setting the ``dynamic-routing`` option on >> +the logical router:: >> + >> + $ ovn-nbctl set Logical_Router lr1 options:dynamic-routing=true >> + >> +This alone does not advertise any routes. You must also configure >> +which route types to redistribute (see below). >> + >> +Configuring Route Redistribution >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +The ``dynamic-routing-redistribute`` option controls which routes OVN >> +advertises to the external fabric. It accepts a comma-separated list >> +of the following values: >> + >> +``connected`` >> + Subnet prefixes from networks attached to the router's 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 actively used IP on the connected networks. This includes >> + logical switch port addresses, router port addresses, and NAT >> + entries of routers connected directly or via a shared logical >> + switch. Replaces the subnet prefix routes that ``connected`` >> + would advertise with per-IP host routes. Useful for steering >> + traffic to the chassis that hosts a specific workload. >> + >> +``static`` >> + All ``Logical_Router_Static_Route`` entries on the router. >> + >> +``nat`` >> + The external IP of each NAT rule on this router and its >> + neighboring routers (routers connected directly or via a shared >> + logical switch). >> + >> +``lb`` >> + The VIP address of each load balancer on this router and its >> + neighboring routers. >> + >> +``hub-spoke`` >> + Routes learned through OVN Interconnection (OVN-IC) from other >> + routers, enabling hub-and-spoke propagation. > > The architecture document does not list "hub-spoke" as an option. This > should be added to the architecture document. > Yep, I'll do that in v2. >> + >> +Set redistribution on the router:: >> + >> + $ ovn-nbctl set Logical_Router lr1 \ >> + options:dynamic-routing-redistribute=connected,static,nat,lb >> + >> +Per-port overrides are also supported. Setting >> +``dynamic-routing-redistribute`` on a ``Logical_Router_Port`` >> +overrides the router-level setting for routes associated with that >> +port:: >> + >> + $ ovn-nbctl set Logical_Router_Port lrp-fabric \ >> + options:dynamic-routing-redistribute=connected,nat >> + >> +If no per-port value is set, the router-level setting applies. >> + >> +VRF Configuration >> +~~~~~~~~~~~~~~~~~ >> + >> +Each dynamic-routing-enabled logical router is associated with a >> +Linux VRF on each chassis. ``ovn-controller`` and the routing daemon >> +exchange routes through this VRF's routing table. >> + >> +**VRF Table ID.** >> +The VRF table ID is determined by: >> + >> +1. The ``dynamic-routing-vrf-id`` option, if set to a valid integer >> + (1--4294967295; IDs 253--255 are reserved by the Linux kernel >> + and should be avoided):: > > IMO, neither this nor the architecture document does a good job > explaining which IDs not to use. This document says that 253-255 are > reserved and "should be avoided". "Should be avoided" is not a good > way of stating that those table IDs are invalid and thus are not > allowed. > > In actuality, the code does the following check: > > #define TABLE_ID_VALID(table_id) (table_id != RT_TABLE_UNSPEC && > \ > table_id != RT_TABLE_COMPAT && > \ > table_id != RT_TABLE_DEFAULT && > \ > table_id != RT_TABLE_MAIN && > \ > table_id != RT_TABLE_LOCAL && > \ > table_id != RT_TABLE_MAX) > > This means the values, 0, 252, 253, 254, 255, and 4294967295 are not > allowed. This document leaves out the values 252 and 4294967295. > > The architecture document states "1-4294967295, excluding reserved > table IDs such as RT_TABLE_MAIN and RT_TABLE_LOCAL" . I'm not sure if > RT_TABLE_MAIN and RT_TABLE_LOCAL vary between systems, but if they > don't, then using the numbers directly would be good. Even if the > numbers were substituted, it still does not indicate that 252 and 253 > are not allowed. Also, 4294967295 is explicitly specified as a valid > option, when it's not (RT_TABLE_MAX). > I'll fix this in the arch doc and remove it from the configuration guide one. >> + >> + $ ovn-nbctl set Logical_Router lr1 \ >> + options:dynamic-routing-vrf-id=100 >> + >> +2. Otherwise, the datapath tunnel key of the logical router is used. >> + >> +**VRF Lifecycle.** >> +By default, ``ovn-controller`` expects the VRF associated with a >> +logical router port to already exist on the chassis, managed by >> +external tooling. To have ``ovn-controller`` create and delete the >> +VRF automatically, set ``dynamic-routing-maintain-vrf`` on the >> +logical router port that is bound to the chassis:: >> + >> + $ ovn-nbctl set Logical_Router_Port lrp-fabric \ >> + options:dynamic-routing-maintain-vrf=true >> + >> +When set, ``ovn-controller`` creates the VRF when the port is bound >> +and deletes it when the port is unbound or dynamic routing is >> +disabled. >> + >> +**VRF Name.** >> +The VRF interface name defaults to ``ovnvrf`` followed by the table >> +ID (e.g., ``ovnvrf100``). Override it with >> +``dynamic-routing-vrf-name``:: >> + >> + $ ovn-nbctl set Logical_Router lr1 \ >> + options:dynamic-routing-vrf-name=myvrf >> + >> +The name must be a valid Linux network interface name (at most 15 >> +characters). >> + >> +Route Nexthop Configuration >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +By default, advertised routes are installed into the VRF as >> +**blackhole** routes. This attracts traffic into OVN for processing >> +without requiring a specific nexthop address. >> + >> +To install routes with a gateway nexthop instead (useful when the >> +routing daemon requires a resolvable nexthop), set:: >> + >> + $ ovn-nbctl set Logical_Router lr1 \ >> + options:dynamic-routing-v4-prefix-nexthop=192.168.1.1 >> + >> + $ ovn-nbctl set Logical_Router lr1 \ >> + options:dynamic-routing-v6-prefix-nexthop=fd00::1 >> + >> +The ``dynamic-routing-v4-prefix-nexthop`` option accepts either an >> +IPv4 or IPv6 address; an IPv6 nexthop for IPv4 prefixes enables >> +RFC 5549-style routing where IPv4 traffic is forwarded over an >> +IPv6-only peering link. The ``dynamic-routing-v6-prefix-nexthop`` >> +option accepts only IPv6 addresses. > > I think this explains the nuances of the nexthop addresses better than > the architecture document or the ovn-nb manpage. In this particular > case, expanding the manpage's explanation of what happens when an IPv6 > prefix is used for dynamic-routing-v4-prefix-nexthop would be useful. > Ack, it's better to update the man page indeed. >> + >> +Route Advertisement Locality >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +When an ``Advertised_Route`` record has a ``tracked_port`` set, >> +``ovn-controller`` adjusts the route metric based on whether the >> +tracked port is locally bound. Routes for locally bound ports >> +receive a higher priority (lower metric), causing the routing daemon >> +to prefer the chassis hosting the workload. >> + >> +The ``dynamic-routing-redistribute-local-only`` option further >> +restricts advertisement: when set to ``true``, ``ovn-controller`` >> +only installs routes on the chassis where the ``tracked_port`` is >> +locally bound. Other chassis do not advertise the route at all:: >> + >> + $ ovn-nbctl set Logical_Router lr1 \ >> + options:dynamic-routing-redistribute-local-only=true >> + >> +This is particularly useful with ``connected-as-host`` to ensure >> +host routes are only announced from the chassis that owns the >> +workload. > > The three paragraphs above are taken almost verbatim from the > architecture document. However, in this document the note about > "connected-as-host" is mentioned after the > "dynamic-routing-redistribute-local-only" option's explanation. In the > architecture document, the "connected-as-host" sentence comes after > the basic "tracked_port" explanation. > > IMO, this document groups the information better than the architecture > document. It makes more sense to indicate how > "dynamic-routing-redistribute-local-only" synergizes with > "connected-as-host". I suggest updating the architecture document. > Ack. >> + >> +This option can also be set per port on the >> +``Logical_Router_Port``:: >> + >> + $ ovn-nbctl set Logical_Router_Port lrp-fabric \ >> + options:dynamic-routing-redistribute-local-only=true >> + >> +Route Learning >> +~~~~~~~~~~~~~~ >> + >> +``ovn-controller`` monitors VRF routing tables for routes installed >> +by the external routing daemon. Routes with a protocol value above >> +``RTPROT_STATIC`` (i.e., routes from dynamic routing protocols like >> +BGP) are learned and recorded as ``Learned_Route`` entries in the >> +Southbound database. Routes installed by ``ovn-controller`` itself >> +(protocol ``RTPROT_OVN``) are excluded from learning. >> +``ovn-northd`` then generates logical flows so that the logical >> +router forwards traffic for these learned prefixes. >> + >> +Learned routes receive lower priority than static routes, ensuring >> +explicitly configured routes always take precedence. >> + >> +To disable route learning on a router:: >> + >> + $ ovn-nbctl set Logical_Router lr1 \ >> + options:dynamic-routing-no-learning=true >> + >> +To disable learning on a specific port (overrides the router-level >> +setting):: >> + >> + $ ovn-nbctl set Logical_Router_Port lrp-fabric \ >> + options:dynamic-routing-no-learning=true >> + >> +Routing Protocol Redirect >> +~~~~~~~~~~~~~~~~~~~~~~~~~ > > The routing-protocol-redirect feature is not in the architecture > document at all. It may be worth adding this section into the > architecture document. > I'll move it there in v2. >> + >> +**Note:** Routing protocol redirect is entirely optional. OVN's >> +dynamic routing works with any control plane configuration. 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. >> + >> +OVN can redirect routing protocol control plane traffic (BGP, BFD) >> +from a logical router port to a logical switch port where an external >> +routing daemon is listening. This allows FRR to peer as if it were >> +using the router port's IP addresses. >> + >> +Configure on the logical router port:: >> + >> + $ ovn-nbctl set Logical_Router_Port lrp-fabric \ >> + options:routing-protocols=BGP,BFD \ >> + options:routing-protocol-redirect=lsp-bgp >> + >> +Where ``lsp-bgp`` is a logical switch port on the peer logical switch >> +that the routing daemon is bound to. Supported protocols: >> + >> +- ``BGP`` --- forwards TCP port 179 >> +- ``BFD`` --- forwards UDP port 3784 >> + >> +For BGP unnumbered mode (advertising IPv4 routes over IPv6 with >> +automatic peer discovery), enable periodic IPv6 Router Advertisements >> +on the logical router port:: >> + >> + $ ovn-nbctl set Logical_Router_Port lrp-fabric \ >> + ipv6_ra_configs:send_periodic=true \ >> + ipv6_ra_configs:address_mode=slaac \ >> + ipv6_ra_configs:max_interval=10 \ >> + ipv6_ra_configs:min_interval=5 >> + >> +The ``max_interval`` and ``min_interval`` values (in seconds) >> +influence how quickly the initial BGP session is established. >> + >> +Port-to-Interface Mapping >> +~~~~~~~~~~~~~~~~~~~~~~~~~ > > port to interface mapping is also not in the architecture document. It > may be worth adding it there. > Ack. >> + >> +When a chassis has multiple links toward the fabric, each running BGP >> +independently, ``dynamic-routing-port-name`` on a logical router port >> +restricts route learning to a specific Linux interface:: >> + >> + $ ovn-nbctl set Logical_Router_Port lrp-fabric1 \ >> + options:dynamic-routing-port-name=lsp-fabric1 >> + >> +``ovn-controller`` resolves the port name to a Linux interface. If >> +the referenced port is bound locally, the interface name is discovered >> +automatically. Otherwise, configure an explicit mapping on the >> +``Open_vSwitch`` table:: >> + >> + $ ovs-vsctl set Open_vSwitch . \ >> + external_ids:dynamic-routing-port-mapping=\ >> + lsp-fabric1=eth1,lsp-fabric2=eth2 >> + >> +Usage Examples >> +-------------- >> + >> +The following examples demonstrate complete configurations for common >> +deployment scenarios. >> + >> +Example: Gateway Router with BGP >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +A centralized gateway router pinned to a specific chassis, peering >> +with an external BGP speaker to advertise connected and static >> +routes. >> + >> +:: >> + >> + External BGP Peer (AS 65001) >> + | >> + | eBGP peering >> + | >> + +---------+---------+ >> + | Gateway Router | (lr-gw, pinned to chassis-1) >> + | 10.0.0.1/24 | dynamic-routing = true >> + +---------+---------+ >> + | >> + +---------+---------+ >> + | Logical Switch | (ls-internal) >> + | 10.0.0.0/24 | >> + +---------+---------+ >> + | >> + VM1 VM2 VM3 >> + >> +**Create the logical topology.** >> +:: >> + >> + $ ovn-nbctl lr-add lr-gw >> + $ ovn-nbctl ls-add ls-internal >> + $ ovn-nbctl ls-add ls-fabric >> + >> + # Router port toward the internal network. >> + $ ovn-nbctl lrp-add lr-gw lrp-internal \ >> + 00:00:00:00:00:01 10.0.0.1/24 >> + $ ovn-nbctl lsp-add-router-port ls-internal \ >> + lsp-internal-to-gw lrp-internal >> + >> + # Router port toward the fabric. >> + $ ovn-nbctl lrp-add lr-gw lrp-fabric \ >> + 00:00:00:00:00:02 192.168.1.1/24 >> + $ ovn-nbctl lsp-add-router-port ls-fabric \ >> + lsp-fabric-to-gw lrp-fabric >> + >> + # Localnet port for physical connectivity. >> + $ ovn-nbctl lsp-add-localnet-port ls-fabric \ >> + lsp-fabric-ln physnet-fabric >> + >> +**Pin the router to a chassis and enable dynamic routing.** >> +:: >> + >> + $ ovn-nbctl set Logical_Router lr-gw \ >> + options:chassis=chassis-1 \ >> + options:dynamic-routing=true \ >> + options:dynamic-routing-redistribute=connected,static \ >> + options:dynamic-routing-vrf-id=100 >> + >> +**Configure VRF management and routing protocol redirect.** >> +:: >> + >> + # Have ovn-controller manage the VRF lifecycle. >> + $ ovn-nbctl set Logical_Router_Port lrp-fabric \ >> + options:dynamic-routing-maintain-vrf=true >> + >> + # Add a logical switch port for the BGP daemon. >> + $ ovn-nbctl lsp-add ls-fabric lsp-bgp >> + $ ovn-nbctl lsp-set-addresses lsp-bgp unknown >> + >> + # Redirect BGP traffic to the BGP daemon port. >> + $ ovn-nbctl set Logical_Router_Port lrp-fabric \ >> + options:routing-protocols=BGP,BFD \ >> + options:routing-protocol-redirect=lsp-bgp >> + >> + # Enable periodic RAs for BGP unnumbered. >> + $ ovn-nbctl set Logical_Router_Port lrp-fabric \ >> + ipv6_ra_configs:send_periodic=true \ >> + ipv6_ra_configs:address_mode=slaac \ >> + ipv6_ra_configs:max_interval=10 \ >> + ipv6_ra_configs:min_interval=5 >> + >> +**Bind the BGP interface on the chassis.** >> +:: >> + >> + # Create an OVS internal port bound to the BGP LSP. >> + $ ovs-vsctl add-port br-int ext0-bgp -- \ >> + set Interface ext0-bgp type=internal \ >> + external-ids:iface-id=lsp-bgp >> + >> + # Place the interface into the VRF. >> + $ ip link set dev ext0-bgp master ovnvrf100 >> + $ ip link set dev ext0-bgp up >> + >> +**Configure FRR on the chassis.** >> +:: >> + >> + configure terminal >> + >> + vrf ovnvrf100 >> + exit-vrf >> + >> + router bgp 65000 vrf ovnvrf100 >> + bgp router-id 192.168.1.1 >> + neighbor ext0-bgp interface remote-as external >> + address-family ipv4 unicast >> + redistribute kernel >> + exit-address-family >> + address-family ipv6 unicast >> + redistribute kernel >> + neighbor ext0-bgp activate >> + exit-address-family >> + >> +Example: Distributed Router with Gateway Ports >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +A distributed logical router with a distributed gateway port, >> +advertising connected, NAT, and load balancer routes. The >> +``local-only`` option ensures host routes are announced only from the >> +chassis hosting the workload. >> + >> +:: >> + >> + External Network >> + | >> + +---------------------+--------------------+ >> + | Distributed LR | >> + | (lr-dist) | >> + | dynamic-routing = true | >> + | NAT: 172.16.0.10 -> 10.0.1.10 | >> + | LB VIP: 172.16.0.100 | >> + +------+----------+----------+-------------+ >> + | | | >> + +------+----+ +---+------+ +-+---------+ >> + | LS-Fabric | | LS-A | | LS-B | >> + | | | 10.0.1/24| | 10.0.2/24 | >> + +-----------+ +----+-----+ +-----+-----+ >> + | | >> + VM-A1 VM-B1 >> + (chassis-1) (chassis-2) >> + >> +**Create the distributed router with a gateway port.** >> +:: >> + >> + $ ovn-nbctl lr-add lr-dist >> + $ ovn-nbctl ls-add ls-a >> + $ ovn-nbctl ls-add ls-b >> + $ ovn-nbctl ls-add ls-fabric >> + >> + # Internal ports. >> + $ ovn-nbctl lrp-add lr-dist lrp-a \ >> + 00:00:00:00:01:01 10.0.1.1/24 >> + $ ovn-nbctl lsp-add-router-port ls-a lsp-a-to-lr lrp-a >> + >> + $ ovn-nbctl lrp-add lr-dist lrp-b \ >> + 00:00:00:00:01:02 10.0.2.1/24 >> + $ ovn-nbctl lsp-add-router-port ls-b lsp-b-to-lr lrp-b >> + >> + # Distributed gateway port. >> + $ ovn-nbctl lrp-add lr-dist lrp-gw \ >> + 00:00:00:00:02:01 172.16.0.1/24 >> + $ ovn-nbctl lsp-add-router-port ls-fabric \ >> + lsp-fabric-to-lr lrp-gw >> + >> + # Configure HA chassis group for the gateway port. >> + $ ovn-nbctl ha-chassis-group-add ha-gw >> + $ ovn-nbctl ha-chassis-group-add-chassis ha-gw \ >> + chassis-1 10 >> + $ ovn-nbctl ha-chassis-group-add-chassis ha-gw \ >> + chassis-2 5 >> + $ GRP=$(ovn-nbctl --bare --columns=_uuid \ >> + find HA_Chassis_Group name=ha-gw) >> + $ ovn-nbctl set Logical_Router_Port lrp-gw \ >> + ha_chassis_group=$GRP >> + >> +**Add NAT and load balancer.** >> +:: >> + >> + $ ovn-nbctl lr-nat-add lr-dist dnat_and_snat \ >> + 172.16.0.10 10.0.1.10 >> + $ ovn-nbctl lb-add lb-web 172.16.0.100:80 \ >> + 10.0.1.10:8080,10.0.2.10:8080 >> + $ ovn-nbctl lr-lb-add lr-dist lb-web >> + >> +**Enable dynamic routing with NAT and LB redistribution.** >> +:: >> + >> + $ ovn-nbctl set Logical_Router lr-dist \ >> + options:dynamic-routing=true \ >> + options:dynamic-routing-redistribute=connected,nat,lb \ >> + options:dynamic-routing-vrf-id=200 >> + >> + $ ovn-nbctl set Logical_Router_Port lrp-gw \ >> + options:dynamic-routing-maintain-vrf=true \ >> + options:dynamic-routing-redistribute-local-only=true >> + >> +With ``local-only`` enabled, NAT and LB host routes are only >> +advertised from the chassis where the associated workload is bound, >> +ensuring optimal traffic forwarding. >> + >> +**Set up routing protocol redirect and FRR** (same pattern as the >> +gateway router example above). >> + >> +Verification and Troubleshooting >> +-------------------------------- >> + >> +Checking OVN State >> +~~~~~~~~~~~~~~~~~~ >> + >> +Verify that ``ovn-northd`` has populated the ``Advertised_Route`` >> +table:: >> + >> + $ ovn-sbctl list Advertised_Route >> + >> +Check for learned routes from external peers:: >> + >> + $ ovn-sbctl list Learned_Route >> + >> +Checking the VRF and Kernel Routes >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> + >> +Verify the VRF exists and is up:: >> + >> + $ ip link show type vrf >> + >> +List routes in the VRF table. Routes marked ``proto ovn`` were >> +installed by ``ovn-controller``; routes with other protocol values >> +(e.g., ``proto bgp``) were learned from the routing daemon:: >> + >> + $ ip route show table 100 >> + >> +Checking FRR State >> +~~~~~~~~~~~~~~~~~~ >> + >> +Verify BGP peering is established:: >> + >> + $ vtysh -c "show bgp summary" >> + >> +Check received and advertised routes:: >> + >> + $ vtysh -c "show bgp ipv4 unicast" >> + $ vtysh -c "show bgp ipv6 unicast" >> + >> +Best Practices >> +-------------- >> + >> +**Use explicit VRF IDs.** >> +Set ``dynamic-routing-vrf-id`` rather than relying on the datapath >> +tunnel key. Explicit IDs make the VRF configuration predictable and >> +easier to reference in FRR configurations and monitoring. >> + >> +**Use local-only for host routes.** >> +When using ``connected-as-host`` redistribution, combine it with >> +``dynamic-routing-redistribute-local-only=true`` to ensure host >> +routes are only announced from the chassis that owns the workload. >> +This provides optimal traffic forwarding and avoids unnecessary >> +traffic tromboning. >> + >> +**Let ovn-controller manage VRFs when possible.** >> +Set ``dynamic-routing-maintain-vrf=true`` on the logical router port >> +to let ``ovn-controller`` handle VRF creation and deletion. This >> +simplifies chassis provisioning and ensures VRF lifecycle matches >> +port binding. >> + >> +**Configure BFD for fast failure detection.** >> +Include ``BFD`` in the ``routing-protocols`` option and enable BFD >> +in FRR for sub-second failure detection. This significantly improves >> +convergence time compared to relying on BGP hold timers alone. >> + >> +**Use per-port redistribution for multi-homed setups.** >> +When a chassis has multiple fabric links, use per-port >> +``dynamic-routing-redistribute`` and ``dynamic-routing-port-name`` to >> +control exactly which routes are advertised and learned on each link. >> + >> +See Also >> +-------- >> + >> +- :doc:`/topics/dynamic-routing/architecture` --- Architecture and >> + internal design of the dynamic routing feature. >> + >> +- ``ovn-nb``\(5) --- Full reference for all ``Logical_Router`` >> + and ``Logical_Router_Port`` dynamic routing options. >> + >> +- ``ovn-sb``\(5) --- Documentation of the ``Advertised_Route`` >> + and ``Learned_Route`` tables. >> + >> +- ``ovn-controller``\(8) --- Controller-side configuration options >> + including ``dynamic-routing-port-mapping``. >> diff --git a/Documentation/topics/dynamic-routing/index.rst >> b/Documentation/topics/dynamic-routing/index.rst >> index eb61afb4a3..d53225609f 100644 >> --- a/Documentation/topics/dynamic-routing/index.rst >> +++ b/Documentation/topics/dynamic-routing/index.rst >> @@ -29,3 +29,4 @@ Dynamic Routing >> :maxdepth: 2 >> >> architecture >> + configuration >> -- >> 2.54.0 >> >> _______________________________________________ >> dev mailing list >> [email protected] >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> > Thanks, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
