Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

In /proc I have two entries for nf_conntrack_max:

/proc/sys/net/netfilter/nf_conntrack_max
/proc/sys/net/nf_conntrack_max

The seem to point to the same value as changing one also changes the other. With both of these set in /etc/sysctl.conf:

net.netfilter.nf_conntrack_max=65528
net.ipv4.netfilter.ip_conntrack_max=65535

The value remains 32764 after a reboot so the changes are not working. Has anyone run into this before? My guess would be that these values are applied before the modules relevant are loaded but was hoping maybe someone already knows the solution.

share|improve this question
    
Did you ever find a solution to this? –  Stu Thompson Apr 7 '11 at 6:06
    
@Stu: Nope, I just got lazy and wrote a cron job to set these :-P –  Kyle Brandt Apr 7 '11 at 10:24

3 Answers 3

it's because /proc/sys/net/nf_conntrack_max is rely on the module nf_conntrack. but by default system will not load this module when system start.

but if you run

iptables -t nat -L

or

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

this module will load automatically and set to the max number that your system support (the max number is 65536 if you ram is > 4G, but actually you can set it to a even bigger number manually or set it in /etc/sysctl.conf).

the easiest way to active it on system start is add one line

nf_conntrack

at the bottom of the file /etc/modules. this modules would be loaded on system start before sysctl executed.

share|improve this answer

Because it should be:

net.netfilter.nf_conntrack_max = 65535

And now you can set this without restarting with: sysctl -p /etc/sysctl.conf

share|improve this answer

I don't use Ubuntu, but thinking about this in my CentOS frame-of-mind, I came up with the same hypothesis that you did-- the sysctls are being applied too early. Some seaching revealed that this has been a filed bug since 2006.

It looks like putting another symlink in at priority > S40 to run the procps init script again would probably do what you need. Per the bug summary, it looks like some re-architechting of the Ubuntu sysctl methodology is in order (and, amusingly, the bug was assigned to somebody who didn't know it was assigned and can't help with it).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.