On 10/9/24 00:45, Florian Westphal wrote:
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.
Thanks, I will submit a new patch with the new commit message
continuing the work from Hannes.
