Linux · high · Networking, DNS & SSH

"nf_conntrack: table full, dropping packet"

The connection tracking table has filled, so new connections are being dropped while existing ones continue.

What you see

New connections fail intermittently while established ones are unaffected. The message appears repeatedly in the kernel log. Common on routers, NAT gateways and busy load balancers.

What is actually wrong

Either genuine load exceeding a default table size that was set for a much smaller machine, or a flood — a scan, a misbehaving client, or an application leaking connections.

Codes and articles

nf_conntrack: table fulldropping packetconntrackip_conntrack: table full

Fixes (2)

Look at what is filling the table

Root shell25 minuteslow riskreversible

Before raising the limit. Doubling the table for a flood only delays the same failure.

See how full it is and what the limit is.

Shell

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_maxcat /proc/sys/net/netfilter/nf_conntrack_count

Find which source addresses hold the most entries.
Shell
```
sudo conntrack -L 2>/dev/null | awk '{print $5}' | sed 's/src=//' | sort | uniq -c | sort -rn | head -20
```
One address holding tens of thousands of entries is a scan or a broken client, and the fix is to block or fix that — not to enlarge the table so it can hold more of it.
Look at the state breakdown. A large number of SYN_SENT entries means connections that are never completing.
Shell
```
sudo conntrack -L 2>/dev/null | awk '{print $4}' | sort | uniq -c | sort -rn | head
```
Check whether conntrack is even needed for the traffic in question. On a machine that is not doing NAT, tracking can be skipped for high-volume flows with a notrack rule.
Shell
```
sudo nft list ruleset | grep -i notrack
```

Confirm it workedYou know whether the entries are legitimate work or a flood.

If you need to undo itNothing was changed.

Size the table for the machine

Root shell20 minutesmedium riskreversible

The load is genuine.

Raise the maximum. Each entry costs roughly 300 bytes, so a million entries is around 300MB of kernel memory — budget for it.
Shell
```
sudo sysctl -w net.netfilter.nf_conntrack_max=524288
```
Raise the hash table size to match, or lookups slow down as the table grows.
Shell
```
echo 131072 | sudo tee /sys/module/nf_conntrack/parameters/hashsize
```
The recommended ratio is roughly max divided by four. Raising max alone gives a table that holds more entries and takes longer to search each one, which shows up as latency rather than drops.
Shorten the timeout for established connections, which is 5 days by default and holds entries long after the connection is gone.
Shell
```
sudo sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=86400
```

Make it persistent.

Shell

printf 'net.netfilter.nf_conntrack_max = 524288\nnet.netfilter.nf_conntrack_tcp_timeout_established = 86400\n' | sudo tee /etc/sysctl.d/99-conntrack.confsudo sysctl --system

Watch the count under load for a few days before deciding it is enough.

Confirm it workedThe count stays comfortably below the maximum under peak load and the kernel messages stop.

Shell

watch -n2 'sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max'

If you need to undo itRemove /etc/sysctl.d/99-conntrack.conf and run sysctl --system to return to the defaults.

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.