On 12/18/24 2:30 PM, Dumitru Ceara wrote:
> On 11/13/24 12:04 PM, Lorenzo Bianconi wrote:
>> With respect to the previous implementation, OVN is now tracking and
>> flushing ECMP next-hop ct entries with the next-hop mac address instead
>> of using an identification number committed by ovn-northd since the previous
>> approach had some limitations when the traffic is initialized from outside
>> the ovn cluster. This series is introducing a way to periodically resolve L2
>> address of the configured next-hops.
>> Please note IPv6 is not currently supported and it will be added before 
>> posting
>> a formal series. The goal of this series is just to collect feedbacks about 
>> the
>> proposed approach.
>>
> 
> Hi Lorenzo,
> 
> I reviewed the patches and shared some feedback but I also wanted to
> share that with this patch applied the ovn-kubernetes e2e tests that
> exercise the ecmp-symmetric-reply functionality fail:
> 
> https://github.com/dceara/ovn-kubernetes/actions/runs/12392477221/job/34592485272
> 
> Summarizing 2 Failures:
>   [FAIL] External Gateway With annotations e2e multiple external gateway
> stale conntrack entry deletion validation Namespace annotation: Should
> validate conntrack entry deletion for TCP/UDP traffic via multiple
> external gateways a.k.a ECMP routes [It] IPV4 udp
> 
> /home/runner/work/ovn-kubernetes/ovn-kubernetes/test/e2e/external_gateways.go:785
>   [FAIL] External Gateway With annotations e2e multiple external gateway
> stale conntrack entry deletion validation Namespace annotation: Should
> validate conntrack entry deletion for TCP/UDP traffic via multiple
> external gateways a.k.a ECMP routes [It] IPV4 tcp
> 
> /home/runner/work/ovn-kubernetes/ovn-kubernetes/test/e2e/external_gateways.go:785
> 
> This needs to be investigated.  Maybe the tests do something wrong or
> maybe the patch series itself has some issues.

After some debugging we found that the problem is that ovn-kubernetes
has a bug.  Assuming it had configured an ECMP symmetric reply route
with multiple paths, all updates to that route (path removal) actually
translate to _independent_ transactions that:
1. remove ALL paths from the NB
2. re-add remaining paths to the NB

Obviously, if ovn-northd runs between transaction "1" and "2", the NB
doesn't contain any ECMP paths anymore so ovn-controller will flush
conntrack.

IMO this has to be fixed in ovn-kubernetes but until that happen we
can't ship the feature in OVN (or at least we can't ship it enabled by
default).

CCing some ovn-kubernetes maintainers.

Regards,
Dumitru

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to