On 2025-01-02 1:31 PM, Ilya Maximets wrote: > On 12/18/24 23:34, Han Zhou wrote: >> Currently the ovs-router doesn't read kernel IP rules, so when there are >> needs to route based on source IP address there is no way to achieve it >> in the ovs-router. This patch provides a convenient way to achieve >> source based routes by providing an optional arg to the ovs-appctl >> ovs/router/add command 'src_prefix=ip/mask', to allow users to specify >> matching on src in addition to dst for user-added routes. >> >> Signed-off-by: Han Zhou <hz...@ovn.org> >> --- >> lib/ovs-router.c | 151 ++++++++++++++++++++++++++++++++++++-------- >> tests/ovs-router.at | 71 ++++++++++++++++++++- >> 2 files changed, 191 insertions(+), 31 deletions(-) > > Hi, Han. This is an interesting feature and certainly a gap between > the kernel and userpsace tunnel support. But I'm a little concerned > about having the implementation different from the kernel and not > being able to cache the source routes from the kernel. >
Hi Ilya. Giving this thread a little bit of "second wind", I'd like to ask your advice on the multiple router tables approach that you suggested and check if my understanding is correct. > It might be better to add support for multiple tables in the router and > actually dump other tables from the kernel, but only ones referenced > from the default one or the other already referenced table (to avoid > performance issues when BGP is running, for exmaple). So by "only ones referenced" you mean only the tables that are referenced by at least one rule from `ip rule show`, right? And if Routing Policy Database (RPDB) is updated in the kernel - by adding new rules or removing existing ones, thereby (un-)referencing a table - the OVS router table cache would need to be updated as well I suppose. Additionally, similar to the kernel's approach, OVS would require an equivalent of the RPDB to perform advanced route lookups, such as those based on a source address. > This way we could actually cache kernel routes instead of creating a > custom syntax and diverge from the kernel implementation. > > What do you think? > If this seems like the right direction, I have a few more questions: * if a basic multi-table router was implemented in OVS with a more limited initial set of route matching capabilities compared to the kernel, would it still be considered a valuable feature? For instance, if the RPDB in OVS only supported source IP matching with a custom table lookup action, and no other matching/action types (like matching on iif, oif, or nat actions), so OVS would cache only the additional kernel rules/routes of the supported types. * there might be special router tables in the kernel, such as the l3mdev-table when VRF is configured, that may need to be excluded from caching in OVS. * enabling multi-table routing support in OVS by default or having it controlled by an 'other_config' flag - what would be a better way to introduce this feature? Thanks, Dima. > Best regards, Ilya Maximets. > _______________________________________________ > dev mailing list > d...@openvswitch.org _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
