Herve Eychenne
2003-10-28 15:10:32 UTC
Hi everyone,
Can someone post a state of the art summary for netfilter conntrack
(and maybe NAT) performance tweaking?
The only things I'm currently aware of are:
- modprobe ip_conntrack hashsize=$HASHSIZE
- echo $CONNTRACK_MAX > /proc/sys/net/ipv4/ip_conntrack_max
I think it would be good to end up with a small document which would
give every detail about how to choose optimal values for HASHSIZE and
CONNTRACK_MAX, and every other mean to get the best out of the
conntracking/NAT system...
Here are things I've collected so far, that it would be good to have
in this little document. I have questions, also:
- CONNTRACK_MAX and HASHSIZE get default values at boot time.
By default, CONNTRACK_MAX = n * 64, where n is the RAM size in MB,
am I right?
What about HASHSIZE default value? How to read it at runtime?
What is the exact link between these 2 values?
- HASHSIZE should be an odd number, and even better: a prime number.
What happens when you set it to an even number, or a non-prime number?
Why enable people to set even and non-prime numbers at all?
- Default values are "reasonnable" for a typical host, but we may
increase them on high-loaded firewalling-only systems, right?
Which values are the "best"? I.e., can someone give a formula with
this potential parameters (if pertinent):
- total RAM size
- size of the memory that should be left for non-conntrack data in
the kernel and userspace in general (what is a reasonnable value for
a firewall doing only firewalling with very few applications
running, and how to measure that at runtime?)
- number of rules, connections rate, etc.
- CONNTRACK_MAX can be modified at run time with /proc. What does it
do exactly (when shinked, when extended)?
When you modify CONNTRACK_MAX, should you also modify HASHSIZE
accordingly? Why? How?
- Is it possible to modify HASHSIZE at runtime when ip_conntrack is
not compiled as a module? If not, shouldn't we enable this with
/proc, like CONNTRACK_MAX?
- Does any of these operations currently (or possibly, if soon
implemented) lead to some rehashing at runtime?
I suppose it would be quite slow... How long does/would it take?
How to proceed to keep current conntrack entries at runtime as much
as possible? (I suppose unloading ip_conntrack module and
reinserting it with another hashsize value clears the table...)
Please comment...
Herve
Can someone post a state of the art summary for netfilter conntrack
(and maybe NAT) performance tweaking?
The only things I'm currently aware of are:
- modprobe ip_conntrack hashsize=$HASHSIZE
- echo $CONNTRACK_MAX > /proc/sys/net/ipv4/ip_conntrack_max
I think it would be good to end up with a small document which would
give every detail about how to choose optimal values for HASHSIZE and
CONNTRACK_MAX, and every other mean to get the best out of the
conntracking/NAT system...
Here are things I've collected so far, that it would be good to have
in this little document. I have questions, also:
- CONNTRACK_MAX and HASHSIZE get default values at boot time.
By default, CONNTRACK_MAX = n * 64, where n is the RAM size in MB,
am I right?
What about HASHSIZE default value? How to read it at runtime?
What is the exact link between these 2 values?
- HASHSIZE should be an odd number, and even better: a prime number.
What happens when you set it to an even number, or a non-prime number?
Why enable people to set even and non-prime numbers at all?
- Default values are "reasonnable" for a typical host, but we may
increase them on high-loaded firewalling-only systems, right?
Which values are the "best"? I.e., can someone give a formula with
this potential parameters (if pertinent):
- total RAM size
- size of the memory that should be left for non-conntrack data in
the kernel and userspace in general (what is a reasonnable value for
a firewall doing only firewalling with very few applications
running, and how to measure that at runtime?)
- number of rules, connections rate, etc.
- CONNTRACK_MAX can be modified at run time with /proc. What does it
do exactly (when shinked, when extended)?
When you modify CONNTRACK_MAX, should you also modify HASHSIZE
accordingly? Why? How?
- Is it possible to modify HASHSIZE at runtime when ip_conntrack is
not compiled as a module? If not, shouldn't we enable this with
/proc, like CONNTRACK_MAX?
- Does any of these operations currently (or possibly, if soon
implemented) lead to some rehashing at runtime?
I suppose it would be quite slow... How long does/would it take?
How to proceed to keep current conntrack entries at runtime as much
as possible? (I suppose unloading ip_conntrack module and
reinserting it with another hashsize value clears the table...)
Please comment...
Herve
--
_
(°= Hervé Eychenne
//)
v_/_ WallFire project: http://www.wallfire.org/
_
(°= Hervé Eychenne
//)
v_/_ WallFire project: http://www.wallfire.org/