ping环回地址丢包

2025/9/23镜像同步5 回复

# ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.096 ms 64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.078 ms 64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.060 ms 64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=0.060 ms 64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=0.084 ms 64 bytes from 127.0.0.1: icmp_seq=10 ttl=64 time=0.075 ms 64 bytes from 127.0.0.1: icmp_seq=11 ttl=64 time=0.091 ms 64 bytes from 127.0.0.1: icmp_seq=22 ttl=64 time=0.072 ms 64 bytes from 127.0.0.1: icmp_seq=23 ttl=64 time=0.071 ms 64 bytes from 127.0.0.1: icmp_seq=24 ttl=64 time=0.079 ms 64 bytes from 127.0.0.1: icmp_seq=25 ttl=64 time=0.063 ms 64 bytes from 127.0.0.1: icmp_seq=26 ttl=64 time=0.083 ms 64 bytes from 127.0.0.1: icmp_seq=27 ttl=64 time=0.082 ms 64 bytes from 127.0.0.1: icmp_seq=28 ttl=64 time=0.071 ms 64 bytes from 127.0.0.1: icmp_seq=29 ttl=64 time=0.071 ms 64 bytes from 127.0.0.1: icmp_seq=30 ttl=64 time=0.058 ms 64 bytes from 127.0.0.1: icmp_seq=31 ttl=64 time=0.069 ms 64 bytes from 127.0.0.1: icmp_seq=32 ttl=64 time=0.052 ms 64 bytes from 127.0.0.1: icmp_seq=33 ttl=64 time=0.071 ms 64 bytes from 127.0.0.1: icmp_seq=34 ttl=64 time=0.069 ms 64 bytes from 127.0.0.1: icmp_seq=35 ttl=64 time=0.069 ms 64 bytes from 127.0.0.1: icmp_seq=36 ttl=64 time=0.069 ms 64 bytes from 127.0.0.1: icmp_seq=37 ttl=64 time=0.071 ms 64 bytes from 127.0.0.1: icmp_seq=38 ttl=64 time=0.070 ms 64 bytes from 127.0.0.1: icmp_seq=39 ttl=64 time=0.074 ms 64 bytes from 127.0.0.1: icmp_seq=40 ttl=64 time=0.072 ms 64 bytes from 127.0.0.1: icmp_seq=41 ttl=64 time=0.069 ms 64 bytes from 127.0.0.1: icmp_seq=42 ttl=64 time=0.084 ms 64 bytes from 127.0.0.1: icmp_seq=43 ttl=64 time=0.074 ms ^C --- 127.0.0.1 ping statistics --- 43 packets transmitted, 29 received, 32.5581% packet loss, time 43015ms rtt min/avg/max/mdev = 0.052/0.072/0.096/0.009 ms 机器为88核心768G内存，系统负载并不高。 %Cpu(s): 11.0 us, 0.8 sy, 0.0 ni, 88.1 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st 谁有什么思路？

订阅后，新回复会通过你的通知中心匿名送达。

5 条回复

redsand机器人#1 · 2025/9/23

帖子发的太快了，发完了就找到原因了，dmesg里面显示 [627864.064871] nf_conntrack: nf_conntrack: table full, dropping packet [627864.065655] nf_conntrack: nf_conntrack: table full, dropping packet [627864.066208] nf_conntrack: nf_conntrack: table full, dropping packet [627864.066216] nf_conntrack: nf_conntrack: table full, dropping packet [627864.066626] nf_conntrack: nf_conntrack: table full, dropping packet /etc/sysctl.conf里面配置的net.netfilter.nf_conntrack_max=6553600 不知道为什么没有应用上

yzwddsg机器人#2 · 2025/9/24

短连接太多了把nf conntrack表给打满了嘛这是也可以把nf_conntrack相关的timewait调小试一下

redsand机器人#3 · 2025/9/24

多谢，回头试试这些参数都什么取值在我的环境比较合适。【在 yzwddsg 的大作中提到: 】 : 短连接太多了把nf conntrack表给打满了嘛这是 : 也可以把nf_conntrack相关的timewait调小试一下

redsand机器人#4 · 2025/11/28

最终决定把net.netfilter.nf_conntrack_tcp_timeout_syn_sent从默认的120改成60

redsand机器人#5 · 2026/1/29

后来把环境当中大多数节点的net.netfilter.nf_conntrack_tcp_timeout_syn_sent都设置成了15秒，只要少数几台机器是60秒和120秒。配合上检测封堵的脚本，竟然防住了一大波持续了好几个小时的攻击，没有客户工单反馈网络问题，封了敌人好几百个IP，哼！观察下来发现设置15秒的都没丢包，60秒和120秒的有有限的丢包，这是因为检测脚本运行一次间隔有大几秒的时间，而大量syn flooding来了以后因为conntrack表比较大所以排序计算归纳本身也需要至少大几秒的时间，60秒以上还是有可能把表打满，所以看起来和检测脚本配合起来还是15秒超时为佳。反正正常连接的话如果15秒都连不上应该也没必要连了。