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