Good day, Zheng,
        By the way, I'm just doing this from my best understanding - if
anyone finds errors in my logic or numbers, please correct me.

On Mon, 22 Apr 2002, zheng wrote:

>   we use linux 2.4 as a firewall.the machine has 128M memory and we have
> about 200 people behind the firewall. we met some problem.sometimes the
> firewall costs up its resources and goes down.i checked with 'top' and
> found that the memory is used up.  the file /proc/net/ip_conntrack
> records all the connnections,and it grows fast. i think this may be the
> problem.

        Please note that the fact that all memory is in use is _not_ a 
problem.  Linux will use all unneeded memory for disk caching, so top 
reporting almost all memory used is not a problem.
        The firewall going down _is_ a problem. ;-)
        You didn't mention which kernel you are using; if it's much 
earlier than 2.4.18 or so, you might want to upgrade the kernel.

>   how to solve the problem? to increase the memory is a solution,but
> that will not solve all the problem.or to get rid of ip_conntrack when
> compile the kernel? but we have to use nat.

        You're right - you _must_ have ip_conntrack in order to use nat.

>   anyone have some good idea on it?thanks for help.

        As I hope I've made clear above, I don't believe that the number 
of tracked connections is bringing your firewall down; I believe it might 
be other memory problems in older kernels.  However, you or others might 
still want to play with the maximum number of trackable connections.
        You can manually adjust the number of connections that can be
tracked with the "hashsize" parameter to the ip_conntrack module.  By
default, the module calculates the hashsize from the amount of ram in the
system (seach for "ip_conntrack_htable_size =" in
/usr/src/linux/net/ipv4/netfilter/ip_conntrack_core.c).  To bump this up,
decide how many connections you want to track (say, 131072, a nice
multiple of 8) and divide that by 8 to see what hashsize you need to
support that many connections (16384 in this example).  The first time you
insert the ip_conntrack module, do it by hand and specify the hashsize.

        Here's the conntrack output from the previous module load:
[root@sparrow root]# cat /var/log/messages | grep ip_conntrack
Apr 24 11:04:37 sparrow kernel: ip_conntrack version 2.0 (4095 buckets, 32760 max) - 
328 bytes per conntrack

        Now use the larger hashsize:
[root@sparrow root]# insmod ip_conntrack hashsize=16384
Using /lib/modules/2.4.19-pre7-ac1/kernel/net/ipv4/netfilter/ip_conntrack.o

[root@sparrow root]# cat /var/log/messages | grep ip_conntrack
Apr 24 11:04:37 sparrow kernel: ip_conntrack version 2.0 (4095 buckets, 32760 max) - 
328 bytes per conntrack
Apr 24 12:36:32 sparrow kernel: ip_conntrack version 2.0 (16384 buckets, 131072 max) - 
328 bytes per conntrack

        One way to automate this parameter is to edit /etc/modules.conf 
and add the line:
options ip_conntrack hashsize=16384
        Remember to run "depmod -a" after saving the change.  Any time you
load that module in the future with "modprobe ip_conntrack" it will use
this parameter automatically without having to specify it on the command
line.  Note this trick doesn't work with "insmod ip_conntrack".

        Now for memory usage.
        In my setup, each connection uses 328 bytes (note that I've 
applied a number of patches from patch-o-matic, some of which might have 
increased the number of bytes per connection, but it's a good working 
number).  Here's a table of hashsize, number of conenctions, and 
approximate memory usage.  I personally don't have a problem allocating a 
_lot_ of memory on a machine that does nothing more than firewalling to 
that task, but I include this as a reminder that you might find problems 
if you push this too close to the amount of actual ram on the system.

hashsize         connections      memory
4095             32760            10.7M
16384            131072           43M
66536            524288           172M

        I didn't want to go too far beyond this myself as much of the ram 
on this system is already allocated.
        Cheers,
        - Bill

---------------------------------------------------------------------------
        "When I was recently asked to write a television script, the
studio insisted that I sign four copies of an affidavit giving it all
rights to my writing 'throughout the Universe in perpetuity.'  I
telephoned a studio lawyer to see if I could keep a few moons of
Jupiter."
        -- Charles C. Mann, in "Information Anxiety", Sept 1998 Atlantic
Monthly.
--------------------------------------------------------------------------
William Stearns ([EMAIL PROTECTED]).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:                        http://www.stearns.org
--------------------------------------------------------------------------



Reply via email to