From: Stephen J Smoogen <smoogen@lanl.gov>
To: Michal Ludvig <mludvig@suse.cz>
Cc: netfilter@lists.netfilter.org
Subject: Re: ip_conntrack_max vs ip_conntrack
Date: Fri, 24 Sep 2004 16:49:26 -0600 [thread overview]
Message-ID: <4154A476.8030405@lanl.gov> (raw)
In-Reply-To: <4154A112.20308@suse.cz>
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.
--
Stephen John Smoogen | CCN-5 Security Team
LANL SIRT Team Leader | SMTP: smoogen@lanl.gov
Los Alamos National Laboratory | Voice: 505.664.0645
Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793
Los Alamos, NM 87545 |
next prev parent reply other threads:[~2004-09-24 22:49 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 [this message]
2004-09-30 9:59 ` Michal Ludvig
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=4154A476.8030405@lanl.gov \
--to=smoogen@lanl.gov \
--cc=mludvig@suse.cz \
--cc=netfilter@lists.netfilter.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.