How to mitigate error “kernel: nf_conntrack: table full, dropping packet”

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












2















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:



  1. Increase size of the table.


  2. Remove the module from the system altogether.


However, neither /proc/sys/net/ipv4/ip_conntrack_maxnor /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










share|improve this question






















  • 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
















2















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:



  1. Increase size of the table.


  2. Remove the module from the system altogether.


However, neither /proc/sys/net/ipv4/ip_conntrack_maxnor /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










share|improve this question






















  • 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














2












2








2


1






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:



  1. Increase size of the table.


  2. Remove the module from the system altogether.


However, neither /proc/sys/net/ipv4/ip_conntrack_maxnor /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










share|improve this question














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:



  1. Increase size of the table.


  2. Remove the module from the system altogether.


However, neither /proc/sys/net/ipv4/ip_conntrack_maxnor /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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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 have nf_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











  • 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

















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











1 Answer
1






active

oldest

votes


















1














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.






share|improve this answer
























    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
    );



    );













    draft saved

    draft discarded


















    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









    1














    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.






    share|improve this answer





























      1














      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.






      share|improve this answer



























        1












        1








        1







        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.






        share|improve this answer















        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Feb 21 at 20:40

























        answered Feb 21 at 20:31









        Philipp ClaßenPhilipp Claßen

        1,43542032




        1,43542032



























            draft saved

            draft discarded
















































            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.




            draft saved


            draft discarded














            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





















































            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






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?