Hello,
On 11/25/25 14:52, Dumitru Ceara via dev wrote:
Hi Felix, Frode, Martin,
I'm not sure others are using the OVN dynamic-routing feature yet but I
know you guys might be.
Looking at how ovn-controller learns routes from the VRF table it
monitors it currently just skips all the link-local prefixes and routes
that OVN installed:
https://github.com/ovn-org/ovn/blob/b1fa54864bba7669ec81a710852a462101f3b280/controller/route-exchange-netlink.c#L216-L222
static void
handle_route_msg(const struct route_table_msg *msg, void *data)
{
[...]
/* This route is not from us, so we learn it. */
if (rd->rtm_protocol != RTPROT_OVN) {
if (!handle_data->learned_routes) {
return;
}
if (prefix_is_link_local(&rd->rta_dst, rd->rtm_dst_len)) {
return;
}
This to me sounds a bit counter intuitive (also based on the discussions
that happened at OVS+OVN'25 last week). The feature is about learning
dynamic routes (learned through BGP/OSPF/etc), why would OVN learn
anything else.
I suspect the != SELF condition was originally put there with the sole purpose
of avoiding the ovn-controller from learning the routes itself had announced.
E.g., if the routing protocol daemon learns routes dynamically it will
install them with rtm_protocol > RTPROT_STATIC (e.g., RTPROT_ZEBRA for
FRR). All other routes are configured by the user.
The different routing protocol suites use different values for rtm_protocol, and
AFAICT all of them are indeed > RTPROT_STATIC.
We're experimenting with BIRD which is using RTPROT_BIRD.
As a side note, we discovered that the feature actually can be used to learn IPv6
routes discovered by kernel or systemd through IPv6 Router Advertisement. Both
the kernel and systemd implementation make use of RTPROT_RA for those routes,
which would also keep working if we use > RTPROT_STATIC as threshold.
So my question is: why learn the "other routes" in OVN? If the user
wishes that OVN uses them they could just configure
OVN.NB.Logical_Router_Static_Route records.
Would such a change be OK for your use cases?
Having a check for rtm_protocol > RTPROT_STATIC seems reasonable to me, avoids
yet another configuration option, and works for our use case.
--
Frode Nordahl
Thanks,
Dumitru
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
