On Fri, 11 May 2012, "Trent W. Buck" <trentbuck@gmail.com> wrote:
ip_conntrack_max was defaulting to around 5500 (a default based on 16MB memory I guess).
Hm; it hadn't occurred to me that it might be based on RAM size. I had assumed that was simply a hard-coded default in the kernel.
On an Ubuntu 10.04 x86_64 router with 3½GB of RAM it's 64k. On an OpenWRT backfire / TP-1043ND (32MB volatile RAM) it's 16k.
On a Squeeze system with 350M of RAM it's 21660 and on a Squeeze system with 512M of RAM it's 32100. On CentOS 5.7 with 384M of RAM it's 24512. But it's writable, so you should be able to increase it significantly if you need to. Even in the unlikely event that each connection took 1K of RAM then a 512M system could handle a lot more than 32100 entries! But I'm not sure that this would necessarily solve the problem. On my home network with a 512M system as the gateway I had problems with connection loss until I configured ssh (the only thing that holds long idle connections) to use ssh protocol keep alives (I never tested with TCP keep alives as I don't think they are useful for ssh - or any other protocol that supports checks). Even if Lenny had significantly smaller defaults than Squeeze (which seems quite unlikely as CentOS doesn't have small defaults) that wouldn't explain why a system that should be able to track thousands of connections starts failing when there are two client systems in use which aren't heavily loaded. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/