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

Reply via email to