nf_conntrack: table full, dropping packet  连接跟踪表已满,开始丢包 的解决办法

中午业务说机器不能登录,我通过USM管理界面登录单板的时候发现机器没有僵死,然后一看日志,g一下子就明白了

tail -2000 /var/log/messages

Apr 10 12:48:35 bj-push-pushserver83 kernel: [95129.138804] __ratelimit: 16523 callbacks suppressed (“连接跟踪表已满,开始丢包”!相信不少用iptables的同学都会见过这个错误信息吧)

Apr 10 12:48:35 bj-xx kernel: [95129.138806] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.138974] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.139142] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.139566] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.139747] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.139823] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.140188] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.140435] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.140508] nf_conntrack: table full, dropping packet.

Apr 10 12:48:35 bj-xx kernel: [95129.141133] nf_conntrack: table full, dropping packet.

Apr 10 12:48:38 bj-xx kernel: [95131.483097] possible SYN flooding on port 443. Sending cookies.

Apr 10 12:49:01 bj-xx /usr/sbin/cron[9492]: (root) CMD (/usr/bin/tsar --cron > /dev/null 2>&1)

Apr 10 12:49:38 bj-xx kernel: [95191.382486] possible SYN flooding on port 443. Sending cookies.

Apr 10 12:50:01 bj-xx  /usr/sbin/cron[9761]: (root) CMD (/opt/huawei/logs/LoadRst/suseRst.sh 2>/dev/null)

Apr 10 12:50:01 bj-xx /usr/sbin/cron[9762]: (root) CMD (/usr/bin/tsar --cron > /dev/null 2>&1)

Apr 10 12:50:38 bj-xx kernel: [95251.283552] possible SYN flooding on port 443. Sending cookies.

Apr 10 12:51:01 bj-xx /usr/sbin/cron[9990]: (root) CMD (/usr/bin/tsar --cron > /dev/null 2>&1)

Apr 10 12:51:38 bj-xx kernel: [95311.185024] possible SYN flooding on port 443. Sending cookies.

Apr 10 12:52:01 bj-xx /usr/sbin/cron[10232]: (root) CMD (/usr/bin/tsar --cron > /dev/null 2>&1)

Apr 10 12:52:38 bj-xx kernel: [95371.082714] possible SYN flooding on port 443. Sending cookies.

Apr 10 12:52:59 bj-xx sshd[9994]: pam_unix2(sshd:auth): conversation failed

Apr 10 12:52:59 bj-xx sshd[9994]: error: ssh_msg_send: write

Apr 10 12:53:01 bj-xx /usr/sbin/cron[10891]: (root) CMD (/usr/bin/tsar --cron > /dev/null 2>&1)

Apr 10 12:53:38 bj-xx kernel: [95430.983871] possible SYN flooding on port 443. Sending cookies.

Apr 10 12:54:01 bj-xx /usr/sbin/cron[11097]: (root) CMD (/usr/bin/tsar --cron > /dev/null 2>&1)

Apr 10 12:54:04 bj-xx sshd[11094]: pam_tally(sshd:account): unknown option: reset

Apr 10 12:54:04 bj-xx sshd[11094]: Accepted publickey for root from 183.62.156.75 port 16959 ssh2

Apr 10 12:54:38 bj-xx kernel: [95490.883402] possible SYN flooding on port 443. Send

都是脚本和任务计划惹的祸

脚本内容

cat /opt/xx/logs/LoadRst/suseRst.sh

#!/bin/bash

cd `dirname $0`

loadnum=`uptime|awk -F':' '{print $4}'|awk -F',' '{print $1*1000}' `

fileDate=`date +"%Y%m%d_%H:%M:%S"`

#echo $fileDate

#echo $loadnum

#loadnum_ora=`uptime|awk -F':' '{print $4}'|awk -F',' '{print $2}' `

softirq=`top -bn 1|awk '/ksoftirqd/ {print $9}'|head -1`

echo -e $fileDate >>log

echo $softirq >>log

if [ $loadnum -ge  "900" ]

then

#echo "asdfasdf"

echo -e $fileDate >>log

/sbin/rcSuSEfirewall2 restart >> log 2>&1

#else

#echo -e "${fileDate}:success" >>log

fi

任务计划

crontab -l

# DO NOT EDIT THIS FILE - edit the master and reinstall.

# (/tmp/crontab.XXXXWNPsHE installed on Wed Apr  9 20:10:57 2014)

# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)

*/5 * * * * /opt/xx/logs/LoadRst/suseRst.sh 2>/dev/null

0 0 * * * /opt/xx/logs/Firewall_log/tar-firewall.sh >/dev/null 2>&1

解决办法

一、关闭防火墙。 简单粗暴,直接有效

#/etc/init.d/SuSEfirewall2_init stop

#/etc/init.d/SuSEfirewall2_setup stop

切记:在防火墙关闭状态下,不要通过iptables指令(比如 iptables -nL)来查看当前状态!因为这样会导致防火墙被启动,而且规则为空。虽然不会有任何拦截效果,但所有连接状态都会被记录,浪费资源且影响性能并可能导致防火墙主动丢包!

二、加大防火墙跟踪表的大小,优化对应的系统参数

1、状态跟踪表的最大行数的设定,理论最大值

CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (ARCH / 32)

以64G的64位操作系统为例

CONNTRACK_MAX = 64*1024*1024*1024/16384/2 = 2097152

即时生效请执行:

sysctl –w net.netfilter.nf_conntrack_max = 2100000

或者

vi /etc/sysctl.conf

net.netfilter.nf_conntrack_max = 2100000

sysctl -p

2、其哈希表大小通常为总表的1/8,最大为1/2。

CONNTRACK_BUCKETS = CONNTRACK_MAX / 8

同样64G的64位操作系统,哈希最佳范围是 262144 ~ 1048576 。

运行状态中查看

sysctl net.netfilter.nf_conntrack_buckets

通过文件 /sys/module/nf_conntrack/parameters/hashsize 进行设置。

或者新建 /etc/modprobe.d/iptables.conf,重新加载模块才生效:

options nf_conntrack hashsize=262144

3、还有些相关的系统参数`sysctl -a | grep nf_conntrack`可以调优(/etc/sysctl.conf ):

net.netfilter.nf_conntrack_max = 1048576

net.netfilter.ip_conntrack_tcp_timeout_established = 3600

net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60

net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120

net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120

三、使用祼表,添加“不跟踪”标识。如下示例更适合桌面系统或随意性强的服务器。因为它开启了连接的状态机制,方便和外部通信。修改 /etc/sysconfig/iptables 文件:

*raw

# 对TCP连接不启用追踪,解决ip_contrack满导致无法连接的问题

-A PREROUTING -p tcp -m tcp --dport 80 -j NOTRACK

-A PREROUTING -p tcp -m tcp --dport 22 -j NOTRACK

-A PREROUTING -p tcp -m tcp --dport 21 -j NOTRACK

-A PREROUTING -p tcp -m tcp --dport 11211 -j NOTRACK

-A PREROUTING -p tcp -m tcp --dport 60000:60100 -j NOTRACK

-A PREROUTING -p tcp -s 192.168.10.1 -j NOTRACK

-A OUTPUT -p tcp -m tcp --sport 80 -j NOTRACK

-A OUTPUT -p tcp -m tcp --sport 22 -j NOTRACK

-A OUTPUT -p tcp -m tcp --sport 21 -j NOTRACK

-A OUTPUT -p tcp -m tcp --sport 11211 -j NOTRACK

-A OUTPUT -p tcp -m tcp --sport 60000:60100 -j NOTRACK

-A OUTPUT -p tcp -s 192.168.10.1 -j NOTRACK

COMMIT

*filter

# 允许ping

-A INPUT -p icmp -j ACCEPT

# 对本地回路、第5张网卡放行

-A INPUT -i lo -j ACCEPT

-A INPUT -i eth4 -j ACCEPT

# 连接状态跟踪,已建立的连接允许传输数据

-A INPUT -m state --state ESTABLISHED,RELATED,INVALID,UNTRACKED -j ACCEPT

# filter表里存在但在raw里不存在的,默认会进行连接状态跟踪

-A INPUT -s 192.168.10.31 -p tcp --dport 2669 -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-host-prohibited

-A FORWARD -j REJECT --reject-with icmp-host-prohibited

COMMIT

或者干脆对所有连接都关闭跟踪,不跟踪任何连接状态。不过规则就限制比较严谨,进出都需要显式申明。示例如下:

*raw

# 对TCP/UDP连接不启用追踪,解决nf_contrack满导致无法连接的问题

-A PREROUTING -p tcp -j NOTRACK

-A PREROUTING -p udp -j NOTRACK

-A OUTPUT -p tcp -j NOTRACK

-A OUTPUT -p udp -j NOTRACK

COMMIT

*filter

# 允许ping

-A INPUT -p icmp -j ACCEPT

# 对本地回路和eth1放行

-A INPUT -i lo -j ACCEPT

-A INPUT -i eth1 -j ACCEPT

# 只允许符合条件的连接进行传输数据

-A INPUT -p tcp --dport 22 -j ACCEPT

-A INPUT -p tcp --sport 80 -j ACCEPT

-A INPUT -p udp --sport 53 -j ACCEPT

-A INPUT -p udp --sport 123 -j ACCEPT

# 出去的包都不限制

-A OUTPUT -p tcp -j ACCEPT

-A OUTPUT -p udp -j ACCEPT

# 输入和转发的包不符合规则的全拦截

-A INPUT -j REJECT --reject-with icmp-host-prohibited

-A FORWARD -j REJECT --reject-with icmp-host-prohibited

COMMIT

效果如下图:

四、删除连接跟踪模块`lsmod | grep nf_conntrack`,不使用连接状态的跟踪功能。

1、删除nf_conntrack和相关的依赖模块,示例:

rmmod nf_conntrack_ipv4

rmmod nf_conntrack_ipv6

rmmod xt_state

rmmod xt_CT

rmmod xt_conntrack

rmmod iptable_nat

rmmod ipt_REDIRECT

rmmod nf_nat

rmmod nf_conntrack

2、禁用跟踪模块,把它加到黑名单(/etc/modprobe.d/blacklist.conf ):

# 禁用 nf_conntrack 模块

blacklist nf_conntrack

blacklist nf_conntrack_ipv6

blacklist xt_conntrack

blacklist nf_conntrack_ftp

blacklist xt_state

blacklist iptable_nat

blacklist ipt_REDIRECT

blacklist nf_nat

blacklist nf_conntrack_ipv4

3、去掉防火墙里所有和状态相关的配置(比如state状态,NAT功能),示例:

*filter

# 允许ping

-A INPUT -p icmp -j ACCEPT

# 对本地回路和第2张网卡放行

-A INPUT -i lo -j ACCEPT

-A INPUT -i eth1 -j ACCEPT

# 对端口放行

-A INPUT -p tcp --dport 1331 -j ACCEPT

# 对IP放行

-A INPUT -s 192.168.10.31 -j ACCEPT

#允许本机进行DNS查询

-A INPUT -p udp --sport 53 -j ACCEPT

-A OUTPUT -p udp -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-host-prohibited

-A FORWARD -j REJECT --reject-with icmp-host-prohibited

COMMIT

另外,防火墙的配置文件最好也改下,不要加载任何额外模块(/etc/sysconfig/iptables-config):

IPTABLES_MODULES="" # 不需要任何附加模块

IPTABLES_MODULES_UNLOAD="no" # 避免iptables重启后sysctl中对应的参数被重置为系统默认值

IPTABLES_SAVE_ON_STOP="no"

IPTABLES_SAVE_ON_RESTART="no"

IPTABLES_SAVE_COUNTER="no"

IPTABLES_STATUS_NUMERIC="yes"

IPTABLES_STATUS_VERBOSE="no"

IPTABLES_STATUS_LINENUMBERS="no"

往往我们对连接的跟踪都是基于操作系统的(netstat / ss ),防火墙的连接状态完全是它自身实现产生的。

本文出自 “” 博客,请务必保留此出处http://2364821.blog.51cto.com/2354821/1393736

[转]nf_conntrack: table full, dropping packet 连接跟踪表已满,开始丢包 的解决办法的更多相关文章

  1. 路由跟踪表满,日志报错nf_conntrack: table full, dropping packet.

    “连接跟踪表已满,开始丢包”!相信不少用iptables的同学都会见过这个错误信息吧,这个问题曾经也困扰过我好长一段时间.此问题的解决办法有四种(nf_conntrack 在CentOS 5 / ke ...

  2. ocalhost kernel: [244840.301449] nf_conntrack: nf_conntrack: table full, dropping packet

    nf_conntrack: table full, dropping packet. 终结篇   "连接跟踪表已满,开始丢包"!相信不少用iptables的同学都会见过这个错误信息 ...

  3. kernel nf_conntrack: table full, dropping packet[转载]

    http://blog.yorkgu.me/2012/02/09/kernel-nf_conntrack-table-full-dropping-packet/ 综合:ip_conntrack就是li ...

  4. ECS实例中的应用偶尔出现丢包现象并且内核日志(dmesg)存在“kernel: nf_conntrack: table full, dropping packet”的报错信息

    问题描述 连接ECS实例中的应用时偶尔出现丢包现象.经排查,ECS实例的外围网络正常,但内核日志(dmesg)中存在"kernel: nf_conntrack: table full, dr ...

  5. ip_conntrack or nf_conntrack : table full, dropping packet

    nf_conntrack: table full, dropping packet ip_conntrack or nf_conntrack : table full, dropping packet ...

  6. linux云主机cpu一直很高降不下来,系统日志报nf_conntrack: table full, dropping packet.

    在启用了iptables web服务器上,流量高的时候经常会出现下面的错误: ip_conntrack: table full, dropping packet 这个问题的原因是由于web服务器收到了 ...

  7. nf_conntrack: table full, dropping packet. 问题

    查出目前 ip_conntrack 记录最多的前十名 IP: # cat /proc/net/nf_conntrack|awk '{print $8}'|cut -d'=' -f 2|sort |un ...

  8. 解决nf_conntrack: table full, dropping packet问题

    " > /proc/sys/net/nf_conntrack_max iptables -t raw -A PREROUTING -p tcp -m tcp --dport -j NO ...

  9. nf_conntrack: table full, dropping packet解决方法

    https://blog.csdn.net/yanggd1987/article/details/45886913

随机推荐

  1. Android -- 获取视频第一帧缩略图

    干货 从API 8开始,新增了一个类: android.media.ThumbnailUtils这个类提供了3个静态方法一个用来获取视频第一帧得到的Bitmap,2个对图片进行缩略处理. public ...

  2. 最新自然语言处理(NLP)四步流程:Embed->Encode->Attend->Predict

    http://blog.csdn.net/jdbc/article/details/53292414 过去半年以来,自然语言处理领域进化出了一件神器.此神器乃是深度神经网络的一种新模式,该模式分为:e ...

  3. Spring(十一):Spring配置Bean(四)SpEL

    Spring表达式语言:SpEL 1)Spring表达式语言(简称SpEL):是一个支持运行时查询和操作对象图的强大的表达式语言. 2)语法类似于EL:SpEL使用#{...}作为界定符,所有在大框号 ...

  4. Android版-微信APP支付

    首发地址: Android版-微信APP支付 欢迎留言.转发 微信极速开发系列文章(微信支付.授权获取用户信息等):点击这里 目录 1.注册账号.开发者认证 2.添加应用 3.申请微信支付 4.技术开 ...

  5. Linux网络编程:基于TCP的程序开发回顾篇《转》

    面向连接的TCP程序设计 基于TCP的程序开发分为服务器端和客户端两部分,常见的核心步骤和流程: 其实按照上面这个流程调用系统API确实可以完全实现应用层程序的开发,一点问题没有.可随着时间的推移,你 ...

  6. Your account already has a signing certificate for this machine but it is not present in your keycha

    转载自:https://blog.csdn.net/csdn2314/article/details/73124117 Your account already has a signing certi ...

  7. JQuery 之 在数据加载完成后才自动执行函数

    数据加载完成执行: $(window).load(function(){ ... }); 进入页就执行,不论等数据是否加载完成: $(document).ready(function(){ ... } ...

  8. 微软BI 之SSAS 系列 - 在 SQL Server 2012 下查看 SSAS 分析服务的模型以及几个模型的简单介绍

    在SSDT中部署一个 SSAS 项目到本地服务器上出现错误. You cannot deploy the model because the localhost deployment server i ...

  9. Nginx 访问日志分析

    0:Nginx日志格式配置 # vim nginx.conf ## # Logging Settings ## log_format access '$remote_addr - $remote_us ...

  10. NGINX源代码自我总结(一)

    查看源代码入门 这是一篇关于NGINX的MAIN()函数入门说明文章,相比其他这篇十分枯燥,其实写的时候更是无聊,不过学了这么长时间的WEB开发,连NGINX源代码都没有读下来,总是觉得有些缺憾,希望 ...