Re: connection dropouts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux