追踪表满导致keepalived vip 不通！
问题：zabbix 突然报警，vip 不通了，
解决方法：将vip 所在的机器的keepalived 服务给关闭，vip 则会飘到另外一台机器上，vip立即恢复正常！
后来查到是追踪表的问题的导致的！从网上找到追踪表的相关资料如下：追踪表最大数目的确定：
nf_conntrack模块：
在iptables不同的表中，都会用到nf_conntrack模块来进行连接跟踪，而对应nf_conntrack的数据库为/proc/net/nf_conntrack(rhel6/centos6)。
有个简单的计算方式：
conntrack_max=ramsize（bytes)/16384/(x/32)
其中的x为你的系统地址位数，若操作系统为32位则x为32，若是64位x就等于64。其默认值为32768。如果你的操作系统为64位，8G内存，则nf_conntrack_max的为8192×1024×1024/16384/（64/32）=262144
若使用中的连接跟踪数量超过了最大连接数量，超出的部分无法被防火墙所接受，也就无法去应用防火墙去使用了。如果超出了，在/var/log/messages文件中将会看到错误消息“nf_conntrack:table full,dropping packet”，所以如果你觉得数量不够了，就可以通过增加内存去扩大连接数量上限。
而这个链接跟踪其实是有最大连接数量限制的。而其默认值会根据实际内存的大小而改变。
ip_conntrack:table full, dropping packet
错误信息：
在启用了iptables 的服务器上，流量高的时候经常会出现下面的错误
ip_conntrack: table full, dropping packet |
这个问题的原因是由于服务器收到了大量的连接，在启用了iptables的情况下，iptables会把所有的连接都做链接跟踪处理，这样iptables就会有一个链接跟踪表，当这个表满的时候，就会出现上面的错误。
iptables的链接跟踪表最大容量为 sysctl -a | grepnet.nf_conntrack_max，链接碰到各种状态的超时后就会从表中删除。
解決方法
1.增加 ip_conntrack_max 值
复制代码
vim/etc/sysctl.conf #添加如下 net.nf_conntrack_max = 102400 sysctl -p |
2.iptables的raw表是不做数据包的链接跟踪处理的，并且优先级最高，我们可以把那些连接量非常大的链接加入到iptables raw表。
复制代码
iptables -t raw -A PREROUTING -d 1.2.3.4 -p tcp --dport 80 -j NOTRACK iptables -A FORWARD -m state --state UNTRACKED -j ACCEPT |
查看追踪表当前的数目：
wc -l /proc/net/nf_conntrack
注意：在防火墙关闭的状态下，不要使用iptables -L -vnx来查看状态！因为这样会导致防火墙被启动，而且规则为空。虽然不会有任何拦截效果，但所有连接状态都会被记录，浪费资源且影响性能并可能导致防火墙主动丢包！
摘之阿里云：
现象：突然发现访问网站很慢，服务器的cpu、内存和磁盘使用率都正常
分析过程及解决方案：查询/var/log/message日志发现有这样的记录“ip_conntrack table fulldropping packet”。kernel 用 ip_conntrack 模块来记录 iptables 网络包的状态，并保存到 table 里（这个 table 在内存里），如果网络状况繁忙，比如高连接，高并发连接等会导致逐步占用这个 table 可用空间，一般这个 table 很大不容易占满并且可以自己清理，table 的记录会一直呆在 table 里占用空间直到源 IP 发一个 RST 包，但是如果出现被攻击、错误的网络配置、有问题的路由/路由器、有问题的网卡等情况的时候，就会导致源 IP 发的这个 RST 包收不到，这样就积累在 table 里，越积累越多直到占满，满了以后 iptables 就会丢包，出现外部无法连接服务器的情况。
还遇到了问题：