Re: [PATCH] nf_conntrack_proto_udp: do not accept packets with IPS_NAT_CLASH

[Florian Westphal <fw@strlen.de>]

Yadan Fan <ydfan@suse.com> wrote:
> On 9/30/24 17:29, Florian Westphal wrote:
> > Hannes Reinecke <hare@kernel.org> wrote:
> > > Commit c46172147ebb changed the logic when to move to ASSURED if
> > > a NAT CLASH is detected. In particular, it moved to ASSURED even
> > > if a NAT CLASH had been detected,
> > 
> > I'm not following.  The code you are removing returns early
> > for nat clash case.
> > 
> > Where does it move to assured if nat clash is detected?
> > 
> > > However, under high load this caused the timeout to happen too
> > > slow causing an IPVS malfunction.
> > 
> > Can you elaborate?
> 
> Hi Florian,
> 
> We have a customer who encountered an issue that UDP packets kept in
> UNREPLIED in conntrack table when there is large number of UDP packets
> sent from their application, the application send packets through multiple
> threads,
> it caused NAT clash because the same SNATs were used for multiple
> connections setup,
> so that initial packets will be flagged with IPS_NAT_CLASH, and this snippet
> of codes
> just makes IPS_NAT_CLASH flagged packets never be marked as ASSURED, which
> caused
> all subsequent UDP packets got dropped.

I think the only thing remaining is to rewrite the commit message to
say that not setting assured will drop NAT_CLASH replies in case server
is very busy and early_drop logic kicks in.