From: Philip Craig <philipc@snapgear.com>
To: "T. Horsnell (tsh)" <tsh@mrc-lmb.cam.ac.uk>
Cc: netfilter@lists.netfilter.org
Subject: Re: connection dropouts
Date: Thu, 26 Feb 2004 19:00:35 +1000 [thread overview]
Message-ID: <403DB5B3.7030509@snapgear.com> (raw)
In-Reply-To: <E1Aw4LY-001AoE-0V@alf1.lmb.internal>
T. Horsnell (tsh) wrote:
> The firewall box is a 1GHz AMD with 128MBytes mem, and
> /proc/sys/net/ipv4/ip_conntrack_max is currently set to 8184.
>
> How can I track how close I get to this limit?
There will be a syslog message telling you when you reach the limit.
Or 'grep ip_conntrack /proc/slabinfo', and read the first number
(active_objs).
Or 'wc -l /proc/net/ip_conntrack', but that is slow and maybe unreliable.
> What is the memory use per conntrack entry?
The kernel displays this when the conntrack module is loaded, eg
kernel: ip_conntrack version 2.1 (8191 buckets, 65528 max) - 300 bytes
per conntrack
Or 'grep ip_conntrack /proc/slabinfo', and read the third number (objsize).
(Hmm, except I noticed those two numbers are different on my PC. The
slabinfo may be more accurate.)
> Is there anything particular about NAT entries in the conntrack
> tables that would make NAT'd hosts more prone to net hangups
> that unNAT'd ones?
Not that I'm aware of. Do the hangups have any sort of consistency?
> If I raise my ip_conntrack_max value, am I likely to crash
> the firewall if I raise it too high?
> What is the theoretical maximum number of conntrack entries?
> What is the theoretical maximum number of NAT connections?
> (this would seem to me to be 65536 - the maximum number
> of ports available on a single host, i.e. the NAT box
> since it has to map a source host:hostport into a NAT:natport)
The only limit is available memory. It is not limited to 65536 since
each entry is based off protocol/source host/source port/dest host/dest
port, the number of combinations of which is more than you'll ever need.
There is a limitation of 65535 NATed connections to a single port on a
given dest host (ie if source host, dest host, and dest port are all
constant), but that would be unusual to encounter.
--
Philip Craig - SnapGear, A CyberGuard Company - http://www.SnapGear.com
next prev parent reply other threads:[~2004-02-26 9:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-25 19:05 connection dropouts T. Horsnell (tsh)
2004-02-26 9:00 ` Philip Craig [this message]
2004-02-26 16:15 ` T. Horsnell (tsh)
2004-02-27 7:44 ` Philip Craig
2004-02-27 17:28 ` T. Horsnell (tsh)
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=403DB5B3.7030509@snapgear.com \
--to=philipc@snapgear.com \
--cc=netfilter@lists.netfilter.org \
--cc=tsh@mrc-lmb.cam.ac.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox