明天是圣诞节，今天是平安夜，公司给提前下班。但是年假还有二十多天，不用也是浪费了，今天就请假休息一下。

从 10月25日开始，一直在排查一个比较复杂的网络问题。和网络组的同事们奋战了两个月，昨天终于有了答案，记录一下。

背景是我们内部的 一个类似 EKS¹ 的产品，是使用虚拟机来搭建，虚拟机的网络是一层虚拟的 Overlay 网络，然后虚拟机内搭建 Pod，Pod 也是在一层 Overlay 网络，整体上，这就是两层 Overlay 网络。封装 VXLAN 的网关（VTEP设备）需要相关的包进行两次 Overlay 封装。

为了 VXLAN 网关设备实现的简单，用了一个比较奇怪的路由方式，让普通路由器和网关设备配合完成两次封装：

1. 路由器收到包，查询路由，发现这个包应该转发给 VXLAN 网关，于是转发给 VXLAN 网关；
2. VXLAN 网关封装第一层 Overlay，目的 IP 改成 Overlay_IP_1 完成之后，交给路由器；
3. 路由器收到包，查询路由，发现这个包现在的 IP 地址 Overlay_IP_1 还是在 VXLAN 网关这里，再次转发给 VXLAN 网关，于是转发给 VXLAN 网关；
4. VXLAN 网关封装第二层 Overlay，目的 IP 改成 Overlay_IP_2 完成之后，交给路由器；
5. 路由器查询路由，转发给目的地址，完成；

说它奇怪，是因为在第 2 步和第 3 步，这个包的路由明明在 VXLAN 网关这里，但是包从 VXLAN 网关发给了路由器，路由器又转发回来。但是理论上是可行的。

我们遇到的问题是，这种实现方式实际会遇到 25% 或者 50% 的丢包。

问题本身就比较复杂，光是描述清楚就比较绕了，所以中间花了很多时间沟通，测试，验证，抓包。

25% 和 50% 这个数字很敏感，像是 4 个端口中的 1 个或者 2 个有问题。

我们的思路还是逐渐缩小问题范围，首先，确认丢包点在哪里——通过 ping 来缩小范围。最后定位到问题发生在第三步上，网关把包发给路由器之后，路由器并没有把包发送回来。

然后我用 scapy² 模拟了最简单的包在网关发出去，发现这个包确实没有从路由器转发回来。

但其实问题的范围还是很大，比如：

• 网关没有真正发出来这个包，即使我们抓包确认包发出去了，但是可能被网卡驱动，或者网卡硬件丢掉了；
• 路由器收到之后，没有转发这个包；
• 路由器转发了，但是被出口端口丢弃了；
• 路由器转发了，但是被网关丢了；
• 等等。

为了再缩小问题，我们用 SPAN³ 对路由器抓发，最后定位包确实到了路由器，路由器没有转发回来这个包。而且还发现一个细节：网关和路由器之间是有多条连线⁴的，路由器收到网关的包，然后选择路由器和网关之间的一条线，来把包还给网关，假设选中（hash）的线路恰好是收到包的线路，那么这个包就无法发回来。这也印证了 25% 和 50% 的丢包率。

在测试了几种品牌的交换机之后，发现只有 Cisco 品牌的交换机有这种行为。

到此为止，我们认为是路由器的 BUG。在讨论解决方案的时候，有同事发现丢包和包的一个 Header 有关，只要这个 Header 的值不为 0，就不会发生丢包。于是大家都很高兴，经过验证，确实不会丢包了。于是认为问题解决了。开始交付网络来测试。

测试发现流量稍大又会丢包了。中间又经过了很长时间的排查和验证，都不对，这里就不记录了。

最后，由于问题可以清晰地复现：用 scapy 构造一个包给路由器，路由宣告在自己这里，确认路由器不会按照宣告的路由发送回来。也能确认问题就是出在路由器这里了。

于是周一我们联系了 Cisco 的 TAC，提交了问题。下午就得到了回复。我的理解如下。

这并不能说是设备的 BUG，应该说是一个行为。即，在路由器视角看来，这个包的路由明明在网关这里，网关为什么要把这个包发给我呢？但是，路由器依然会按照路由把包转发给网关，但是会额外发送一个 ICMP Redirect⁵ 包给网关，提示它你有更优的路由可以选择，不要再发给我了。ICMP Redirect 消息，在之前的博客中⁶也讨论过。

但是我们的网关并不会理会路由器发送来的 ICMP 提示消息，因为这个多余的一跳是设计上的预期行为（至少在当前阶段是的，将来可能会优化这里）。所以会继续把包往非最优路由，即路由器，发送。

路由器对于收到的每一个包都会转发并且会发送一个 ICMP Redirect 消息。这个 ICMP Redirect 消息的成本非常高：路由器要从转发的包里面拿到源 IP 地址，然后构造一个 ICMP 包进行发送。这个操作无法在 ASIC 芯片上完成，需要 Line Card 把包上送到 CPU，由 CPU 处理这种复杂的任务。

ASIC 芯片能够直接处理设备接口的包，高速完成简单的转发操作。有点像 GPU，能做的事情不多，但是能做到的都很快。

CPU 能够完成很多复杂的任务，但是比较慢。而且，网络设备通常由多个 ASIC 芯片，一个芯片只负责几个接口，从而性能高到能让所有的接口达到线速。（在《Google 的十年五代网络架构》⁷一文中讨论过）。但是 CPU 的数量就相对少很多。

网络设备为了实现高速转发，会将大部分的操作都放在 Line Card 上来完成，不必上送到 CPU。

其他一些需要 CPU 来处理的操作，比如：

• 处理 TTL=1 的包（所以 mtr 来 debug 的时候经常看到中间的网络设备丢包⁸，但实际上不会造成问题，因为只会影响 TTL=1 的包，不会影响正常的数据包）；
• IP Fragmentation⁹；

此外，CPU 最主要的工作就是运行网络设备的操作系统，以及处理动态路由协议，比如 BGP 和 OSPF 等等。虽然我们使用的路由器的 CPU 已经很强大了，但是设备不会允许 CPU 花费过多的时间来做 ICMP Redirect 这种事情。所以 Nexus 7000 平台设计了 Control Plane Policing (CoPP) 的 feature，来保证路由协议，SSH 这种重要控制面的包能够得到最高的优先级。像 ICMP Redirect 这种包，即使 CPU 空闲，但是如果发送的过多，也会被限制。限制的结果就是不仅 ICMP Redirect 不会发送，连原来的包也不会转发，直接 Drop 掉。

CoPP 是很重要的保护措施，不建议关闭。

较好的解决方法更加简单，就是一行命令，在交换机的 interface 上执行 no ip redirects 就好了，即，让这个接口不要再生成 ICMP Redirect 消息，这样包就可以直接在 Line Card 完成转发，无需 CPU 处理。

Cisco 的工程师推荐了这篇文档：Understand ICMP Redirect Messages¹⁰，内容很不错。

1. https://aws.amazon.com/eks/ ↩︎
2. https://scapy.net/ ↩︎
3. 路由器和交换机的包分析方式：https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41.html ↩︎
4. 数据中心网络高可用技术之从服务器到交换机：802.3 ad ↩︎
5. https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Redirect ↩︎
6. 由一个子网掩码配置错误所想到的 ↩︎
7. Google 的十年五代网络架构 ↩︎
8. 使用 mtr 检查网络问题，以及注意事项 ↩︎
9. 有关 MTU 和 MSS 的一切 ↩︎
10. https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/nx-os-software/213841-understanding-icmp-redirect-messages.html#toc-hId–1052318184 ↩︎