On 9/16/25 11:33 AM, Dumitru Ceara wrote: > Hi Jakub, > > On 9/10/25 10:43 PM, Jakub Libosvar wrote: >> >> >>> On Sep 9, 2025, at 9:59 AM, Dumitru Ceara <[email protected]> wrote: >>> >>> Hi Jakub, >>> >>> Thanks for the bug report and for the fix! Sorry for the delay in >>> reviewing this. >>> >>> On 7/28/25 7:52 PM, Jakub Libosvar via dev wrote: >>>> The logical router port for outport of a logical router was calculated >>>> based on the subnet matching of LRPs on the given LR. This doesn't work >>>> in case IPv6 local-link addresses are used. >>>> >>>> The patch introduces a generic function that calculates outport by >>>> strict matching on the nexthop address. This function is used when >>>> generating the logical flow from the logical router policy. >>>> >>>> This problem becomes more complex when a router is connected to >>>> complicated topology where the L2 domain is stretched over multiple >>>> logical switches or even localnet ports. This complex solution is not >>>> included in this patch and will be part of a followup patch. >>>> >>> >>> What worries me a bit about this approach is that, in general, the only >>> restriction for mac addresses is that they need to be unique in the L2 >>> domain they're used in. >>> >>> Let's consider a topology that's not covered by the cases you tested below: >>> >>> R1 ------- R2 -------- R3 >>> netA netB >>> >>> We have two IP networks, netA and netB. >>> >>> In theory R1 and R3 could have the same MAC address, e.g., >>> 00:00:00:00:00:01 and that shouldn't cause any routing issues. The only >>> constraints are: >>> - R1 and R2 should have different MAC addresses on netA >>> - R2 and R3 should have different MAC addresses on netB >> >> I think if there are two same addresses then it’s a problem with the >> CMS, it should not be using same MACs as they should be unique as >> per EUI-48. In general, the problem you’re describing is not tied to >> a MAC address but to “same IP” problem. Same can happen also if netA >> and netB use the same IP range and R1 and R2 LRPs have the same IP. >> > > In my opinion, netA and netB having the same IP range (overlapping > subnets) is a misconfiguration and won't work anyway in OVN. > >>> >>> Now, if we add a policy on R2: >>> if dst == 2001::/64 then reroute 0000:00ff:fe00:0001 >>> >>> Then ovn-northd still can't choose any port. Arguably the policy is >>> incorrect though, because it's ambiguous. So, in order to fix that, >>> what we could do is add support for "output_port" for >>> Logical_Router_Policy (like we have for Logical_Router_Static_Route). >>> >>> The CMS (configuring the policy) should always be able know which >>> output_port to configure in these cases? >> >> yes, output_port works for my use case too and we know what >> output_port we want to set when we’re creating the policy. >> >> For me it is fine, just thinking out loud if a mechanism exists in >> northd that can find the “right” output_port then it should also >> consider local-link-addresses too. The ambiguity, as I tried to >> explain above, also happens with colliding IPs, not necessarily same >> MAC addresses. > > Right, I still think the best we can do in these cases is let the CMS > choose (through output_port). > >>> >>>> Same problem seems to exist when finding the outport from the logical >>>> router static route. The function responsible for finding the right LRP >>>> is genereic enough so it can be re-used later for the static route too >>>> in another followup patch. >>> >>> As mentioned above, I think the CMS should probably be using >>> "output_port" for the static routes in these cases. From the man page >>> of "output_port": >>> >>> 'When this is specified and there are multiple IP addresses on the >>> router port and none of them are in the same subnet of "nexthop", OVN >>> chooses the first IP address as the one via which the "nexthop" is >>> reachable.' >>> >>> If OVN would support output_port for policies too, would that be enough >>> for the use case you're targetting? >> >> Yes :) >> > > OK, I'll work on a patch that adds that. >
Posted here: https://patchwork.ozlabs.org/project/ovn/patch/[email protected]/ Thanks, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
