How to mitigate error “kernel: nf_conntrack: table full, dropping packet”
Clash Royale CLAN TAG#URR8PPP
We recently had a problem with one of our servers (Debian Squeeze) becoming unresponsive during heavy-ish load. Looking at the kernel logs, I think this is the cause:
kernel: nf_conntrack: table full, dropping packet
As I understand it, this is the conntrack module, which does some stateful tracking of connection, reporting that the table used to store the connection details is full.
From the research I have done, there seem to be two ways to mitigate this:
Increase size of the table.
Remove the module from the system altogether.
However, neither /proc/sys/net/ipv4/ip_conntrack_max
nor /proc/sys/net/ipv4/netfilter/ip_conntrack_max
exist on this machine (there is no ipv4
catalogue under net
).
If I do lsmod
I get no results.
So, I'm a bit confused - perhaps someone could clarify the situation for me?
- Is conntrack installed? If so, where are the settings? And why doesn't it show up in lsmod?
- If conntrack is not installed, what is issuing the table full messages?
Thank you
debian networking
add a comment |
We recently had a problem with one of our servers (Debian Squeeze) becoming unresponsive during heavy-ish load. Looking at the kernel logs, I think this is the cause:
kernel: nf_conntrack: table full, dropping packet
As I understand it, this is the conntrack module, which does some stateful tracking of connection, reporting that the table used to store the connection details is full.
From the research I have done, there seem to be two ways to mitigate this:
Increase size of the table.
Remove the module from the system altogether.
However, neither /proc/sys/net/ipv4/ip_conntrack_max
nor /proc/sys/net/ipv4/netfilter/ip_conntrack_max
exist on this machine (there is no ipv4
catalogue under net
).
If I do lsmod
I get no results.
So, I'm a bit confused - perhaps someone could clarify the situation for me?
- Is conntrack installed? If so, where are the settings? And why doesn't it show up in lsmod?
- If conntrack is not installed, what is issuing the table full messages?
Thank you
debian networking
Really?lsmod|grep conntrack
doesn't yield results? Maybe you're using IPv6?
– Jan
Sep 30 '14 at 11:06
Right,lsmod|grep conntrack
comes back empty (as does lsmod on it's own). Definitely using ip4, although both ip4 and ip6 are configured on this server - it's a virtualized server if that makes any difference.
– UpTheCreek
Sep 30 '14 at 11:12
I havenf_conntrack_max
directly in/proc/sys/net
and in/proc/sys/net/netfilter
.
– Scyld de Fraud
Sep 30 '14 at 12:01
add a comment |
We recently had a problem with one of our servers (Debian Squeeze) becoming unresponsive during heavy-ish load. Looking at the kernel logs, I think this is the cause:
kernel: nf_conntrack: table full, dropping packet
As I understand it, this is the conntrack module, which does some stateful tracking of connection, reporting that the table used to store the connection details is full.
From the research I have done, there seem to be two ways to mitigate this:
Increase size of the table.
Remove the module from the system altogether.
However, neither /proc/sys/net/ipv4/ip_conntrack_max
nor /proc/sys/net/ipv4/netfilter/ip_conntrack_max
exist on this machine (there is no ipv4
catalogue under net
).
If I do lsmod
I get no results.
So, I'm a bit confused - perhaps someone could clarify the situation for me?
- Is conntrack installed? If so, where are the settings? And why doesn't it show up in lsmod?
- If conntrack is not installed, what is issuing the table full messages?
Thank you
debian networking
We recently had a problem with one of our servers (Debian Squeeze) becoming unresponsive during heavy-ish load. Looking at the kernel logs, I think this is the cause:
kernel: nf_conntrack: table full, dropping packet
As I understand it, this is the conntrack module, which does some stateful tracking of connection, reporting that the table used to store the connection details is full.
From the research I have done, there seem to be two ways to mitigate this:
Increase size of the table.
Remove the module from the system altogether.
However, neither /proc/sys/net/ipv4/ip_conntrack_max
nor /proc/sys/net/ipv4/netfilter/ip_conntrack_max
exist on this machine (there is no ipv4
catalogue under net
).
If I do lsmod
I get no results.
So, I'm a bit confused - perhaps someone could clarify the situation for me?
- Is conntrack installed? If so, where are the settings? And why doesn't it show up in lsmod?
- If conntrack is not installed, what is issuing the table full messages?
Thank you
debian networking
debian networking
asked Sep 30 '14 at 10:56
UpTheCreekUpTheCreek
3433516
3433516
Really?lsmod|grep conntrack
doesn't yield results? Maybe you're using IPv6?
– Jan
Sep 30 '14 at 11:06
Right,lsmod|grep conntrack
comes back empty (as does lsmod on it's own). Definitely using ip4, although both ip4 and ip6 are configured on this server - it's a virtualized server if that makes any difference.
– UpTheCreek
Sep 30 '14 at 11:12
I havenf_conntrack_max
directly in/proc/sys/net
and in/proc/sys/net/netfilter
.
– Scyld de Fraud
Sep 30 '14 at 12:01
add a comment |
Really?lsmod|grep conntrack
doesn't yield results? Maybe you're using IPv6?
– Jan
Sep 30 '14 at 11:06
Right,lsmod|grep conntrack
comes back empty (as does lsmod on it's own). Definitely using ip4, although both ip4 and ip6 are configured on this server - it's a virtualized server if that makes any difference.
– UpTheCreek
Sep 30 '14 at 11:12
I havenf_conntrack_max
directly in/proc/sys/net
and in/proc/sys/net/netfilter
.
– Scyld de Fraud
Sep 30 '14 at 12:01
Really?
lsmod|grep conntrack
doesn't yield results? Maybe you're using IPv6?– Jan
Sep 30 '14 at 11:06
Really?
lsmod|grep conntrack
doesn't yield results? Maybe you're using IPv6?– Jan
Sep 30 '14 at 11:06
Right,
lsmod|grep conntrack
comes back empty (as does lsmod on it's own). Definitely using ip4, although both ip4 and ip6 are configured on this server - it's a virtualized server if that makes any difference.– UpTheCreek
Sep 30 '14 at 11:12
Right,
lsmod|grep conntrack
comes back empty (as does lsmod on it's own). Definitely using ip4, although both ip4 and ip6 are configured on this server - it's a virtualized server if that makes any difference.– UpTheCreek
Sep 30 '14 at 11:12
I have
nf_conntrack_max
directly in /proc/sys/net
and in /proc/sys/net/netfilter
.– Scyld de Fraud
Sep 30 '14 at 12:01
I have
nf_conntrack_max
directly in /proc/sys/net
and in /proc/sys/net/netfilter
.– Scyld de Fraud
Sep 30 '14 at 12:01
add a comment |
1 Answer
1
active
oldest
votes
I had the same issue on servers running with Ubuntu 18.04. Even though the nf_conntrack
module was not loaded at startup, later during traffic spikes, messages were dropped (nf_conntrack: table full, dropping packet
).
I'm not aware of a way to disable the functionality, but I ended up explicitly loading the module, so I could overwrite the table size.
First, make sure that nf_conntrack
gets immediately loaded by including it in /etc/modules
:
nf_conntrack
Then increase its table size, which otherwise will depend on the memory size of the server, by overwriting the defaults in /etc/sysctl.conf
:
net.netfilter.nf_conntrack_max=262144
net.nf_conntrack_max=262144
To verify:
$ cat /proc/sys/net/netfilter/nf_conntrack_max
262144
As said, it was tested on Ubuntu 18.04, but I would expect it to work also on Debian.
For some further background, why nf_conntrack
might get later loaded, even if it is not present after booting up, this related answer has an example where the module gets automatically loaded when iptables
is called. Adding it explicitly to /etc/modules
eliminates that kind of complexity.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f158397%2fhow-to-mitigate-error-kernel-nf-conntrack-table-full-dropping-packet%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I had the same issue on servers running with Ubuntu 18.04. Even though the nf_conntrack
module was not loaded at startup, later during traffic spikes, messages were dropped (nf_conntrack: table full, dropping packet
).
I'm not aware of a way to disable the functionality, but I ended up explicitly loading the module, so I could overwrite the table size.
First, make sure that nf_conntrack
gets immediately loaded by including it in /etc/modules
:
nf_conntrack
Then increase its table size, which otherwise will depend on the memory size of the server, by overwriting the defaults in /etc/sysctl.conf
:
net.netfilter.nf_conntrack_max=262144
net.nf_conntrack_max=262144
To verify:
$ cat /proc/sys/net/netfilter/nf_conntrack_max
262144
As said, it was tested on Ubuntu 18.04, but I would expect it to work also on Debian.
For some further background, why nf_conntrack
might get later loaded, even if it is not present after booting up, this related answer has an example where the module gets automatically loaded when iptables
is called. Adding it explicitly to /etc/modules
eliminates that kind of complexity.
add a comment |
I had the same issue on servers running with Ubuntu 18.04. Even though the nf_conntrack
module was not loaded at startup, later during traffic spikes, messages were dropped (nf_conntrack: table full, dropping packet
).
I'm not aware of a way to disable the functionality, but I ended up explicitly loading the module, so I could overwrite the table size.
First, make sure that nf_conntrack
gets immediately loaded by including it in /etc/modules
:
nf_conntrack
Then increase its table size, which otherwise will depend on the memory size of the server, by overwriting the defaults in /etc/sysctl.conf
:
net.netfilter.nf_conntrack_max=262144
net.nf_conntrack_max=262144
To verify:
$ cat /proc/sys/net/netfilter/nf_conntrack_max
262144
As said, it was tested on Ubuntu 18.04, but I would expect it to work also on Debian.
For some further background, why nf_conntrack
might get later loaded, even if it is not present after booting up, this related answer has an example where the module gets automatically loaded when iptables
is called. Adding it explicitly to /etc/modules
eliminates that kind of complexity.
add a comment |
I had the same issue on servers running with Ubuntu 18.04. Even though the nf_conntrack
module was not loaded at startup, later during traffic spikes, messages were dropped (nf_conntrack: table full, dropping packet
).
I'm not aware of a way to disable the functionality, but I ended up explicitly loading the module, so I could overwrite the table size.
First, make sure that nf_conntrack
gets immediately loaded by including it in /etc/modules
:
nf_conntrack
Then increase its table size, which otherwise will depend on the memory size of the server, by overwriting the defaults in /etc/sysctl.conf
:
net.netfilter.nf_conntrack_max=262144
net.nf_conntrack_max=262144
To verify:
$ cat /proc/sys/net/netfilter/nf_conntrack_max
262144
As said, it was tested on Ubuntu 18.04, but I would expect it to work also on Debian.
For some further background, why nf_conntrack
might get later loaded, even if it is not present after booting up, this related answer has an example where the module gets automatically loaded when iptables
is called. Adding it explicitly to /etc/modules
eliminates that kind of complexity.
I had the same issue on servers running with Ubuntu 18.04. Even though the nf_conntrack
module was not loaded at startup, later during traffic spikes, messages were dropped (nf_conntrack: table full, dropping packet
).
I'm not aware of a way to disable the functionality, but I ended up explicitly loading the module, so I could overwrite the table size.
First, make sure that nf_conntrack
gets immediately loaded by including it in /etc/modules
:
nf_conntrack
Then increase its table size, which otherwise will depend on the memory size of the server, by overwriting the defaults in /etc/sysctl.conf
:
net.netfilter.nf_conntrack_max=262144
net.nf_conntrack_max=262144
To verify:
$ cat /proc/sys/net/netfilter/nf_conntrack_max
262144
As said, it was tested on Ubuntu 18.04, but I would expect it to work also on Debian.
For some further background, why nf_conntrack
might get later loaded, even if it is not present after booting up, this related answer has an example where the module gets automatically loaded when iptables
is called. Adding it explicitly to /etc/modules
eliminates that kind of complexity.
edited Feb 21 at 20:40
answered Feb 21 at 20:31
Philipp ClaßenPhilipp Claßen
1,43542032
1,43542032
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f158397%2fhow-to-mitigate-error-kernel-nf-conntrack-table-full-dropping-packet%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Really?
lsmod|grep conntrack
doesn't yield results? Maybe you're using IPv6?– Jan
Sep 30 '14 at 11:06
Right,
lsmod|grep conntrack
comes back empty (as does lsmod on it's own). Definitely using ip4, although both ip4 and ip6 are configured on this server - it's a virtualized server if that makes any difference.– UpTheCreek
Sep 30 '14 at 11:12
I have
nf_conntrack_max
directly in/proc/sys/net
and in/proc/sys/net/netfilter
.– Scyld de Fraud
Sep 30 '14 at 12:01