On Mon, Feb 14, 2022 at 10:32 AM Vladislav Odintsov <odiv...@gmail.com>
wrote:
>
> Hi Dumitru,
>
> I’ve got a general question about what the logical topology you’d like to
implement.
>
> Also, please see inline comments.
>
>
> Regards,
> Vladislav Odintsov
>
> > On 14 Feb 2022, at 15:51, Dumitru Ceara <dce...@redhat.com> wrote:
> >
> > Hi Vladislav,
> >
> > I was looking at what options we have in OVN to implement a VRF-like
> > behavior and then remembered you had worked on the multiple routing
> > table feature.
> >
Hi Dumitru, during the code review it has been clarified that this
RouteTable feature is NOT for VRF-like use cases. VRF-like use cases can be
directly implemented with multiple LRs in OVN.
Thanks,
Han
> > On 11/19/21 17:07, Vladislav Odintsov wrote:
> >> This patch extends Logical Router's routing functionality.
> >> Now user may create multiple routing tables within a Logical Router
> >> and assign them to Logical Router Ports.
> >>
> >> Traffic coming from Logical Router Port with assigned route_table
> >> is checked against Logical_Router_Static_Routes with same route_table
> >> field value and routes to connected networks. If no route_table option
> >> is set to the LRP, routes' lookup is done agains routes with no
> >> route_table field value ("", empty string) and against routes to
> >> connected networks.
> >
> > I was a bit surprised by the fact that if there's no static route with
> > the same route_table value as the ingress router port we go ahead and
> > match against all connected networks, regardless of their ports' route
> > tables.
>
> The current behaviour is expected — earlier while code review I’ve
described it’s similar
> to AWS/GCP VPC lookup logic: the "local" route (route to connected
networks/subnets) is present
> always and can’t be deleted or modified.
> This means that "connected" routes (including learned routes from other
AZs, which
> have "connected" origin) are installed in the routing table regardless of
their `route_table` value.
> But the user may create more specific static route if he/she needs it and
this route doesn’t break
> necessary connectivity.
>
> > Does it make sense to change this and perform longest prefix match in
> > general, always matching on route_table?
>
> I can’t imagine how to easy support current behaviour with such change. I
mean how
> to force a match against all connected routes regardless of routing table.
> The only one option I see is to add an option for LR, which configures a
mode of
> local routes match: with or without route_table value respect.
> >
> > In this case connected routes could inherit the route_table value from
> > the corresponding router ports where they're defined.
> >
> > Would that break your use case?
>
> Please, see previous comment.
>
> >
> > Thanks,
> > Dumitru
> >
> > _______________________________________________
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
> _______________________________________________
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
