抽丝剥茧：生产环境中负载均衡产品 DPDK 问题的解决（上）

ULB4 是 UCloud 自主研发的基于 DPDK 的高可用四层负载均衡产品，转发能力接近线速；DPDK 则是一个高性能的开源数据面开发套件。ULB4 作为用户应用的全局入口，在大流量多元化场景下保证用户业务的持续稳定至关重要，这也是 UCloud 网络产品团队的技术使命。尤其现网单个 ULB 集群承载带宽已达 10G，包量 83 万 PPS，运行环境复杂，即使面临突发因素(比如触发未知 BUG)，我们也要设法保证产品正常工作，避免产生严重影响。

近期，我们在 ULB4 的线上环境中，发现了一个 DPDK 的发包异常现象，由于整个 ULB 产品为集群架构，该异常并未导致用户服务不可用。但为了任何时刻都能保证用户服务的足够稳定，团队通过 GDB、报文导出工具、生产环境流量镜像等手段，从现网 GB 级流量中捕获异常报文，再结合 DPDK 源码分析，定位到原因出自 DPDK 本身的 BUG 并修复解决。期间未对用户业务造成影响，进一步保证了 UCloud 数万 ULB 实例的稳定运行。

本文将从问题现象着手，抽丝剥茧，详述问题定位、分析与解决全过程，希望能为 ULB 用户和 DPDK 开发者提供参考与启迪。

问题背景

在 12 月初一向稳定的 ULB4 集群中突然出现了容灾，某台 ULB4 服务器工作异常被自动移出了集群。当时的现象是：

转发面服务监控到网卡接收方向流量正常，但是发送方向流量为 0，重启转发面服务后又可以正常收发，同时集群其他机器也会不定期出现异常情况。对用户业务而言，会出现少量连接轻微抖动，随后迅速恢复。

下面是整个问题的处理过程，我们在此过程中做出种种尝试，最终结合 DPDK 源码完成分析和解决，后续也准备将自研的报文导出工具开源共享。

问题定位与分析

ULB4 集群一直很稳定地工作，突然陆续在集群的不同机器上出现同样的问题，并且机器恢复加入集群后，过了一段时间又再次出现同样的问题。根据我们的运营经验，初步猜测是某种异常报文触发了程序 BUG。但是，面对 GB 级流量如何捕获到异常报文？又如何在不影响业务情况下找出问题呢？

1、GDB 调试报文，发现疑点

想要知道整个程序为什么不发包，最好的办法就是能够进入到程序中去看看具体的执行过程。对于 DPDK 用户态程序来说，GDB 显然是一个好用的工具。我们在发包程序逻辑中设置断点，并通过 disassemble 命令查看该函数的执行逻辑，反汇编之后足足有七百多行。（该函数中调用的很多函数都使用了 inline 修饰，导致该函数在汇编之后指令特别多）

结合对应 DPDK 版本的源码，单条指令一步步执行。在多次尝试之后，发现每次都会在下图所示的地方直接返回。

大致流程是 i40e_xmit_pkts()在发送的时候，发现发送队列满了就会去调用 i40e_xmit_cleanup()清理队列。DPDK 中网卡在发送完数据包后会去回写特定字段，表明该报文已经发送，而驱动程序去查看该字段就可以知道这个报文是否已经被发过。此处的问题就是驱动程序认为该队列中的报文始终未被网卡发送出去，后续来的报文将无法加入到队列而被直接丢弃。

至此，直接原因已经找到，就是网卡因为某种原因不发包或者没能正确回写特定字段，导致驱动程序认为发送队列始终处于队列满的状态，而无法将后续的报文加入发送队列。

那么为什么出现队列满？异常包是否相关呢？带着这个疑问，我们做了第二个尝试。

2、一键还原网卡报文

队列满，而且后面的报文一直加不进去，说明此时队列里面的报文一直卡在那。既然我们猜测可能是存在异常报文，那么有没有可能异常报文还在队列里面呢？如果可以把当前队列里面的报文全部导出来，那就可以进一步验证我们的猜测了。

基于对 DPDK 的深入研究，我们根据以下步骤导出报文。

• 我们看 i40e_xmit_pkts()函数，会发现第一个参数就是发送队列，所以我们可以获取到队列的信息。

• 如下图所示，在刚进入断点的时候，查看寄存器信息，以此来获得该函数对应的参数。

• 当我们打印该队列的消息时，却发现没有符号信息，此时我们可以如下图所示去加载编译时候生成的 i40e_rxtx.o 来获取对应符号信息。

• 在得到队列信息后，我们使用 GDB 的 dump 命令将整个队列中所有的报文全部按队列中的顺序导出，对每个报文按序号命名。

• 此时导出的报文还是原始的报文，我们无法使用 wireshark 方便地查看报文信息。为此如下图所示，我们使用 libpcap 库写了个简单的小工具转换成 wireshark 可以解析的 pcap 文件。

果然，如下图所示，在导出的所有报文中包含了一个长度为 26 字节，但内容为全 0 的报文。这个报文看上去十分异常，似乎初步验证了我们的猜测：

为了提高在排查问题时导出报文的速度，我们写了一个报文一键导出工具，可以在异常时一键导出所有的报文并转成 pcap 格式。

在多次导出报文后，我们发现一个规律：每次都会有一个长度为 26 字节但是全 0 的报文，而且在其前面都会有一个同样长度的报文，且每次源 IP 地址网段都来自于同一个地区。