From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=217.70.190.124 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793965248; b=j1pB73WGIJS1tEVs4p9FONuvwPE8jTBiE0Z/Nnd5Iis5qvv1yc83SPgkIw1rv5GiK8kI jrnoZ+PfBZN3R1APth6xV+gsP60T8/KVFmYigVSoeO1u5sWHvMvPToKaxbxg5URmLZG9v 53XcXY/NiRD1LJymML4py8yTY28I0sc7d40FJ8KUabC8PAfMlnKJLMWaQ47PqhSu6ohZL +/koCgdxW3jRn1zO7NF6UcmEn3W7S1U4/7pNqi8koKqIUocgPDKp2CtJikorTPojk6cNB BC6UtzxFz7lEMk/smHSexr0Lf75U2sS9iUDcKzfMlzrl8hJoUcLoAqNYfnEGPM7Dt8w== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793965248; h=DMARC-Filter:DKIM-Signature:Received:Date:From:To:Cc:Subject: Message-ID:References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To:X-Spam-Status:X-Spam-Checker-Version; bh=5jjA6YtIdyvB1Tq3M7IJ9BpKzfkjMKdFlQjpHQXhINI=; b=X1SqxcZ6IKFlqk8UjXCpdQiTJR830DiooRqS1lqvBLZTSk3b3YTgv57YQjoyCdlEO+Xf Av16L/41m0rpJL/Paf3hL1BA/XMqpVQRtGt5YUW+/J5DYjmvDAHYUxJHLW7cKl46IGNHk rQ41thUTJTXdmk9a7yVDrAoMJDes051hEa0eXeRhqFIiE4clTS2hBUseML/dlTsyIxLz5 n6NsBCwwYzNp77HAb5sqJCSBnIbroPW9t4WDXHfDWjN8vOArWvu6bnJF88aUWo0dEy82g XkFJFZAjGl0ZtpKJl2Af73fGhI1A2G2mRSsdWBFN44SW8DEyM8v/Yc7QDbZ8ipKQPYg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none header.from=netfilter.org; spf=pass smtp.mailfrom=netfilter.org; dkim=pass header.d=netfilter.org header.i=@netfilter.org header.a=rsa-sha256 header.s=2025 header.b=kn0X52A1; arc=none smtp.remote-ip=217.70.190.124 Received: from mail.netfilter.org (mail.netfilter.org [217.70.190.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with UTF8SMTPS id BD64E606A329 for ; Fri, 6 Nov 2026 11:40:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org BD64E606A329 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=netfilter.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=netfilter.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=netfilter.org header.i=@netfilter.org header.a=rsa-sha256 header.s=2025 header.b=kn0X52A1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netfilter.org; s=2025; t=1793965245; bh=5jjA6YtIdyvB1Tq3M7IJ9BpKzfkjMKdFlQjpHQXhINI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kn0X52A1QI0gV7THsuGvG/VdQfFoR+/gLMYqEI/+97DmkMukrGz+aAe1HZNnjy8Au HvgALnbPGLdS22Ig0o3YOOCaUxGH7DSs3HNTE8yt7/WU30h4OV882R2TSS59Vhiu3s Zd4uMgPv3a5OdkExd+gBywCvxmwdkvi5x4UXVdSLpN6tmHJa5tib6Tf5R+S7qI9RbN x4xfFzSl1qx+4OcaHWZDkerRUbEicUMDc/DOIOSHXSlij9cxSiHsvgcvWvEoDTiwZ2 8vIArc+ocUhRB5aqt0SD405QYnxsNS17sVygQX5eY2JyEOxVIPs3ixtUM8huV16ofV VUvj54mo5yOhg== Received: from netfilter.org (mail-agni [217.70.190.124]) by mail.netfilter.org (Postfix) with UTF8SMTPSA id EF2FD6007A; Fri, 6 Nov 2026 12:40:44 +0100 (CET) Date: Fri, 6 Nov 2026 12:40:42 +0100 From: Pablo Neira Ayuso To: "S.S.Vikash" Cc: netfilter-devel@vger.kernel.org, fw@strlen.de Subject: Re: [RFC] netfilter: conntrack: early_drop eviction limitation under sparse table configurations (max << buckets) Message-ID: References: X-Mailing-List: netfilter-devel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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