问题分享：checksum与padding

最近碰到了padding导致checksum错误的问题，初步整理了一下，与大家分享。

拓扑如上所示，A给B发送了一个数据，B处理后转给C，C报错checksum failed。

经过在A出口处抓包，和在C入口处抓包，发现报文差异如下：

显然发现，这里面padding不一样。说实话，我之前也不知道padding是啥东西，果断查了一下，得到解释如下：

以太网规定的数据帧最小长度为64字节，当报文的长度不足时，数据链路底层会自动增加字节补齐。

在我们的环境中，A的应用层序发送了一个1字节的UDP探测报文，结果经过层层封装以后，发送给A的网卡，结果发现，长度还是不够：

于是A的网卡填充了padding，补齐64字节的要求，并重新计算了checksum。

这里网卡发送的报文携带vlan，并添加了全0的padding。

报文发给交换机1，交换机1上行对接交换机2是三层口，于是交换机把vlan剥掉。剥掉以后报文又不满足64字节的要求了，于是交换机自己补上了padding。可是，此时交换机补上了非0的内容。

交换机2将报文打上vlan标签，发给B，此时padding并不会被删除。

B收到报文，由于B是用户态的网关设备，报文直接被DPDK送到应用层序。而应用层序处理报文五元组信息，原则上也不会打开包详细解读，只是对于IP或者端口做些修改，当然也没有把报文的padding删除到，就直接把报文丢回给网卡。

B的网卡收到报文以后，此时报文是带着padding，网卡认为这也是数据包的一部分，因此将整个报文重新计算了checksum，然后转发给C。

C的网卡收到报文，rx计算checksum，读取报文长度，只计算有效报文，即不包括padding，此时发现checksum incorrect。

为什么之前没有出现这样的问题？

之前网关并没有使用DPDK，即所有的报文都是走内核协议栈处理的，协议栈会识别padding并把它剥离。随着DPDK技术的发展，对于报文的处理直接越过了协议栈。

交换机为啥要加非0的padding？

这，目前还不知道，毕竟协议规定是 should be，也没说是must。

如何解决这个问题？

方法有二：

1、 用户态应用程序自己识别padding并自己计算checksum。但是这样会损耗部分性能

2、 网卡在tx时也要读取报文的len并以此为依据计算checksum，这需要网卡定制开发。