nf_conntrack: table full, dropping packet": conntrack tuning
Fixes conntrack table exhaustion dropping packets. Use when kernels log conntrack table full, when connections drop under load, or when tuning NAT-heavy hosts. Not for application connection limits.
TL;DR
The conntrack table tracks every connection through the host's NAT/firewall; when it fills, new connections get dropped with this log message. The fixes are sizing the table for the workload (more connections need a bigger table), reducing garbage (short timeouts for the protocols you do not need to track long), and finding connection churn sources. It is a capacity problem on busy NAT gateways, load balancers, and Kubernetes nodes.
The query
"nf_conntrack: table full, dropping packet": conntrack tuningUse this when
- Kernel logs show conntrack table full
- New connections drop under load
- Tuning NAT gateways or busy nodes
- After traffic growth
Not for when
- Application-level connection limits
- Firewall rule issues (different logs)
- Bandwidth saturation
Steps
Step 1: Confirm the table is actually full
Check the current conntrack count against the max. If count is at max during the drops, the diagnosis is confirmed; if not, the drops have another cause. Expected output: count vs max quantified at drop time.
Step 2: Size the table for the workload
Raise the conntrack max based on measured peak connections with headroom. The default is sized for a workstation, not a NAT gateway handling thousands of connections. Size from data, not defaults. Expected output: a max that covers peak plus growth.
Step 3: Tune timeouts for your traffic mix
Lower timeouts for connection states you do not need to track long (unreplied UDP, short-lived TCP). Long default timeouts hold table entries for dead connections; tuning reclaims them faster. Expected output: table entries recycling faster; effective capacity up.
Step 4: Find the churn source
Look for what creates excessive connections: misconfigured health checks opening connections per second, connection-per-request patterns, or a SYN flood. Fixing the churn beats enlarging the table. Expected output: the churn source identified and calmed.
Step 5: Monitor table usage continuously
Alert on conntrack usage percentage, not just on the full-table log message. The log message means drops already happened; the metric gives advance warning. Expected output: early-warning alerts with time to react.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_MjE41jdmkv46bxShN7xI8g