linux丢包排查方法汇总
1、排查网卡丢包
命令1： ifconfig xxx
ifconfig eth0
eth0 Link encap:Ethernet HWaddr AC::3D:A9::0Dinet addr:211.211.211.211 Bcast:211.211.211.255 Mask:255.255.255.0UP BROADCAST RUNNING MULTICAST MTU: Metric:RX packets: errors: dropped: overruns: frame:TX packets: errors: dropped: overruns: carrier:collisions: txqueuelen:RX bytes: ( (1.3 TiB)Memory:94b00000-94b20000
解析：
RX errors: 表示总的收包的错误数量，这包括 too-long-frames 错误，Ring Buffer 溢出错误，crc 校验错误，帧同步错误，fifo overruns 以及 missed pkg 等等。
RX dropped: 表示数据包已经进入了 Ring Buffer，但是由于内存不够等系统原因，导致在拷贝到内存的过程中被丢弃。
RX overruns: 表示了 fifo 的 overruns，这是由于 Ring Buffer(aka Driver Queue) 传输的 IO 大于 kernel 能够处理的 IO 导致的，而 Ring Buffer 则是指在发起 IRQ 请求之前的那块 buffer。很明显，overruns 的增大意味着数据包没到 Ring Buffer 就被网卡物理层给丢弃了，而 CPU 无法即使的处理中断是造成 Ring Buffer 满的原因之一，上面那台有问题的机器就是因为 interruprs 分布的不均匀(都压在 core0)，没有做 affinity 而造成的丢包。
RX frame: 表示 misaligned 的 frames
对于TX：出现上述 counter 增大的原因主要包括 aborted transmission, errors due to carrirer, fifo error, heartbeat erros 以及 windown error，而 collisions 则表示由于 CSMA/CD 造成的传输中断。
dropped与overruns的区别
dropped：表示这个数据包已经进入到网卡的接收缓存fifo队列，并且开始被系统中断处理准备进行数据包拷贝（从网卡缓存fifo队列拷贝到系统内存），但由于此时的系统原因（比如内存不够等）导致这个数据包被丢掉，即这个数据包被Linux系统丢掉。
overruns：表示这个数据包还没有被进入到网卡的接收缓存fifo队列就被丢掉，因此此时网卡的fifo是满的。为什么fifo会是满的？因为系统繁忙，来不及响应网卡中断，导致网卡里的数据包没有及时的拷贝到系统内存，fifo是满的就导致后面的数据包进不来，即这个数据包被网卡硬件丢掉。所以，个人觉得遇到overruns非0，需要检测cpu负载与cpu中断情况
命令2: ethtool -S xxx
ethtool -S eth0 | grep rx_ | grep errors
rx_crc_errors: 0rx_missed_errors: 0rx_long_length_errors: 0rx_short_length_errors: 0rx_align_errors: 0rx_errors: 0rx_length_errors: 0rx_over_errors: 0rx_frame_errors: 0rx_fifo_errors: 0
2、排查网络丢包
命令： netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
br-0。 1500 120663354 0 0 0 89134427 0 0 0 BMRU
docker0 1500 3307728075 0 0 0 3520602520 0 0 0 BMRU
ens192 1500 3644841642 0 6930 0 3335406503 0 0 0 BMRU
解析：
RX-OK：接收时，正确的数据包数。
RX-ERR：接收时，产生错误的数据包数。
RX-DRP：接收时，丢弃的数据包数。
RX-OVR：接收时，由于过速（在数据传输中，由于接收设备不能接收按照发送速率传送来的数据而使数据丢失）而丢失的数据包数。
TX-OK：发送时，正确的数据包数。
TX-ERR：发送时，产生错误的数据包数。
TX-DRP：发送时，丢弃的数据包数。
TX-OVR：发送时，由于过速而丢失的数据包数。
Flg标志：
* B 已经设置了一个广播地址。
* L 该接口是一个回送设备。
* M 接收所有数据包（混乱模式）。
* N 避免跟踪。
* O 在该接口上，禁用ARP。
* P 这是一个点到点链接。
* R 接口正在运行。
* U 接口处于“活动”状态。
}
3、排查是否防火墙没关导致包被防火墙丢弃
查看防火墙： systemctl status firewalld.service
关闭防火墙： systemctl stop firewalld.service
禁止防火墙开机自动启动： systemctl disable firewalld.service
4、排查连接跟踪表溢出导致丢包
查看是否有溢出错误： dmesg |grep conntrack
5、排查Ring Buffer溢出导致丢包
命令1: ethtool -S eth0|grep rx_fifo
rx_fifo_errors: 0
命令2: cat /proc/net/dev
Inter-| Receive | Transmitface |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressedeth0: 17253386680731 42839525880 0 0 0 0 0 244182022 14879545018057 41657801805 0 0 0 0 0 0
6、反向路由校验rp_filter过滤导致丢包
查看当前rp_filter策略配置： cat /proc/sys/net/ipv4/conf/eth0/rp_filter
分析：具体要根据出入包的处理网络设备以及rp_filter当前的值来判断是否发生
7、半连接队列溢出导致丢包
半连接队列：
半连接队列指的是TCP传输中服务器收到SYN包但还未完成三次握手的连接队列，队列大小由内核参数tcp_max_syn_backlog定义。当服务器保持的半连接数量达到tcp_max_syn_backlog后，内核将会丢弃新来的SYN包。
通过dmesg可以确认是否有该情况发生：dmesg | grep “TCP: drop open request from”
半连接队列的连接数量可以通过netstat统计SYN_RECV状态的连接得知：
$ netstat -ant|grep SYN_RECV|wc -l
0大多数情况下这个值应该是0或很小，因为半连接状态从第一次握手完成时进入，
第三次握手完成后退出，正常的网络环境中这个过程发生很快，如果这个值较大，
服务器极有可能受到了SYN Flood攻击。
8、排查iptables规则丢包
查看当前有哪些drop规则： iptables-save | grep -i drop
例如：出现以下drop规则-A INPUT -p tcp -m tcp --dport 6666 -j DROP
确定是否命令改drop规则： iptables -L INPUT -nv
查看pkts这里是否计数增加，增加就是证明出现丢包：Chain INPUT (policy ACCEPT 0 packets, 0 bytes)pkts bytes target prot opt in out source destination 48 2991 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6666
9、查看内核丢包
方法1: 使用perf
perf抓取命令： perf record -g -a -e skb:kfree_skb
perf查看命令： perf script
方法2: 使用dropwatch
安装命令： yum install dropwatch
使用命令： dropwatch -l kas，启动后按start开始抓取
示例：
1、perf判断是否出现内核丢包： perf record -g -a -e skb:kfree_skb
查看perf record结果：perf script
swapper 0 [001] 1299147.131284: skb:kfree_skb: skbaddr=0xff40b007a2ad7400 protocol=2048 location=0xffffffff96aa2cc8ffffffff969c4803 kfree_skb+0x73 ([kernel.kallsyms])ffffffff969c4803 kfree_skb+0x73 ([kernel.kallsyms])ffffffff96aa2cc8 tcp_v4_rcv+0x48 ([kernel.kallsyms])ffffffff96a76c3c ip_protocol_deliver_rcu+0x2c ([kernel.kallsyms])ffffffff96a76e2d ip_local_deliver_finish+0x4d ([kernel.kallsyms])ffffffff96a76f20 ip_local_deliver+0xe0 ([kernel.kallsyms])ffffffff96a771ab ip_rcv+0x27b ([kernel.kallsyms])ffffffff969e0610 __netif_receive_skb_core+0xba0 ([kernel.kallsyms])ffffffff969e07bd netif_receive_skb_internal+0x3d ([kernel.kallsyms])ffffffff969e1268 napi_gro_receive+0x108 ([kernel.kallsyms])ffffffffc05b8431 mlx5e_handle_rx_cqe+0xb1 ([kernel.kallsyms])ffffffffc05b9f34 mlx5e_poll_rx_cq+0x804 ([kernel.kallsyms])ffffffffc05ba6dc mlx5e_napi_poll+0x10c ([kernel.kallsyms])ffffffff969e1b5d __napi_poll+0x2d ([kernel.kallsyms])ffffffff969e2033 net_rx_action+0x253 ([kernel.kallsyms])ffffffff96e000d7 __softirqentry_text_start+0xd7 ([kernel.kallsyms])ffffffff962f3f3b irq_exit_rcu+0xcb ([kernel.kallsyms])ffffffff962f3f4a irq_exit+0xa ([kernel.kallsyms])ffffffff96c01e7f do_IRQ+0x7f ([kernel.kallsyms])
此例子中能看到了kfree_skb，证明出现了内核丢包
2、dropwatch追踪丢包的地方： dropwatch -l kas
Initalizing kallsyms db
dropwatch> start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring
1 drops at skb_queue_purge+18 (0xffffffff92a42868)
2 drops at unix_dgram_sendmsg+4f8 (0xffffffff92b1b168)
1 drops at nf_hook_slow+f3 (0xffffffff92a99be3)
6 drops at nf_hook_slow+f3 (0xffffffff92a99be3)
1 drops at nf_hook_slow+f3 (0xffffffff92a99be3)
4 drops at nf_hook_slow+f3 (0xffffffff92a99be3)
示例中，nf_hook_slow代表在netfilter处理丢包，一般是被防火墙丢弃
10、利用bpf抓去内核hook点来排查netfilter hook等其它原因的丢包
bpf开源追踪项目：
https://github.com/OpenCloudOS/nettrace
安装追踪工具nettrace：
wget https://github.com/OpenCloudOS/nettrace/releases/download/v1.2.3/nettrace-1.2.3-1.tl3.x86_64.rpm
yum install python3
rpm -i nettrace-1.2.3-1.tl3.x86_64.rpm
抓取丢弃的包： nettrace --drop
begin trace...
[1303097.782556] TCP: 172.17.0.2:51578 -> 10.172.1.110:9100 seq:3752084848, ack:0, flags:S, tcp_v4_rcv+0x48
[1303100.778508] TCP: 172.17.0.2:51930 -> 10.172.1.110:9100 seq:2637953428, ack:0, flags:S, tcp_v4_rcv+0x48
[1303102.782574] TCP: 172.17.0.2:51930 -> 10.172.1.110:9100 seq:2637953428, ack:0, flags:S, tcp_v4_rcv+0x48
[1303105.098950] TCP: 10.172.1.110:43390 -> 10.172.1.111:6666 seq:1070580818, ack:0, flags:S, nf_hook_slow+0xa7
[1303105.778674] TCP: 172.17.0.2:52280 -> 110.172.1.111:9100 seq:3671449143, ack:0, flags:S, tcp_v4_rcv+0x48
[1303106.142463] TCP: 10.172.1.111:43390 -> 10.172.1.110:6666 seq:1070580818, ack:0, flags:S, nf_hook_slow+0xa7
示例分析：
从丢包的hook点是nf_hook_slow看出是netfilter丢弃的，排查方向应该注重于：
防火墙，selinux，用户的iptables等会下发hetfilter hook规则的地方
