Re: [RFC] netfilter: conntrack: early_drop eviction limitation under sparse table configurations (max << buckets)

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Fri, Nov 06, 2026 at 04:23:08PM +0530, S.S.Vikash wrote:
> Hi,
> 
> While investigating connection tracking exhaustion behavior under a spoofed
> SYN flood, I observed that the effectiveness of early eviction in
> net/netfilter/nf_conntrack_core.c:early_drop() degrades significantly when
> nf_conntrack_max is configured to be substantially smaller than
> nf_conntrack_buckets.
> 
> Setup & Reproduction:
> - Host kernel: Linux 6.14 (Proxmox host)
> - Workload: Conntrack table saturated with non-ASSURED, unreplied TCP
>   connections generated by spoofed SYN traffic.
> - Test: Verifying whether an inbound, legitimate SSH connection can be
>   established while the table is at capacity.
> 
> Results observed:
> 
> nf_conntrack_max       |   nf_conntrack_buckets     |     New SSH Connection
> ------------------------------+-----------------------------------+----------------------------------
>               4096              |              262144
> |         Failed (drops)
>               4096              |              4096
>   |         Established
>               65536            |              262144
> |         Established
>               262144          |              262144                  |
>         Established
> 
> Root Cause Analysis:
> In early_drop(), the kernel examines at most NF_CT_EVICTION_RANGE (8)
> consecutive hash buckets starting from the calculated hash index.
> 
> With nf_conntrack_max=4096 and nf_conntrack_buckets=262144,

makes no sense to make to configure it in this way, there are well
define rules aiming at maintaining O(1) in hashtables and this
configuration is clearly suboptimal.

> the hash table
> is sparsely populated. Since early_drop() examines only eight consecutive
> buckets, it can fail to locate an eligible entry even when many non-ASSURED
> connections remain in the table. This appears consistent with the connection
> failures observed during testing.
> 
> When the bucket count is reduced or when the table density is increased,
> early eviction succeeds reliably and permits legitimate inbound connections.
> 
> Proposed Improvements:
> I am interested in addressing this behavior upstream and would appreciate
> feedback on which direction would be most useful:
> 
> 1. Diagnostic:
>    Warn (e.g., via pr_warn_once()) when nf_conntrack_max is configured to be
>    significantly lower than nf_conntrack_buckets via sysctl, notifying the
>    operator that early_drop() heuristics may become ineffective under load.
> 
> 2. Documentation:
>    Update Documentation/networking/nf_conntrack-sysctl.rst to document the
>    tuning implications of sparse hash tables on early eviction.

Documentation is good to have, I would suggest you start with this.

> 3. Algorithmic:
>    Investigate a bounded improvement to candidate selection in sparse tables
>    without introducing unacceptable CPU overhead on the drop path.

You mean, to improve the situation for this suboptimal configuration?

> I'm happy to prepare a patch or provide additional test measurements based
> on the discussion.
> 
> Thanks,
> Vikash SS