On 1/19/26 8:04 AM, Ales Musil wrote: > > > On Fri, Dec 19, 2025 at 12:33 PM Matteo Perin via dev > <[email protected] <mailto:[email protected]>> wrote: > > The OVN native route learning code added the LRP dynamic-routing-port-name > and accompanying dynamic-routing-port-mapping key in the local OVS table. > > When the routing-protocol-redirect option is in use on an LRP, the need to > manually set the dynamic-routing-port-name and > dynamic-routing-port-mapping > options can be removed if OVN can support looking up the veth pair bound > to > the LSP referred to, when using veth pairs to connect routing daemons to > OVN. > > This commit introduces this capability: when the routing-protocol-redirect > option is configured on a LRP to redirect routing protocol traffic to a > LSP, > and that LSP is bound to a veth interface, ovn-controller will now > automatically > discover the peer interface name and uses it for dynamic route learning. > > The discovery happens at port binding time in the route exchange code > path. > To do this, the ethtool ioctl interface is leveraged to verify the bound > interface is a veth and, in that case, retrieve the peer ifindex and > relative > iface name. > This means that the discovery feature will only be available on Linux > platforms. > Also, there is a fallback to learning from all interfaces (base case) if > discovery fails for any reason. > > This will simplify dynamic routing deployments by automating the interface > mapping configuration that was previously required for veth-based routing > daemon integrations. > > Signed-off-by: Matteo Perin <[email protected] > <mailto:[email protected]>> > --- > First of all, sorry everyone for the spam of emails I sent to forward this > patch, since this is my first contribution attempt I am still finding my > way around the project patch proposal pipeline. > > This addition to the OVN controller is an effort to remove the need of > additional configuration when using the routing-protocol-redirect with > one of the most common network setups used along routing daemons. > > The veth peer discovery is currently made thought an ioctl to ethtool and > this, unfortunately, makes this added feature platfom-dependent. > As an alternative, I also though about moving the discovery part to OVS > (this will not remove the linux kernel dependency, but it will make it > part of the already in-place OVS linux netdev layer). > I did not go through with this idea since it seemed to require moving too > many things around and adding space to store peer information to the > Interface table in OVSDB, and this seemed way too overkill for the limited > scope of this feature. > > By my initial investigation, the refactoring using this approach would > require: > - Extending OVS rtnetlink support to parse IFLA_LINK attribute (containing > veth peer ifindex info). > - Exposing it via OVSDB Interface:external_ids:peer_ifindex, or similar > - OVN controller then reads peer info from OVS table and calls > if_indextoname() > to get interface name. > > Would this (more "disruptive") technique be more preferable than having > the > discovery management in a very specific path in the OVN controller? If so, > I can rework the patch taking into account your suggestions. > > > Hello Matteo, > > thank you for the patch. I'm sorry I didn't reply earlier. To me it seems > like it would be better to utilize what ovs already has. If you take a look > at the way how "status" column is populated, we already call ethtool > there so it would be that hard to call it twice once with "ETHTOOL_GDRVINFO" > which ovs already does, then with "ETHTOOL_GSTATS". Then we could > add the "peer_ifindex" into the "status". This is part of > "netdev_linux_get_status()". > Having that we could easily check the status column, does that sound > reasonable > to you? > > One note about "ETHTOOL_GSTATS" the hardcoded value 21 for the array > is not correct. It should be allocated to whatever the "ETHTOOL_GDRVINFO" > returns in "n_stats". > > Ccing Ilya if he has any objections or other idea how to extend ovs > capabilities.
We can do that from OVS side. But we need to be careful to avoid issuing the commands unnecessarily, i.e. we need to cache the results to avoid blocking inside the kernel when we have a lot of ports. But it's not fully clear to me, how we would detect that the value changed in the kernel. This can potentially happen when the peer is moved in and out a different namespace. It's hard to keep this information up to date. Any ideas? Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
