网络丢包排查方法

网络丢包问题可能由多种原因引起，包括物理线路故障、设备故障、病毒攻击、路由信息错误、网络拥塞、网络延迟、恶意攻击、传输协议特性（如TCP和UDP的不同丢包率）、无线网络问题、网络设备过载、网络配置不当、安全漏洞等。
例如，设备故障可能是由于网卡驱动程序的问题或网线质量不佳；网络拥塞可能导致数据包排队、延迟或丢失；恶意攻击如拒绝服务攻击(DDoS)可能占用网络资源，导致正常数据包被丢弃。解决这些问题的方法包括检查网络线缆、重启路由器、检查网络设置、更新驱动程序、关闭防火墙和杀毒软件、重置网络设置等。

此外，还可以通过分段捕获的方法在网络中关键设备的两端进行抓包，以确定是否丢包，从而准确定位丢包设备。在核心交换机上配置镜像，使用网络分析系统抓包，分析关键链路的流量占用情况和网络利用率，以缓解网络拥塞。

1. 简述

1.1 什么是丢包

丢包是指在网络通信过程中，数据包（Packet）在传输过程中出现丢失的情况。每个数据包都有一个特定的源地址和目标地址，并携带着传输的数据内容。当一个数据包从源地址发送到目标地址的途中，如果因为各种原因导致该数据包未能正常到达目标地址，就被称为丢包。

造成数据包丢失的原因可能有多种，比如网络拥堵、传输错误、路由问题、设备故障等。丢包会影响通信质量和性能，尤其对于实时应用（如视频通话、游戏等）来说，丢失重要的数据包可能会导致卡顿、延迟或者画面断续等问题。
为了应对丢包问题，网络通信中通常采用一些机制来进行错误检测和恢复，例如使用校验和进行数据完整性验证、重传机制来补发丢失的数据包等。这些机制可以有效降低丢包率并提高网络通信可靠性。

1.2 数据包接收、发送原理

发送数据包：

应用程序将需要发送的数据组装成一个或多个数据包。
数据包被传递给传输层协议，如TCP或UDP。
传输层协议将数据包添加上目标地址、源地址以及其他必要的控制信息。
传输层协议将数据包交给网络层协议，如IP协议。
网络层协议在数据包头部添加路由信息，形成最终的网络包（Packet）。
最终的网络包通过物理介质（如以太网、Wi-Fi等）发送出去。

接收数据包：

物理介质接收到发送的数据包，并将其转换为电信号进行处理。
接收端的物理设备通过解码等过程还原出二进制数据流。
接收端的网络层协议检查网络包头部中目标地址是否与自身匹配，如果匹配，则进行下一步处理；否则丢弃该数据包。
网络层协议将有效载荷（Payload）交给传输层协议，如TCP或UDP。
传输层协议对接收到的数据进行处理，并根据需要重组分段的片段（TCP），或者直接提取有效载荷（UDP）。
最终，接收到的数据包通过传输层协议提供给应用程序处理和解析。

1.3 核心思路

了解了收发包的原理，可以了解到丢包原因主要会涉及网卡设备、网卡驱动、内核协议栈三大类。以下我们将遵循“从下到上分层分析（各层可能性出现的丢包场景），然后查看关键信息，最终得出分析结果”的原则展开介绍。

2. 硬件网卡丢包

2.1 Ring Buffer溢出

Ring Buffer（环形缓冲区）溢出是指当往一个已经满了的环形缓冲区中写入数据时，会覆盖之前存储在缓冲区中的数据。这种情况通常发生在写入速度快于读取速度的情况下。
环形缓冲区是一种固定大小、循环使用的缓冲区结构。它由一个固定长度的数组和两个指针组成：一个用于指示写入位置，另一个用于指示读取位置。当写入位置超过数组长度时，指针会回到数组起始位置继续写入数据，形成循环。
当写入速度快于读取速度时，如果没有采取适当的措施来处理溢出情况，那么新写入的数据就会覆盖未读取的数据，导致数据丢失或不完整。

为了解决Ring Buffer溢出问题，可以考虑以下几种方法：

采用合适的策略进行流量控制：通过监控读取速度和写入速度，并根据需要进行调整。
使用同步机制或锁来保护对Ring Buffer的访问，在多线程或多进程环境下确保安全性。
在设计阶段合理评估所需缓冲区大小，以应对可能的高负载情况。
实现溢出检测和处理机制，例如当缓冲区即将溢出时，采取相应措施如丢弃数据、阻塞写入等。

如图所示，物理介质上的数据帧到达后首先由NIC（网络适配器）读取，写入设备内部缓冲区Ring Buffer中，再由中断处理程序触发Softirq从中消费，Ring Buffer的大小因网卡设备而异。当网络数据包到达（生产）的速率快于内核处理（消费）的速率时，Ring Buffer很快会被填满，新来的数据包将被丢弃；
查看：
通过ethtool或/proc/net/dev可以查看因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

查看eth0网卡Ring Buffer最大值和当前设置

$ ethtool -g eth0

解决方案：修改网卡eth0接收与发送硬件缓存区大小

$ ethtool -G eth0 rx 4096 tx 4096

2.2 网卡端口协商丢包

网卡端口协商丢包通常指的是在网络设备（如交换机、路由器）上，当两个相连的设备进行链接时，它们需要进行一系列的协商以确定连接的速率和工作模式。这个过程称为端口协商（Port Negotiation），其中最常见的协商方式是通过自适应协商（Auto-negotiation）。

在端口协商过程中，设备之间会交换一些控制信息来决定最佳的速率和工作模式。然而，有时候由于不同厂家或不同版本的设备实现标准不一致，或者存在硬件或软件问题，可能会导致端口协商失败或出现异常情况。
当端口协商失败或存在问题时，可能会导致丢包现象。这是因为连接双方无法达成一致的速率和工作模式设置，在传输数据时会发生错误或丢失部分数据包。这种情况下，可能需要对网络设备进行调整、更新固件/驱动程序、检查物理连接等方法来解决问题。

以下是一些可能解决网卡端口协商丢包问题的方法：

确保使用了兼容性良好、最新版本的网络设备。
检查物理连接是否稳定，并尝试更换合适的网线。
更新网络设备的固件或驱动程序，以确保兼容性和稳定性。
手动配置端口速率和工作模式，而不依赖自适应协商。这需要确保两个连接设备的设置一致。
如果问题仍然存在，可能需要联系厂家技术支持进行进一步排查和解决。

查看ethtool -S eth0并查看/proc/net/dev了解更多信息：

➜  ~ 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

主要查看网卡和上游网络设备协商速率和模式是否符合预期；
解决方案：

1. 重新自协商： ethtool -r eth1/eth0;
2. 如果上游不支持自协商，可以强制设置端口速率：ethtool -s eth1 speed 1000 duplex full autoneg off

2.3 网卡流控丢包

网卡流控丢包问题通常是由于发送和接收速率不匹配导致的。你可以通过以下步骤来检查和解决网卡流控丢包问题：

1. 检查流控设置：使用ethtool命令检查网卡的流控设置，例如：ethtool -a 其中，是指你要检查的网卡接口名称。
2. 确保发送方和接收方速率一致：如果发送方的速率大于接收方，则可能会出现丢包情况。你可以通过调整两端设备的速率来解决该问题。在交换机或路由器上也需要确保相应端口的速率设置正确。
3. 调整缓冲区大小：尝试增加网卡缓冲区大小以提高数据传输性能，可以使用ethtool命令进行配置。
4. 检查链路质量：使用网络分析工具（如Wireshark）监视网络链路，以确定是否存在其他潜在问题（如网络干扰、噪音等）。
5. 更新驱动程序和固件：确保你的网卡驱动程序和固件是最新版本，因为更新版本通常会修复一些已知问题。
6. 联系供应商支持：如果以上方法都无法解决问题，建议联系网卡供应商的技术支持团队，寻求更专业的帮助和建议。

解决方案：

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

2.4 报文mac地址丢包

报文的MAC地址丢包问题通常与网络链路中的物理设备、网络拓扑或配置问题有关。以下是一些可能导致报文MAC地址丢包的常见原因和解决方法：

1. ARP缓存问题：检查源设备和目标设备之间的ARP缓存是否正确，确保MAC地址映射到正确的IP地址。
2. 网络设备故障：检查网络交换机、路由器或其他中间设备是否正常工作。可能存在硬件故障、软件配置错误或过载等问题。可以尝试重启相关设备来解决。
3. VLAN配置不匹配：如果使用了虚拟局域网（VLAN），请确保发送方和接收方在相同的VLAN中，并且VLAN配置正确。
4. MTU大小限制：某些情况下，如果数据包的大小超过了链路上允许的最大传输单元（MTU）大小，则可能发生丢包现象。确保所有相关设备的MTU设置一致，并能够处理所需的数据包大小。
5. MAC地址欺骗攻击：在局域网中可能存在恶意主机进行MAC地址欺骗攻击，导致报文被重定向到错误的目标设备。在这种情况下，可以通过实施安全措施来防止此类攻击。
6. 链路速率不匹配：如果发送方和接收方的链路速率不一致，可能会导致报文在传输过程中丢失。确保两端设备的链路速率设置正确，并能够适应所需的数据传输。
7. 网络拥塞：高网络流量可能导致报文丢失。可以尝试通过增加带宽、调整流控参数或实施其他网络优化方法来缓解拥塞问题。

一般计算机网卡都工作在非混杂模式下，此时网卡只接受来自网络端口的目的地址指向自己的数据，如果报文的目的mac地址不是对端的接口的mac地址，一般都会丢包，一般这种情况很有可能是源端设置静态arp表项或者动态学习的arp表项没有及时更新，但目的端mac地址已发生变化（换了网卡），没有更新通知到源端（比如更新报文被丢失，中间交换机异常等情况）；

查看：
目的端抓包，tcpdump可以开启混杂模式，可以抓到对应的报文，然后查看mac地址；
源端查看arp表或者抓包（上一跳设备），看发送的mac地址是否和下一跳目的端的mac地址一致；

解决方案：
刷新arp表然后发包触发arp重新学习（可能影响其他报文，增加延时，需要小心操作）；
可以在源端手动设置正确的静态的arp表项；

2.5 其他网卡异常丢包

1. 原因一：物理线路故障
   网管员发现广域网线路时通时断， 发生这种情况时， 有可能是线路出现故障， 也可能是用户方面的原因。为了分清是否是线路故障，可以做如下测试。
   如果广域网线路是通过路由器实现的，可以登录到路由器，通过扩展 ping 向对端路由器广域网接口发送大量的数据包进行测试。如果线路是通过三层交换机实现，可在线路两端分别接一台计算机，并将 IP 地址分别设为本端三层路由交换机的广域网接口地址，使用 “ping 对端计算机地址 - t ”命令进行测试。
   如果上述测试没有发生丢包现象， 则说明线路运营商提供的线路是好的， 引起故障的原因在于用户自身，需要进一步查找。如果上述测试发生丢包现象， 则说明故障是由线路供应商提供的线路引起的， 需要与线路供应商联系尽快解决问题。
   由物理线路引起的丢包现象还有很多，如光纤连接问题，跳线没有对准设备接口，双绞线及 RJ-45 接头有问题等。另外，通信线路受到随机噪声或者突发噪声造成的数据报错误，射频信号的干扰和信号的衰减等都可能造成数据包的丢失。我们可以借助网络测试仪来检查线路的质量。
2. 原因二：设备故障
   设备故障主要是指设备硬件方面的故障，不包含软件配置不当造成的丢包。如网卡是坏的，交换机的某个端口出现了物理故障，光纤收发器的电端口与网络设备接口，或两端设备接口的双工模式不匹配。
   曾看过这样的例子，一交换机端口的光纤模块故障造成的丢包现象， 该交换机在通信一段时间后死机，即不能通信，重启后恢复正常。在经过一段时间观察后发现，某光纤模块存在问题，取一块新的模块替换，一切正常。
   究其原因，交换机会对所有接收到的数据包进行 CRC 错误检测和长度校验，将检查出有错误的包丢弃，正确的包转发出去。但这个过程中有些有错误的包在 CRC 错误检测和长度校验中都均未检测出错误，这样的包在转发过程中不会被发送出去，也不会被丢弃，它们将会堆积在动态缓存中，永远无法发送出去，等到缓存中堆积满了，就会造成交换机死机的现象。最终结果是，数据包无法到达目的主机。
3. 原因三：网络拥塞
   网络拥塞造成丢包率上升的原因很多，主要是路由器资源被大量占用造成的，如果发现网速慢， 并且丢包率呈现上升的情况， 这时应该 show process cpu 和 show process mem ，一般情况下发现 IP input process 占用过多的资源。接下来可以检查 fast switching 在大流量外出端口是否被禁用，如果是，则需要重新使用。
   再看一下 Fast switching on the same interface是否被禁用，如一个接口配有多个网段并且这些网段间流量很大时，路由器工作在 process-switches 方式，这种情况下要在接口上执行命令“enable ip route-cache same- interface 。”
   接下来，用 show interfaces 和 show interfaces switching 命令识别大量包进出的端口。一旦确认进入端口后，打开 IP accounting on the outgoing interface 看其特征，如果是攻击，源地址会不断变化但是目的地址不变，可以用命令 “access list ”暂时解决此类问题(最好在接近攻击源的设备上配置)，最终解决办法是停止攻击源。
   应用中遇到的造成网络拥塞的情况还有很多， 如大量的 UDP 流量， 可以用解决 spoof attack 的步骤解决此问题。大量的组播流、广播包穿越路由器，路由器配置了 IP NAT 并