记一次线上DPDK-LVS的故障排查 荐

首先，我们怀疑与dpvs或与金融的某些安全策略相关，因此我们做了如下测试（后端上跑的均是相同的测试代码，并模拟了服务端逻辑）：

client < ----- > dpvs < ----- > rs（金融区） 不正常

client < ----- > dpvs < ----- > rs（非金融区） 正常

client < ----- > lvs < ----- > rs（金融区） 正常

client < ----- > lvs < ----- > rs（非金融区） 正常

通过1、2组测试能够得出结论：该问题与金融区相关且dpvs转发正常

通过3、4组测试能够得出结论：该问题与金融区无关且kernel版lvs转发正常

通过1、3组测试能够得出结论：该问题与dpvs有关，经过dpvs的请求不正常

通过2、4组测试能够得出结论：该问题与dpvs/lvs无关，经过dpvs/lvs的请求均正常

以上4组结论两两冲突，无法定位问题是与dpvs相关还是与金融区相关，排查一度进入僵局，无法定位故障点。

为了进一步排查，我们在client和后端rs上抓包排查，发现client的请求均能够正常到达rs，而rs的大部分数据也能够正常回复给client，但有固定的几个包总是会被重传且直至超时，以下是抓包截图：

因此rs的网卡在数据包长度不足60字节时需要做两件事情：

• 补充1字节的padding达到最小长度60字节
• 补充的padding为全0

----- 网卡手册针对 TCP/UDP checksum部分的说明

至此，问题的原因已经很明显了：部分机器的网卡在做padding时未按照rfc894的规定补充全0而是补充了其他值，导致dpvs的网卡在做checksum offload时padding的数据也参与了checksum的计算。

分析正常的rs和不正常的rs在网卡硬件上的差别，发现：网卡的硬件型号相同，驱动型号也相同，但不正常的网卡fireware与正常的网卡不相同，而fireware我们没有办法自行升级或降级。

整个故障的过程可以大概表示为：

client dpvs rs

---1--- > 

                            < ---2---

    < ---3---

步骤1：数据包正常，请求数据

步骤2：部分数据包初始长度小于60字节，需要网卡补充padding，网卡先计算checksum填入tcp包头后补充padding至数据包末尾，此时checksum正常，但padding不为全0

步骤3：dpvs收到步骤2的包进行正常转发逻辑处理后转发至网卡，由网卡计算checksum并转发，但在计算新的checksum时由于padding非全0导致checksum计算错误，client收到后丢弃了这个包

ps：以上是rs的网卡在添加padding时补充的不是全0，另一种场景是client的网卡在添加padding时补充的不是全0，这两种情况都会导致上述问题的出现。

至此，我们已经能够解释最开始提出的三个问题：

dpvs已经在多个机房上线，运行时间已超过半年，为何突然有业务反馈异常

a：该业务是在某个核心机房上线了dpvs后出现了问题，其他机房很早上线了dpvs但由于其他机房是改业务的备份机房实际并未启用，因此半年多来一直没有发现问题

反馈问题的业务多与金融区相关（金融区由于其特殊性，会额外增加安全方面的加固策略）

a：排查发现是金融区的某一批次机器的fireware存在bug导致，与金融区本身的安全策略无关

为什么问题表现均为服务hang住

a：问题的实质是出现丢包，服务在等待响应，因此表现为hang住

接下来我们将解决该问题：

只要让dpvs在处理数据包时，忽略数据包以前的padding部分，而由dpvs的网卡重新去处理padding（由于网卡计算checksum是在补充padding之前，因此可以保证此时的checksum一定是正确的）。由于dpvs是基于dpdk开发的，数据包在dpvs中是以mbuf的结构保存和处理的，以下是mbuf的结构：

数据帧被存储在headroom和tailroom之间（与skb类似），pkt_len=data_len=整个数据帧的长度，我们要做的就是将padding从data中去除（放到tailroom中去），因此可以在数据包入口处添加以下代码：