Comment 2 for bug 2003842

Revision history for this message
Dmitrii Shcherbakov (dmitriis) wrote :

Hi Rodolfo,

Yes, I understand the unbound port logic with routed provider networks is there to defer IP allocation until the moment when the segment (and its subnet) is known.

Do you think this LP is "invalid" because it's part of a new feature rather than a bug?

I have seen a spec merged for floating IPs on routed provider networks which implies attaching routers to routed provider networks:

https://review.opendev.org/c/openstack/neutron-specs/+/486450/17/specs/victoria/routed-networks-floating-ips.rst
https://review.opendev.org/c/openstack/neutron/+/669395/
https://review.opendev.org/q/topic:bug%252F1667329

So this would be a scenario in presence of the L3 leaf & spine topology but requires a more advanced integration & dynamic routing between the fabric and OpenStack.

I understand if the functionality like this would make sense to add during a new feature development (potentially separately for ML2/OVS and ML2/OVN) for the referenced spec.

Where I was going with this is the following: OVN has built-in reachability checks [**] for next-hops of routes added to the router (Logical_Router_Static_Routes NB table) so even if there are static routes added to a router OVN will be able to determine which ones to actually have processing for in the form of logical flows - so we won't get blackholing of traffic because of unreachable next-hops of extra routes or ECMP default routes with next-hops on different segments.

OVN also includes `ecmp-symmetric-reply` functionality (not yet used in Neutron) that utilizes conntrack which could be enabled for avoiding asymmetric replies in presence of ECMP routes (for the non-distributed routing case since this relies on conntrack):

https://github.com/ovn-org/ovn/blob/v22.12.0/ovn-nb.xml#L3312-L3319
https://github.com/ovn-org/ovn/commit/4fdca656857d4a5caeec35ae813888cb9e403e5e

But before any of this can be used, the fundamental problem is the lack of an added inferred default route which I wanted to have a record of in the form of this bug.

=====
[**]

When OVN adds logical flows for routes (whether ECMP or not)

https://github.com/ovn-org/ovn/blob/1207ae69f358c515f01a1c4451864cad6ca23406/northd/northd.c#L10377-L10389 build_static_route_flow
https://github.com/ovn-org/ovn/blob/1207ae69f358c515f01a1c4451864cad6ca23406/northd/northd.c#L10228-L10275 build_ecmp_route_flow

it does an overlap and reachability check - if a next-hop of a route is not reachable via a port (based on its assigned IP and direct connectivity of a subnet), logical flows for it are not added.

https://github.com/ovn-org/ovn/blob/1207ae69f358c515f01a1c4451864cad6ca23406/northd/northd.c#L9997-L10016 (find_static_route_outport)

This is similar to selective addition of routes to the routing table of an L3 namespace with ML2/OVS.