From: Michal Ludvig <mludvig@suse.cz>
To: Stephen J Smoogen <smoogen@lanl.gov>
Cc: netfilter@lists.netfilter.org
Subject: Re: ip_conntrack_max vs ip_conntrack
Date: Thu, 30 Sep 2004 11:59:49 +0200 [thread overview]
Message-ID: <415BD915.9000206@suse.cz> (raw)
In-Reply-To: <4154A476.8030405@lanl.gov>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stephen J Smoogen told me that:
> Michal Ludvig wrote:
>
>> Hi all,
>>
>> could someone please explain me what is the relation between the number
>> in /proc/sys/net/ipv4/ip_conntrack_max and number of lines in
>> /proc/net/ip_conntrack?
>>
>> On one of our very loaded firewalls (with 1GB RAM) we are still getting
>> "ip_conntrack: table full, dropping packet." message. We tried to tweak
>> all different parameters, e.g. hashsize to up to 1048576,
>> ip_conntrack_max, ip_conntrack_tcp_timeout_established, etc.
>> Unfortunately sooner or later the kernel always starts dropping packets.
>> At the same time however there are at most a few thousands of lines in
>> /proc/net/ip_conntrack.
>>
>> I instrumented the kernel to dump the same output via printk() once
>> ip_conntrack_count reaches ip_conntrack_max. When I set _max=128 and run
>> nmap through the firewall it of course very soon prints the "dropping
>> packets" message, but along with only 6 (=six!) lines of connections.
>> Where was the rest, 122 connections, lost? What does the
>> ip_conntrack_count actually count?
>
> Ok one thing you might want to do is check to see if you dont have a bug
> in your kernel somewhere.. I found the one I talked about earlier by
> doing the following:
>
> cat /proc/slabinfo |grep ip_conntrack
> cat /proc/net/ip_conntrack | wc -l
>
> Not the best and very racy.. but the 2 did NOT match up in any shape or
> form. I then played around with various conntrack modules until I figure
> d it out to being something with conntrack_irc and conntrack_ftp in the
> kernel I was running. Removing those allowed for the 2 to match up
> closely when doing HTTP crashloads on the firewall. Adding either one
> of them caused what looked like a resource leak.
>
> As far as I can tell.. a POM-only patched 2.4.26 did not exhibit this
> problem.
I can see it on 2.6.5 but not on 2.6.9-rc2. Does anyone have the patch
or the cset number that fixed this? I hope I won't have to binary search
for it... ;-)
Michal Ludvig
- --
SUSE Labs mludvig@suse.cz
(+420) 296.542.396 http://www.suse.cz
Personal homepage http://www.logix.cz/michal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBW9kTDDolCcRbIhgRAl3MAJ9T3SH/leXz3v4oScV/j4Q9vS6BggCfTFOh
WhXvdntlqi2W1bIs0o4E6as=
=48El
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2004-09-30 9:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-24 22:34 ip_conntrack_max vs ip_conntrack Michal Ludvig
2004-09-24 22:49 ` Stephen J Smoogen
2004-09-30 9:59 ` Michal Ludvig [this message]
2004-09-28 7:59 ` Mohamed Eldesoky
2004-09-28 12:31 ` Alistair Tonner
2004-09-28 12:53 ` Ted Kaczmarek
2004-09-28 14:27 ` Jose Maria Lopez
2004-09-28 14:48 ` Mohamed Eldesoky
2004-09-28 15:19 ` Alistair Tonner
2004-09-30 11:30 ` Mohamed Eldesoky
-- strict thread matches above, loose matches on Subject: below --
2004-09-27 17:52 Jiann-Ming Su
2004-09-27 18:04 ` Jason Opperisano
2004-09-27 18:57 ` Jose Maria Lopez
2004-09-30 22:48 ` Jiann-Ming Su
2004-09-30 23:03 ` Jason Opperisano
2004-10-19 17:21 ` Jiann-Ming Su
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=415BD915.9000206@suse.cz \
--to=mludvig@suse.cz \
--cc=netfilter@lists.netfilter.org \
--cc=smoogen@lanl.gov \
/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.