Connection Tracking Calculator
Check conntrack usage against nf_conntrack_max and estimate memory and timeout impact.
Inputs
Linux default is 432000s (5 days)
Conntrack Table Utilization %
45.78%
Status
Healthy
Estimated Conntrack Memory (MB)
34.33
TCP Established Timeout (hours)
120.0
Step by step
Values used
Current Conntrack Entries (conntrack -C) = 120,000; nf_conntrack_max = 262,144; Memory per Entry (bytes) = 300; TCP Established Timeout (sec) = 432,000
Conntrack utilization and memory
utilization% = current_entries / nf_conntrack_max × 100; memory = entries × ~300 bytes
Conntrack Table Utilization %
= 45.78
Status
= Healthy
Estimated Conntrack Memory (MB)
= 34.33
TCP Established Timeout (hours)
= 120.0
How it works
Netfilter's connection tracking subsystem (conntrack) maintains a table entry for every connection passing through a system using stateful firewalling, NAT, or many container networking setups, and this table has a hard ceiling set by nf_conntrack_max — once full, new connections are dropped or rejected rather than tracked. Each entry consumes kernel memory (roughly a few hundred bytes depending on protocol and extensions tracked), and long default timeouts — especially the notoriously long 5-day TCP ESTABLISHED timeout — mean idle-but-not-closed connections can accumulate and consume table capacity long after they're practically dead.
Formula
Conntrack utilization and memory
utilization% = current_entries / nf_conntrack_max × 100; memory = entries × ~300 bytes
- E
- current conntrack entries
- E_{max}
- nf_conntrack_max
- b
- bytes per entry
Frequently Asked Questions
How do I check current conntrack usage and the configured maximum?
`cat /proc/sys/net/netfilter/nf_conntrack_count` shows current entries; `cat /proc/sys/net/netfilter/nf_conntrack_max` shows the ceiling. `conntrack -L | wc -l` lists (and counts) entries in detail if the conntrack tools package is installed.
What happens when the conntrack table fills up?
The kernel logs 'nf_conntrack: table full, dropping packet' and refuses to track (and thus typically drops) new connections until entries expire or are evicted — this is a common, often overlooked cause of intermittent connection failures on busy firewalls, load balancers, and NAT gateways.
Why is the default TCP ESTABLISHED timeout so long (5 days)?
It's intentionally conservative to avoid prematurely dropping tracking state for legitimate long-lived idle connections (e.g. persistent database connections, SSH sessions), but on high-churn systems this default can let stale entries accumulate — tuning `nf_conntrack_tcp_timeout_established` lower is a common mitigation alongside raising nf_conntrack_max.