Yadan Fan <ydfan@xxxxxxxx> wrote: > On 9/30/24 17:29, Florian Westphal wrote: > > Hannes Reinecke <hare@xxxxxxxxxx> 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.
