nf_conntrack记录不对

      用内核版本分别为2.6.18、2.16.23和2.6.25三台机器做大并发的NAT服务器。三个服务器是级联的，从lan至wan分别 是：2.6.25-->2.623-->2.6.18。三个服务器做了如下的相同配置：
i）将它们的并发连接数nf_conntrack_max都改成了131072；
ii）相应的hashsize通过 echo 32768 > sys/module/nf_conntrack/parameters/hashsize改成了32768,但expect_hashsize保持为默 认值；
iii）相应的nf_conntrack_tcp_timeout_established 改成了1500s。
   出现的问题如下：
i）2.6.23的的nf_conntrack_count曾累积趋势，虽然有时候也下降了一些，但总体趋势是增加的，而另外两个内核的 nf_conntrack_count随网络状况能动态的更新。
ii）cat /proc/net/nf_conntrack > wc -l，发现2.6.23的nf_conntrack 记录总只有nf_conntrack_count的一半左右，而其他两个内核的记录数和nf_conntack持平；
iii）cat /proc/slabinfo，发现2.6.23所占用的slab存储与nf_conntrack_count是一致的（当然，其它两个内核也是一致的）

    因为三个服务器是级联的，所以三者的nf_conntrak_count应基本一致，所以从问题i)~iii)看来，2.6.23中的nf_conntrack连接没有及时释放，而且其记录信息不全，感觉是内核的bug（因为其他原因，换内核工作量太大）。请问该如何解决这些问题呢？毕竟连接数如果总是累加，就会很快达到 我们的设定上限的~~
####

解决方法：

net.netfilter.nf_conntrack_max = 655360
net.netfilter.nf_conntrack_tcp_timeout_established = 180

-----

net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
fs.inotify.max_user_watches = 65536
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.route.gc_interval = 1
net.ipv4.route.gc_timeout = 150
net.ipv4.route.gc_elasticity = 2
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 1024    65000
net.core.rmem_max = 16777216
net.core.wmem_default = 8388608
net.core.wmem_max=16777216
net.core.rmem_default = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 262144
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_retries2=7
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_timestamps=0
net.ipv4.tcp_window_scaling= 1
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_sack=1
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_keepalive_time=30
net.ipv4.tcp_keepalive_probes=2
net.ipv4.tcp_keepalive_intvl=2
net.ipv4.tcp_max_tw_buckets = 1200000
net.ipv4.ip_conntrack_max = 655360
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 180

或者###

fs01:~ # lsmod | grep conntrack
nf_conntrack_ipv4      12792  3 iptable_nat,nf_nat
nf_conntrack           80480  3 iptable_nat,nf_nat,nf_conntrack_ipv4

 

rmmod   nf_conntrack_ipv4   nf_conntrack  

 

#####

nf_conntrack: table full, dropping packet.

If you see this message "nf_conntrack: table full, dropping packet" in your syslog on a Linux box, it's likely that it's having comms problems. I saw this recently on a DNS server that looked like it was being attacked. The problem is that when this happens, normal DNS resolution is interrupted.

I haven't found a decent solution yet, but it seems that if the system has lots of RAM then you can increase the nf_conntrack_max kernel parameter (my system is running iptables, which I assume the "netfilter" module has something to do with).

On a 2.6 kernel, you can go to /proc/sys/net/netfilter and check some of the values. For instance, nf_conntrack_count shows you the current value while nf_conntrack_max is the maximum value that is set.

You can just cat these values or use sysctl to view them:

# sysctl net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_max = 65536

# sysctl net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_count = 45033

To change the value, use the -w switch (in this example I've doubled the value):

# sysctl -w net.netfilter.nf_conntrack_max=131072

I think that in order to make this permanent across reboots, you'll need to add this line to the bottom of /etc/sysctl.conf:

net.netfilter.nf_conntrack_max=131072