Linux Netfilter discussions
 help / color / mirror / Atom feed
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



  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