On 6/3/26 11:56 PM, Martin Kalcok wrote: > Hi Dumitru and Ales, > Hi Martin, Ales,
Thanks for the review! > thanks for the doc update, the recommendations look sound to me. I have > just one nit below that may or may not be worth addressing. Otherwise > > Acked-by: Martin Kalcok <[email protected]> > > > On 03/06/2026 11:07, Ales Musil via dev wrote: >> On Mon, Jun 1, 2026 at 3:50 PM 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 and >>> in the architecture document. The added value is some more >>> details and a few worked examples. >>> >>> The guide includes: >>> - Two worked examples: gateway router with BGP and >>> distributed router with gateway ports. >>> - Verification/troubleshooting commands and best practices. >>> >>> Also update the architecture document with information that >>> was missing: >>> - Add hub-spoke to the redistribution options list. >>> - Fix VRF table ID description to list the exact excluded >>> values (0, 252, 253, 254, 255, 4294967295). >>> - Add Routing Protocol Redirect section. >>> - Add Port-to-Interface Mapping section. >>> - Improve connected-as-host + local-only grouping. >>> >>> Also expand the dynamic-routing-v4-prefix-nexthop description >>> in ovn-nb.xml to explain the RFC 5549 use case. >>> >>> Reported-at: https://redhat.atlassian.net/browse/FDP-3119 >>> Assisted-by: Claude Opus 4.6, Claude Code >>> Signed-off-by: Dumitru Ceara <[email protected]> >>> --- >>> v2: >>> - Addressed Mark's comments: >>> - Renamed configuration.rst to configuration-examples.rst >>> and stripped the configuration reference sections that >>> duplicated the architecture document. The new document >>> focuses on worked examples with explanatory prose, >>> verification commands, and best practices. >>> - Added hub-spoke to the redistribution options list in >>> architecture.rst. >>> - Fixed VRF table ID accuracy in architecture.rst to list >>> all excluded values (0, 252-255, 4294967295) matching >>> the TABLE_ID_VALID macro. >>> - Improved connected-as-host + local-only grouping in >>> architecture.rst. >>> - Added Routing Protocol Redirect section to >>> architecture.rst. >>> - Added Port-to-Interface Mapping section to >>> architecture.rst. >>> - Expanded dynamic-routing-v4-prefix-nexthop description >>> in ovn-nb.xml with RFC 5549 explanation. >>> --- >>> Documentation/automake.mk | 1 + >>> .../topics/dynamic-routing/architecture.rst | 63 ++- >>> .../configuration-examples.rst | 366 ++++++++++++++++++ >>> .../topics/dynamic-routing/index.rst | 1 + >>> ovn-nb.xml | 8 +- >>> 5 files changed, 434 insertions(+), 5 deletions(-) >>> create mode 100644 >>> Documentation/topics/dynamic-routing/configuration-examples.rst >>> >>> diff --git a/Documentation/automake.mk b/Documentation/automake.mk >>> index aa286ebd9c..91582163e1 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- >>> examples.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/architecture.rst >>> b/Documentation/topics/dynamic-routing/architecture.rst >>> index e7c968330f..b436d4aa99 100644 >>> --- a/Documentation/topics/dynamic-routing/architecture.rst >>> +++ b/Documentation/topics/dynamic-routing/architecture.rst >>> @@ -288,6 +288,9 @@ accepts a comma-separated list of the following >>> values: >>> - ``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. >>> >>> @@ -331,6 +334,11 @@ 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 >>> ----------------- >>> >>> @@ -391,8 +399,9 @@ 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``). >>> + 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``). >>> >>> 2. The tunnel key of the logical router datapath, used as a fallback >>> when ``dynamic-routing-vrf-id`` is not configured. >>> @@ -423,6 +432,56 @@ 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 (RFC 5549), 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. > > The automatic on-link peer discovery based on RAs isn't part of any BGP- > related RFC AFAIK. However many of the BGP implementations happen to > support it this way. The above paragraph about the automatic RAs is > definitely useful advice, I'd just maybe squeeze in a small disclaimer > that auto-discovery needs to be supported by the BGP daemon on the other > end. > Good point, I'll update this part and send a v3 (also addressing Mark's comments). Regards, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
