On 2/27/25 7:54 PM, Mark Michelson wrote: > From: Xavier Simonart <[email protected]> > > A) routed traffic and l3gw > B) non routed traffic and vxlan. > > Routed traffic and l3gw > ======================= > Configuration: p1 - LS1 - Router - LS2 - p2, with p1 on hv1, p2 on hv2 and > Router > a l3gw chassis on hv2. > If p1 sends an over-mtu packet towards p2, this will cause a > icmp_type=3,icmp_code=4 > being received from the tunnel interface. It will be received back in LS1 from > LS1-router (l3gateway) port. > If some ACLs are present, icmp was sent to ct, resulting in ct_inv and packet > being dropped. > > Before this patch and patch [1], l3gateway ports were ** sometimes ** > considered as > related lports. There was no code adding such ports to related_lports ssets, > but > L3gateway ports are sometimes created as patch ports (which are > related_lports) > and then modified to l3gateway ports. > Until patch [1], such a port type modification did not cause the port to be > removed > from the sset. Hence, remote l3gateway ports were sometimes considered as > related ports, > and proper flows were installed to skip ct. > > This means that before this patch and before patch [1] > - After a recompute, "remote" l3gateway ports were not considered as related > ports and packet being dropped in above use case. > - in I+P, if the l3gateway port was directly created (i.e. in one sb > transaction, w/o going through a patch port), it was also not in the > related_lports set, resulting in a similar packet drop in the above use > case. > > Patch [1] always consideres "remote" l3gateway ports were not related_ports, > in both > I+P and recompute cases. In that sense, it made the behaviour more > consistent, icmp > type=3, code=4 was always dropped in this scenario. > > With patch [1] and this patch, remote l3gateway ports are still non related > ports, but ct > is skipped for icmp type=3, code=4. > > Non routed traffic and vxlan. > ============================= > Configuration: p1 - S1 - p2 with p1 on hv1 and p2 on hv2, and vxlan tunnel. > > If p1 sends ovn-mtu packet towards p2, an icmp 'packet too big' (type=3, > code=4), > generated by the kernel, is received on the tunnel interface. It's being > handled > by table CT_ZONE_LOOKUP with outport=p2 and inport=0. Hence table > CT_ZONE_LOOKUP > will not load any ct_zone. > Later on this packet is sent to conntrack, resulting in ct_inv flag set and > packet being dropped. > There is no need to send such a icmp 'packet too big' to ct in ingress > datapath. > This patch adds two flows to skip ct for such a packet. > > [1] a680c96465cd > > Fixes: a680c96465cd ("controller: Nonvif related lports handling.") > Fixes: 3faadc76ad71 ("northd: Fix pmtud for non routed traffic.") > Reported-at: https://issues.redhat.com/browse/FDP-685 > > Signed-off-by: Mark Michelson <[email protected]> > ---
Similar to the comment I had on patch 1/3 I think we should maintain the DCO (and other tags) from the original commit and it would also be nice to include the "cherry picked from commit .." line too. Thanks, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
