1.服务器环境以及配置
|-----------|----------------------------|------------------------------------------------------|
| 系统环境 | 物理机/虚拟机/云/容器 | 物理机 |
| 网络环境 | 外网/私有网络/无网络 | 私有网络 |
| 硬件环境 | 机型 | 华鲲振宇 TG225B1 |
| 硬件环境 | 处理器 | kunpeng 920 |
| 硬件环境 | 内存 | 1024GB |
| 硬件环境 | 主板型号 | TG225B1 HZKY |
| 硬件环境 | 整机类型/架构 | aarch64 |
| 硬件环境 | 固件版本 | 6.57 |
| 软件环境 | 具体操作系统版本 | Kylin-server-release-v10SP2-aarch64-Bui1d09/20210524 |
| 软件环境 | 内核版本 | 4.19.90-24.4.v2101.ky10.aarch64 |
| 第三方软件 | 有/无 如有已安装的第三方软件，列出具体名称、版本号 | oceanbase 3.2.3版本 |
2.问题现象描述
- 问题1
发生时间：
2023/8/23
问题描述：
18台用于数据库的机器(华为鲲鹏服务器+系统kylin-v10-sp2-0524)存在以下现象：
网卡做bond（mode4），一段时间后ifconfig查看bond信息，dropped在持续增加计数，网络通讯正常，ping不丢包，搭载的业务运行正常。客户侧网络人员已检查交换机配置，硬件厂商已检查硬件驱动正常。
问题截图
网卡参数截图
3.问题分析
3.1. 前期分析排查
根据问题现象，前期我们做了以下测试步骤：
1、在问题机器上使用ping测试，测试结果为ping包不丢包。且客户表示虽然drop在不断增加，但业务并未受到影响
2、调大网卡ringbuffer为tx 4096 rx4096，但没有效果。
3、使用tcpdump尝试收集异常数据，但开启tcpdump后网卡drop数目不再频繁增长了。
根据以上测试信息，我们发现虽然网卡不断有drop查看，但并未影响服务器正常运行;且当使用tcpdump收集数据时，网卡会自动打开混杂模式，该模式下网卡drop不断增长的现象不再出现。
我们再继续查看/proc/net/dev文件，发现出现大量drop的网卡仅表现为drop数目较高，却无fifo、errs、frame，这也说明当前drop的数据包应该不是触发了驱动检测异常、FIFO缓冲区错误、分组帧错误。由此可以推断：网卡已经把数据完整交给了操作系统，其本身并没有丢包，真正丢包的是操作系统。
结合以上现象，我们初步推测当前服务器网卡drop不断增加应该不是触发了某种异常错误，而是由于网络中存在不支持的网络协议包、未知的多播包、异常的VLAN标记包等原因。
3.2.使用dropwatch查看drop具体位置
为了确定网卡drop出现的具体位置，我们使用dropwatch监控 kfree_skb 的调用。
对比drop数量上升时的对应函数输出，我们初步定位到发生drop的位于__netif_receive_skb_core 函数。
查看Linux内核源码中__netif_receive_skb_core 函数的定义来确认一下丢包原因。
从源码中我们可以看到，当pfmemalloc 为真，且 skb_pfmemalloc_protocol 中判断不支持包协议的时候，就会跳转到label
drop处理，从而触发kfree_skb调用，产生丢包。
继续查看skb_pfmemalloc_protocol 支持的网络网络协议包，我们可以看到其只支持ETH_P_ARP、ETH_P_IP、ETH_P_IPV6、ETH_P_8021Q、ETH_P_8021AD这几种网络协议。
3.3 使用systemtap捕捉被丢弃的数据包协议号
为了确认drop包的对应网络协议号，我们使用systemtap进行相应捕获，对应stap脚本内容如下。
使用stap运行该脚本，对比网卡drop出现的时机，我们发现drop的包其网络协议均为0X88CC。
在网络上查找该协议号相关信息，发现0X88CC为LLDP报文的网络协议号，多为路由器、交换机等设备发出。
继续使用tcpdump捕获非skb_pfmemalloc_protocol 函数支持的网络协议包，发现网络中确实存在0X88CC这一LLDP报文协议的数据包，且从名字来看大概率为交换机发出的包。
4.问题分析结果
结合以上分析排查，我们可以确定当前服务器网卡drop不断增加不是触发了某种异常错误，而是由于网络中存在0X88CC这一不支持的网络协议包。
当网卡接收到该协议的数据包时并未产生fifo、errs、frame等错误，而是交由操作系统内核判断，在skb_pfmemalloc_protocol 函数处理中被丢弃。
继续查看0X88CC这一协议号对应的数据包类型，发现其为LLDP报文的网络协议号，多为路由器、交换机等设备发出。tcpdump的抓包也确认了网络环境中确实存在LLDP报文数据。
当前和客户方面交流，该LLDP包大概率为交换机发出，非业务相关，因此虽然有网卡drop产生但并不会导致业务异常。后续可以根据tcpdump抓包的相应信息，让对应网络部门进行排查，确定为路由器、交换机等发出的LLDP包且非业务相关即可忽略网卡drop现象。