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:
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):
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)
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.
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 /review. opendev. org/c/openstack /neutron/ +/669395/ /review. opendev. org/q/topic: bug%252F1667329
https:/
https:/
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 /github. com/ovn- org/ovn/ commit/ 4fdca656857d4a5 caeec35ae813888 cb9e403e5e
https:/
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/1207ae69f3 58c515f01a1c445 1864cad6ca23406 /northd/ northd. c#L10377- L10389 build_static_ route_flow /github. com/ovn- org/ovn/ blob/1207ae69f3 58c515f01a1c445 1864cad6ca23406 /northd/ northd. c#L10228- L10275 build_ecmp_ route_flow
https:/
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/1207ae69f3 58c515f01a1c445 1864cad6ca23406 /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.