Very interesting find ! So, what that means is that the 5 days timeout will
not
hurt other connections, because unreplied connections will get removed
automatically if new connections need the spot ?
That would definitely explain why the total of unreplied connection went
down a
little bit on June 8th at 4am: http://4u.1nw.eu/conntrack_stat3.png
We did fix other parameters earlier, like enabling tcp_tw_reuse and
directing
localhost traffic to NOTRACK. It would explain why we didn't get more of
those
`table full, dropping packet`.
- Julien
On 2012-06-09 14:14, Marco Padovan wrote:
Looks like it's an intendend behaviour:
http://www.netfilter.org/documentation/FAQ/netfilter-faq-3.html#ss3.17 [1]
<
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 [2]
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 [3] ).
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
Links:
------
[1] http://www.netfilter.org/documentation/FAQ/netfilter-faq-3.html#ss3.17
[2] http://4u.1nw.eu/conntrack_stat3.png
[3] https://gist.github.com/2901349
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
