服务器出现 server kernel: ip_conntrack: table full, dropping packet. 问题
# cat /var/log/messages
...
Nov 8 08:54:58 server kernel: ip_conntrack: table full, dropping packet.
Nov 8 08:55:03 server kernel: printk: 49 messages suppressed.
Nov 8 08:55:03 server kernel: ip_conntrack: table full, dropping packet.
Nov 8 08:55:08 server kernel: printk: 49 messages suppressed.
...
当出现该问题的时候,TELNET连接80端口也连接不上,这样会导致新的外网请求不能进入;而如果使用keepalived来检测80端口存活的话,keepalived也会认为服务器down机。
越到这种问题,首先查看当前 ip_conntrack 记录,已经有 36271,超过了系统设置的 16640 :
$ head /proc/slabinfo
slabinfo - version: 2.1
# name
: tunables
: slabdata
ip_conntrack_expect 0 0 192 20 1 : tunables 120 60 8 : slabdata 0 0 0
ip_conntrack 36271 36216 384 10 1 : tunables 54 27 8 : slabdata 1612 1612 108
# cat /proc/sys/net/ipv4/ip_conntrack_max
16640
出现这种问题,是由于iptables增加了conntrack模块,用于检测tcp的连接状态
kernel 用 ip_conntrack 模块来记录 iptables 网络包的状态,并保存到 table 里(这个 table 在内存里),如果网络状况繁忙,比如高连接,高并发连接等会导致逐步占用这个 table 可用空间,
一般这个 table 很大不容易占满并且可以自己清理,table 的记录会一直呆在 table 里占用空间直到源 IP 发一个 RST 包,
但是如果出现被攻击、错误的网络配置、有问题的路由/路由器、有问题的网卡等情况的时候,就会导致源 IP 发的这个 RST 包收不到,这样就积累在 table 里,越积累越多直到占满,
满了以后 iptables 就会丢包,出现外部无法连接服务器的情况。
知道问题就好办了,要么增加 table 容量以便能记录更多的连接信息(会消耗一点内存),要么就卸载 ip_conntrack 模块。
查看当前 ip_conntrack_max 设置,然后增加16倍到 1048576:
net.ipv4.ip_conntrack_max = 1048576
net.ipv4.netfilter.ip_conntrack_max = 1048576
还有一个参数 ip_conntrack_tcp_timeout_established 需要注意,默认情况下 timeout 是5天(432000秒),需要降低:
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
综合一下,最好把这些内核参数加到 sysctl.conf 文件以便系统启动后自动读取中:
sysctl -p
还有一种办法就是直接卸载 ip_conntrack 模块,这个办法最简单,到在 /etc/sysconfig/iptables-config 文件里删除或者注释掉 ip_conntrack_netbios_ns 后重启系统:
# vi /etc/sysconfig/iptables-config
#IPTABLES_MODULES="ip_conntrack_netbios_ns"
# shutdown -r now
本文出自 “麦麦的运维之路” 博客,请务必保留此出处http://xiaomaimai.blog.51cto.com/1182965/833181