All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Padovan <evcz@evcz.tk>
Cc: netfilter@vger.kernel.org
Subject: Re: Conntrack & Unreplied exhausts hashsize
Date: Sat, 09 Jun 2012 20:15:53 +0200	[thread overview]
Message-ID: <4FD392D9.9010706@evcz.tk> (raw)
In-Reply-To: <f8da378bd8c865bf9618b0d52f7b4441@njm.linuxwall.info>

Looks like it's an intendend behaviour:

http://www.netfilter.org/documentation/FAQ/netfilter-faq-3.html#ss3.17

<<UNREPLIED entries are temporary entries, i.e. as soon as we run out of
connection tracking entries (we reach
/proc/sys/net/ipv4/ip_conntrack_max), we delete old UNREPLIED entries.
In other words: instead of having empty conntrack entries, we'd rather
keep some maybe useful information in them until we really need them.>>

when having the conntrack table full "error" did you still have
unreplied entries in the table?

Il 09/06/2012 17:12, Julien Vehent ha scritto:
> Hi everyone,
>
> I'm analyzing a configuration problem that we are encountering with
> conntrack at work. We have a farm of frontend servers that run apache.
> Those servers run into the classical table full problem:
>
>     Jun 5 09:57:51 web-front1 kernel: [7177214.445925] nf_conntrack:
> table full, dropping packet.
>
> So I started tuning the kernel of one member of the farm. This server
> has 2 interfaces: one public and one in the LAN. The problem is on the
> public interface, it seems that connections in the UNREPLIED state
> continue to grow and never get cleaned up by conntrack. Below is a
> diagram that shows the issue:
>
> http://4u.1nw.eu/conntrack_stat3.png
>
> The orange line counts connections on the public IP that are in the
> unreplied state. The script parses /etc/net/ip_conntrack every 10
> minutes (nothing fancy, see https://gist.github.com/2901349 ).
>
> My questions are:
>
> Should these UNREPLIED connection get removed from conntrack after a
> certain timeout?
>
> What is the parameter that controls this timeout ?
> I'm afraid it might be
> `net.netfilter.nf_conntrack_tcp_timeout_established = 432000`, which
> is 5 days. If this is the case, would it be safe to set this parameter
> to 300 seconds instead (5 minutes) ?
>
> Note: apache runs with `KeepAlive On` and `KeepAliveTimeout 3`, in
> case this might be relevant.
>
>
> Thanks a lot,
> Julien
>
>



  reply	other threads:[~2012-06-09 18:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-09 15:12 Conntrack & Unreplied exhausts hashsize Julien Vehent
2012-06-09 18:15 ` Marco Padovan [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-06-09 20:15 Fwd: " Julien Vehent
2012-06-12 11:22 ` Julien Vehent
2012-06-16 19:39   ` Pablo Neira Ayuso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FD392D9.9010706@evcz.tk \
    --to=evcz@evcz.tk \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.