Mailing List Archive

ip_conntrack growing indefinitely
Hi everybody. We're running a couple of Debian Sarge machines with
2.4.31 kernel doing NAT for our network.
Recently we had troubles with lost packets because of full ip_conntrack
buffers, and it's strange because usually the average number of
connections is not more then 8000-10000.
For now it has been patched setting ip_conntrack_max to 65536 but
connections still grow indefinitely (seems NAT never drops old connections).
Any idea of the reasons? Could be related with the kernel version (2
years old) we're running?

Thanks

--
Alexander Fortin
IT Consultant
Informed Technology
E-mail: alieno@it.net.au
Ph: 08 9460 4888 Fax: 08 9460 4877
Re: ip_conntrack growing indefinitely [ In reply to ]
Hi there,

On Sat, 11 Aug 2007 fd4 wrote:

> > For now it has been patched setting ip_conntrack_max to 65536 but
> > connections still grow indefinitely (seems NAT never drops old
> > connections). Any idea of the reasons? Could be related with the
> > kernel version (2 years old) we're running?
>
> I've a similar phenomen using kernel 2.6.18-4-vserver-686 :
> conntrack -L|wc -l
> 3340
> nearly all started at a similar time from two ports to random
>
> example iptstate:
> Source Destination Proto State TTL
> 1.2.3.4:42573 1.2.3.4:842 tcp ESTABLISHED 10:44:43
> 1.2.3.4:42574 1.2.3.4:1501 tcp ESTABLISHED 10:43:51
> 1.2.3.4:42573 1.2.3.4:1392 tcp ESTABLISHED 10:43:20
>
> well :- on my wish list now something like that:
> conntrack -D -s 1.2.3.4 -d 1.2.3.4 -p tcp --orig-port-src 42573 --orig-port-dst *

I don't think it grows indefinitely. The timeout is five days.

http://lists.netfilter.org/pipermail/netfilter-devel/2005-June/020081.html

--

73,
Ged.
Re: ip_conntrack growing indefinitely [ In reply to ]
Am Sat, 11 Aug 2007 11:19:08 +0100 (BST)
schrieb "G.W. Haywood" <ged@jubileegroup.co.uk>:

> I don't think it grows indefinitely. The timeout is five days.

about 11 hrs in that case :-)
(of course I've reduced the standard value)

and I've said a similar case - just wondering, cleaned it with conntrack -F

the growing to more than 3300 entries has started by an unknown local event triggering conntrack on local connections; I could not find any reason in the logs or somehow else. happened within a minute or 2 from 2 local ports