网络丢包排查方法

一、硬件网卡丢包

1.Ring Buffer溢出

Ring Buffer（环形缓冲区）溢出是指当往一个已经满了的环形缓冲区中写入数据时，会覆盖之前存储在缓冲区中的数据。这种情况通常发生在写入速度快于读取速度的情况下。

1.查看Ring Buffer满而丢弃的包统计(fifo字段)
$ ethtool -S eth0|grep rx_fifo
rx_fifo_errors: 0
$ cat /proc/net/dev
Inter-|Receive | Transmitface |bytes packets errs drop fifo frame compressed 
multicast|bytes packets errs drop fifo colls carrier compressed
eth0: 17253386680731 42839525880 0 0 0 0 0 244182022 14879545018057 41657801805 0 0 0 0 0 0

2.查看网卡Ring Buffer最大值和当前设置
ethtool -g eth0

3.修改网卡接收与发送硬件缓存区大小
ethtool -G eth0 rx 4096 tx 4096

2.网卡端口协商丢包

1.查看网卡和上游网络设备协商速率和模式
➜  ~ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.19.6.105  netmask 255.255.192.0  broadcast 172.19.63.255
        ether 00:16:3e:18:9f:57  txqueuelen 1000  (Ethernet)
        RX packets 11631990  bytes 3611913450 (3.3 GiB)
        RX errors 0  dropped 216  overruns 0  frame 0
        TX packets 10461655  bytes 2946312189 (2.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
➜  ~ ethtool -i eth0
driver: virtio_net
version: 1.0.0
firmware-version:
expansion-rom-version:
bus-info: 0000:00:03.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
➜  ~ ethtool -S eth0
no stats available 

➜  ~ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  eth0: 3611947360 11632489    0    0    0     0          0         0 2946427291 10462601    0    0    0     0       0          0
    lo:    4215      78    0    0    0     0          0         0     4215      78    0    0    0     0       0          0

2.重新协商
ethtool -r eth1/eth0

3.强制设置端口速率
ethtool -s eth1 speed 1000 duplex full autoneg off

3.网卡流控丢包

网卡流控丢包问题通常是由于发送和接收速率不匹配导致的

1.查看网卡的流控设置
ethtool -a eth0

确保发送方和接收方速率一致：如果发送方的速率大于接收方，则可能会出现丢包情况。你可以通过调整两端设备的速率来解决该问题

2.关闭网卡流控
ethtool -A ethx autoneg off //自协商关闭
ethtool -A ethx tx off //发送模块关闭
ethtool -A ethx rx off //接收模块关闭

二、网卡驱动丢包

1.查看丢包信息

ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.134  netmask 255.255.255.0  broadcast 192.168.100.255
        inet6 fe80::20c:29ff:feb4:5883  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:b4:58:83  txqueuelen 1000  (Ethernet)
        RX packets 102430  bytes 137887910 (131.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0 #主要此行
        TX packets 27457  bytes 3144190 (2.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

字段解析：

(1)RX errors:表示总的收包的错误数量，还包括too-long-frames错误，Ring Buffer 溢出错误，crc 校验错误，帧同步错误，fifo overruns 以及 missed pkg 等等。
(2)RX dropped:表示数据包已经进入了 Ring Buffer，但是由于内存不够等系统原因，导致在拷贝到内存的过程中被丢弃。
(3)RX overruns:overruns 意味着数据包没到 ring buffer 就被网卡物理层给丢弃了，当驱动处理速度跟不上网卡收包速度时，驱动来不及分配缓冲区，NIC 接收到的数据包无法及时写到 skb，就会产生堆积。当 NIC 内部缓冲区写满后，就会丢弃部分数据，引起丢包。
这部分丢包为 rx_fifo_errors，在 /proc/net/dev 中体现为 fifo 字段增长，在 ifconfig 中体现为 overruns 指标增长，CPU无法及时的处理中断是造成 ring ruffer 满的原因之一，例如中断分配的不均匀。或者 ring buffer 太小导致的。
(4)RX frame: 表示 misaligned 的 frames,对于 TX 的来说，出现上述 counter 增大的原因主要包括 aborted transmission, errors due to carrirer, fifo error, heartbeat erros 以及 windown error，而 collisions 则表示由于 CSMA/CD 造成的传输中断

2.驱动溢出丢包

netdev_max_backlog是内核从NIC收到包后，交由协议栈（如IP、TCP）处理之前的缓冲队列。每个CPU核都有一个backlog队列，与Ring Buffer同理，当接收包的速率大于内核协议栈处理的速率时，CPU的backlog队列不断增长，当达到设定的netdev_max_backlog值时，数据包将被丢弃。

1.查看是否发生netdev backlog队列溢出
00000027 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00007f82 00000000 00000010 00000000 00000000 00000000 00000000 00000000 00000000 00000000

每一行代表每个CPU核的状态统计，从CPU0依次往下

每一列代表一个CPU核的各项统计：
第一列代表中断处理程序收到的包总数；
第二列即代表由于netdev_max_backlog队列溢出而被丢弃的包总数。从上面的输出可以看出，这台服务器统计中，并没有因为netdev_max_backlog导致的丢包,netdev_max_backlog(接收) 和 txqueuelen(发送) 相对应。


2.netdev backlog队列溢出解决方案
netdev_max_backlog的默认值是1000，在高速链路上，可能会出现上述第二统计不为0的情况，可以通过修改内核参数net.core.netdev_max_backlog来解决
sysctl -w net.core.netdev_max_backlog=2000

3.频繁网卡IRQ导致丢包

1.查看是否存在网卡 IRQ频繁导致的丢包
00000027 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00007f9c 00000000 00000010 00000000 00000000 00000000 00000000 00000000 00000000 00000000
第三列一直在增加的话需要，表示 soft IRQ 获取的 CPU 时间太短，来不及处理足够多的网络包，那么需要增大 netdev_budget 值。

2.解决IRQ丢包
budget 默认 300，可以调整
sysctl -w net.core.netdev_budget=600

4.单核负载高导致丢包

单核CPU软中断占有高, 导致应用没有机会收发或者收包比较慢，即使调整netdev_max_backlog队列大小仍然会一段时间后丢包，处理速度跟不上网卡接收的速度

1.查看
mpstat -P ALL 1
Linux 3.10.0-957.el7.x86_64 (localhost.localdomain)     05/07/2024     _x86_64_    (2 CPU)

03:09:59 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
03:10:00 PM  all    0.52    0.00    2.58    0.00    0.00    0.52    0.00    0.00    0.00   96.39
03:10:00 PM    0    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
03:10:00 PM    1    0.00    0.00    5.21    0.00    0.00    1.04    0.00    0.00    0.00   93.75
单核软中断占有100%，导致应用没有机会收发或者收包比较慢而丢包

2.解决
2.1调整网卡RSS队列配置
查看：ethtool -x eth0；
调整：ethtool -X eth0 xxxx；

三、内核协议栈丢包

1.neighbor系统arp丢包

arp_ignore参数的作用是控制系统在收到外部的arp请求时，是否要返回arp响应。

1.查看
sysctl -a|grep arp_ignore

2.解决
根据实际场景设置对应值

2.arp_filter配置丢包

在多接口系统里面，这些接口都可以回应arp请求，导致对端有可能学到不同的mac地址，后续报文发送可能由于mac地址和接收报文接口mac地址不一样而导致丢包，arp_filter主要是用来适配这种场景

1.查看
sysctl -a | grep arp_filter

2.解决方案
根据实际场景设置对应的值，一般默认是关掉此过滤规则，特殊情况可以打开；
0：默认值，表示回应arp请求的时候不检查接口情况；
1：表示回应arp请求时会检查接口是否和接收请求接口一致，不一致就不回应；

3.arp表满导致丢包

1.查看
查看arp状态：cat /proc/net/stat/arp_cache ，table_fulls统计：

查看dmesg消息（内核打印）
dmesg|grep neighbour
neighbour: arp_cache: neighbor table overflow!

查看当前arp表大小
ip n|wc -l

查看系统配额
sysctl -a |grep net.ipv4.neigh.default.gc_thresh
gc_thresh1：存在于ARP高速缓存中的最少层数，如果少于这个数，垃圾收集器将不会运行。缺省值是128。


gc_thresh2 ：保存在 ARP 高速缓存中的最多的记录软限制。垃圾收集器在开始收集前，允许记录数超过这个数字 5 秒。缺省值是 512。
gc_thresh3 ：保存在 ARP 高速缓存中的最多记录的硬限制，一旦高速缓存中的数目高于此，垃圾收集器将马上运行。缺省值是1024

2.解决方案
根据实际arp最大值情况（比如访问其他子机最大个数），调整arp表大小
$ sudo sysctl -w net.ipv4.neigh.default.gc_thresh1=1024
$ sudo sysctl -w net.ipv4.neigh.default.gc_thresh2=2048
$ sudo sysctl -w net.ipv4.neigh.default.gc_thresh3=4096
$ sudo sysctl  -p

4.arp请求缓存队列溢出丢包

1.查看
cat /proc/net/stat/arp_cache ，unresolved_discards是否有新增计数

2.解决方案
根据客户需求调整缓存队列大小unres_qlen_bytes：

四、TCP/UDP协议丢包

1.分片重组丢包

1.查看
netstat -s|grep timeout
601 fragments dropped after timeout

2.解决方法
2.1调整超时时间
net.ipv4.ipfrag_time = 30
sysctl -w net.ipv4.ipfrag_time=60


2.2 调整分片内存大小
netstat -s|grep reassembles
8094 packet reassembles failed
解决方案：
调整参数
net.ipv4.ipfrag_high_thresh 
net.ipv4.ipfrag_low_thresh

2.3关闭分片安全检查
netstat -s|grep reassembles
8094 packet reassembles failed
解决方案： 把ipfrag_max_dist设置为0

2.4分片hash bucket冲突链太长超过系统默认值128
dmesg|grep “Dropping fragment”
inet_frag_find: Fragment hash bucket 128 list length grew over limit. Dropping fragment.
解决方案：热补丁调整hash大小

2.5 系统内存不足，创建新分片队列失败
netstat -s|grep reassembles
8094 packet reassembles failed

dropwatch -l kas #dropwatch查看丢包位置
解决方案
增大系统网络内存
net.core.rmem_default 
net.core.rmem_max 
net.core.wmem_default

系统回收内存
echo 3 > /proc/sys/vm/drop_caches

2.TIME_WAIT过多丢包

大量TIMEWAIT出现，并且需要解决的场景，在高并发短连接的TCP服务器上，当服务器处理完请求后立刻按照主动正常关闭连接。。。这个场景下，会出现大量socket处于TIMEWAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上

1.查看
dmsg
TCP: time wait bucket table overflow；
系统配置
sysctl -a|grep tcp_max_tw_buckets

解决方案：
1. tw_reuse，tw_recycle 必须在客户端和服务端timestamps 开启时才管用（默认打开）

2. tw_reuse 只对客户端起作用，开启后客户端在1s内回收；

3. tw_recycle对客户端和服务器同时起作用，开启后在3.5*RTO 内回收，RTO 200ms~ 120s具体时间视网络状况。内网状况比tw_reuse稍快，公网尤其移动网络大多要比tw_reuse 慢，优点就是能够回收服务端的TIME_WAIT数量；

在服务端，如果网络路径会经过NAT节点，不要启用net.ipv4.tcp_tw_recycle，会导致时间戳混乱，引起其他丢包问题；

4. 调整tcp_max_tw_buckets大小，如果内存足够：

3.内存不足导致丢包

1.查看
dmesg|grep “out of memory”
系统配置
cat /proc/sys/net/ipv4/tcp_mem
cat /proc/sys/net/ipv4/tcp_rmem
cat /proc/sys/net/ipv4/tcp_wmem

2.解决方案
根据TCP业务并发流量，调整系统参数，一般试着增大2倍或者其他倍数来看是否缓解；
sysclt -w net.ipv4.tcp_mem=
sysclt -w net.ipv4.tcp_wmem=
sysclt -w net.ipv4.tcp_rmem=
sysctl -p

4.TCP超时丢包

1.查看当前端到端网络质量
hping -S 9.199.10.104 -A

2.解决方案
关闭Nagle算法，减少小包延迟；
关闭延迟ack:
sysctl -w net.ipv4.tcp_no_delay_ack=1

5.TCP乱序丢包

#修改TCP无序传送的容错率
sysctl -a|grep tcp_reordering

抄自于：https://mp.weixin.qq.com/

标签：arp,丢包,00000000,0.00,网络,网卡,排查,net
From： https://www.cnblogs.com/panwenbin-logs/p/18177479