My sysctl.conf contains net.ipv4.netfilter.ip_conntrack_max = 524288 but bootmisc is either not loading this (unlikely) or there is an ordering problem preventing it becoming active.
Uh, this is way too much for standard hashsize, won't work. Even if you load the module properly with altered hashsize, this value is so crazy your firewall will become unusably slow way before this limit would be reached. (And note that ~350 bytes per connection of memory (which cannot be swapped) is required per connection). http://www.wallfire.org/misc/netfilter_conntrack_perf.txt
(524288 * 350 is a ~180 meg hash - can it really not deal with that?) The problem still exists though - net.ipv4.netfilter.ip_conntrack_max settings in sysctl.conf are being ignored..
(In reply to comment #2) > (524288 * 350 is a ~180 meg hash - can it really not deal with that?) You don't understand, you need to *set* appropriate hashsize if you want such huge number of connections tracked, it won't work w/ the default value. The default is 8192 for boxes w/ 1GB+ of RAM (and CONNTRACK_MAX is 8x the default max hashsize). echo $HASHSIZE > /sys/module/nf_conntrack/parameters/hashsize (w/ 2.6.20+ kernels). Read the above-reffered link for more details.
regardless, it isnt a userspace issue as sysctl does its things by writing the values into the kernel if the value isnt getting set or "sticking", then the problem is elsewhere there is no ordering problem as nothing else from Gentoo will write to sysctl
So the problem is not that the sysctl value is being rejected because the netfilter module is not loaded? Okay good. Thanks.
For the original poster, check if the conntrack module is loaded when the sysctl runs. I bet it's not. Other than that, I'd like to strongly discourage you from it. You really don't want to be using conntrack for high performance systems. Just loading the module massively eats into performance and leads to lots of packet loss, this is from experience, running a site with >75K PPS of TCP traffic. If you're using it for IPVS-NAT, I strongly suggest moving to IPVS-DR instead, yes you'll need an extra machine to implement it, but it will work a lot better.
