三、流量镜像，确认异常包

第二步结论让整个排查前进了一大步，但是队列包是经过一系列程序处理的，并不是真正的原始业务报文。不达目的不罢休，关键时刻还是要上镜像抓包，于是当晚紧急联系网络运维同事在交换机上配置port-mirroring（端口镜像），将发往ULB4集群的流量镜像到一个空闲服务器上进行镜像抓包。当然，镜像服务器还需要做特殊配置，如下：

设置网卡混杂模式，用于收取镜像流量（ifconfig net2 promisc）。

关闭GRO功能（ethtool -K net2 gro off），用于收取最原始的报文，防止Linux的GRO功能提前将报文进行组装。

根据异常IP的地域特性，我们针对性抓取了部分源IP段的流量。

参考命令：

nohup tcpdump -i net2 -s0 -w %Y%m%d_%H-%M-%S.pcap -G 1800 “proto gre and (((ip[54:4]&0x11223000)==0x11223000) or ((ip[58:4]&0x11223000)==0x11223000))” &

经过多次尝试后，功夫不负有心人，故障出现了，经过层层剥离筛选，找到了如下报文：

这是IP分片报文，但是奇怪的是IP分片的第二片只有IP头。经过仔细比对，这两个报文合在一起就是导出队列报文中的那两个连在一起的报文。后26字节和全0报文完全吻合。

我们知道在TCP/IP协议中，如果发送时一个IP报文长度超过了MTU，将会触发IP分片，会被拆成多个小的分片报文进行发送。正常情况下，所有的分片肯定都是携带有数据的。但是这一个分片报文就很异常，报文的总长度是20，也就是说只有一个IP头，后面不再携带任何信息，这样的报文是没有任何意义的。这个报文还因为长度太短在经过交换机后被填充了26字节的0。

至此，我们最终找到了这个异常报文，也基本验证了我们的猜测。但是还需要去实际验证是否为这种异常报文导致。（从整个报文的交互来看，这一片报文本来是设置了不可分片的TCP报文，但是在经过某个公网网关后被强制设定了允许分片，并且分片出了这种异常的形式。）

四、解决方案

如果确实是这个异常报文导致的，那么只要在收包时对这种异常报文进行检查然后丢弃就可以了。于是，我们修改DPDK程序，丢弃这类报文。作为验证，先发布了一台线上服务器，经过1天运行再也没有出现异常容灾情况。既然问题根因已经找到，正是这种异常报文导致了DPDK工作异常，后续就可以按灰度全网发布了。

五、DPDK社区反馈

本着对开源社区负责任的态度，我们准备将BUG向DPDK社区同步。对比最新的commit后，找到11月6日提交的一个commit，情况如出一辙，如下：

ip_frag: check fragment length of incoming packet

DPDK 18.11最新发布的版本中，已对此进行了修复，和我们处理逻辑一致，也是丢弃该异常报文。

复盘和总结

处理完所有问题后，我们开始做整体复盘。

一、ULB无法发包的成因总结

ULB4无法发包的整个产生过程如下：

DPDK收到分片报文中的第一片，将其缓存下来等待后续分片；

第二片只有IP头的异常分片到来，DPDK按照正常的报文处理逻辑进行处理，并没有进行检查丢弃，于是两片报文的rte_mbuf结构被链在一起，组成了一个链式报文返回给ULB4；

这样的报文被ULB4接收后，因为整个报文的总长度并没有达到需要分片的长度，所以ULB4直接调用DPDK的发送接口发送出去；

DPDK没有对这种异常报文进行检查，而是直接调用相应的用户态网卡驱动直接将报文发送出去；

用户态网卡驱动在发送这样的异常报文时触发了网卡tx hang；

触发tx hang后，网卡不再工作，驱动队列中报文对应的发送描述符不再被网卡正确设置发送完成标记；

后续的报文持续到来，开始在发送队列中积压，最终将整个队列占满，再有报文到来时将被直接丢弃。

二、为什么异常报文会触发网卡tx hang

首先我们看下DPDK中跟网卡发送报文相关的代码。

从以上的图中我们可以看到，根据网卡的Datasheet对相关字段进行正确设置非常重要，如果某种原因设置错误，将可能会导致不可预知的后果（具体还是要参考网卡的Datasheet）。

如下图所示，通常网卡对应的Datasheet中会对相应字段进行相关描述，网卡驱动中一般都会有相应的数据结构与其对应。

在有了基本了解后，我们猜想如果直接在程序中手动构造这种类似的异常报文，是否也会导致网卡异常不发包？

答案是肯定的。

如下图所示，我们使用这样的代码片段构成异常报文，然后调用DPDK接口直接发送，很快网卡就会tx hang。

三、对直接操作硬件的思考

直接操作硬件是一件需要非常谨慎的事情，在传统的Linux系统中，驱动程序一般处于内核态由内核去管理，而且驱动程序代码中可能进行了各种异常处理，因此很少会发生用户程序操作导致硬件不工作的情况。而DPDK因为其自身使用用户态驱动的特点，使得可以在用户态直接操作硬件，同时为了提升性能可能进行了非常多的优化，如果用户自身程序处理出问题就有可能会导致网卡tx hang这样的异常情况发生。

四、工具的价值

我们编写了一键导出DPDK驱动队列报文的工具，这样就可以在每次出现问题时，快速导出网卡驱动发送队列中的所有报文，大大提高了排查效率。这个工具再优化下后，准备在UCloud GitHub上开源，希望对DPDK开发者有所帮助。

写在最后

DPDK作为开源套件，通常情况下稳定性和可靠性不存在什么问题，但是实际的应用场景千变万化，一些特殊情况可能导致DPDK工作异常。虽然发生概率很小，但是DPDK通常在关键的网关位置，一旦出现了问题，哪怕是很少见的问题也将会产生严重影响。

因此技术团队理解其工作原理并对其源码进行分析，同时能够结合具体现象一步步定位出DPDK存在的问题，对提高整个DPDK程序的服务可靠性具有重要意义。值得一提的是，ULB4的高可用集群架构在本次问题的处理过程中发挥了重要作用，在一台不可用的时候，集群中其他机器也可以继续为用户提供可靠服务，有效提升了用户业务的可靠性。

本文转载自公众号UCloud技术（ID：ucloud_tech）。

原文链接：

https://mp.weixin.qq.com/s/JgX_hNsRtEK1poaJU9-LrQ

创作场景

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