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.
Issue just disappeared after deleting this portion.
Yadan,
SUSE L3
This patch revert part of that patch, as for NAT CLASH we
should not move to ASSURED at all.
nf_ct_refresh_acct(ct, ctinfo, skb, extra);
- /* never set ASSURED for IPS_NAT_CLASH, they time out soon */
- if (unlikely((status & IPS_NAT_CLASH)))
- return NF_ACCEPT;
-
/* Also, more likely to be important, and not a probe */
if (stream && !test_and_set_bit(IPS_ASSURED_BIT, &ct->status))
nf_conntrack_event_cache(IPCT_ASSURED, ct);
AFAICS with this patch we now do move to assured unconditionally?
The changelog and patch seem contradictory to me.
