问题背景

问题出现在某次网络区域冗余演练时，同事反馈说主备交换机倒换后，出现了异常现象，网络 Ping 时通时不通，而主交换机恢复后网络恢复正常。在检查了相关配置后，也没有发现有什么问题，因为切换过程中影响了部分业务，所以并未再次倒换测试，最后记录该问题在此次网络冗余演练中。

我在之后收到该问题反馈后，加入一起做了相关故障排查和处理，最终问题虽然解决了，但又感觉没完全解决，留下挺多技术疑惑，都可以算是未解之谜了。

问题描述

网络拓扑如下，小网络区域组网情况很简单，除了最下的专线路由器单接外，其余设备均是双冗余。R1 等路由器上行到 SW3 或 SW4 交换机用的 HSRP，路由指向 VIP 1.1.1.1。

问题发生在 SW1 关机重启时，切换到 SW2 一侧后，从上到下的 Ping 1.1.1.10 出现了时通时不通的现象，当然这只是简单从网络检测上来说，从数据包上来说就是发生了丢包或严重超时，对业务来说，像是 TCP 通讯，肯定是大量超时重传最后断连。在 SW1 重启恢复后，网络 Ping 也随之恢复正常。

问题乍一看，像是感觉哪里网络配置有问题，但检查了一圈，包括网络拓扑、网络设备配置等，确实没有看出什么问题。架构和配置如此简单的情况下，如果出现完全通或完全不通还好理解，时通时不通实在不好解释，不得不怀疑防火墙了，像是 FW2 的问题。

但在没有实质根据的情况下，咋能随便麻烦别人。既然正常情况下检查不出啥问题，那就只能在下个变更窗口再次复原故障场景了，抓包验证，数据包不说谎。

问题分析

故障重现

测试拓扑和抓包点见下图，在 SW1 关闭下行至防火墙的端口后，故障现象重现。

逐一登录设备，发现了些许端倪，但仍无法完全定位问题原因，整理如下：

1. R1 设备重定向信息

ICMP: redirect rcvd from 1.1.1.2-- for 2.2.2.2 use gw 1.1.1.3

R1 持续收到 SW3 发来的重定向信息，要求使用网关 1.1.1.3，但由于路由器特殊，实际上忽略了该 ICMP 消息，仍然使用本身的路由下一跳，数据包仍然发给网关 1.1.1.1。

2. R1、SW3、SW4 等，逐一检查，在路由上并没有任何问题。

实际上当时在看到 R1 的重定向消息后，已经基本判定了是 SW3 和 SW4 SVI 下的重定向配置开启的问题，在关闭重定向后，Ping 恢复正常。

但是为什么会出现故障现象？按理说就算有重定向的问题，在路由一切正常的情况下，也应该是能正常转发，况且就算有路由问题，出现完全不通现象还说得过去。

至此只能通过实际抓包结果进行分析了，有了 SW3 和 SW4 的抓包结果，应该比较容易定位问题发生在哪了。

初步分析

上图是 SW3，下图是 SW4，梳理如下：

1. Ping 数据包共分为四组，其中第一组对应为 SW3 的 1 和 SW4 的 5 ，第二组对应为 SW3 的 2 和 SW4 的 6，以此类推；（以 ICMP seq 作为对应 10511-10514）

2. Ping 数据包的结果，第一、二、四组是不通的，第三组是通的。

以下以第一组（不通）的情况进行分析，第二组和第四组情况一致：

1. SW3 1 数据包

包含有 4 个 ICMP 数据包，因为 SW3 一共有两个抓包点（E1/1 和 E1/2），所以是有重复数据包的。

ICMP request 数据包，第一个是在 E1/1 的入方向抓取，紧接着该数据包往 E1/2 转发，第二个是在 E1/2 的出方向抓取；

ICMP reply 数据包，第三个是在 E1/2 的入方向抓取，紧接着该数据包往 E1/1 转发，第四个是在 E1/1 的出方向抓取；

2. SW4 5 数据包

仅包含有 2 个 ICMP 数据包，也就是 ICMP request 数据包。

ICMP request 数据包，第一个是在上行连防火墙的端口的入方向抓取，紧接着该数据包往 E1/1 转发，第二个是在 E1/1 的出方向抓取。

ICMP reply 数据包并没有收到，也就是说在 SW4 的 E1/1 的入方向是没有抓到数据包的，自然在上行连防火墙的端口的出方向也就没有。

3. 丢包点

ICMP reply 在中途发生了丢包，至于丢包点，实际上可能就两个地方，一个是 SW3，虽然说在 E1/1 的出方向抓取到，但实际上由于交换机 SPAN 的机制问题，并不能确定是否真正发出去了，有可能 SPAN 抓到了，但是在出接口的时候丢了；另一个是 SW4，接收的时候发生了丢弃。

以下以第三组（通）的情况进行分析：

1. SW3 3 数据包

包含有 4 个 ICMP 数据包，因为 SW3 一共有两个抓包点（E1/1 和 E1/2），所以同样是有重复数据包的。

ICMP request 数据包，第一个是在 E1/1 的入方向抓取，紧接着该数据包往 E1/2 转发，第二个是在 E1/2 的出方向抓取；

ICMP reply 数据包，第三个是在 E1/2 的入方向抓取，紧接着该数据包往 E1/1 转发，第四个是在 E1/1 的出方向抓取。

2. SW4 7 数据包

包含有 4 个 ICMP 数据包，因为 SW4 一共也是有两个抓包点（E1/1 和上行连防火墙的端口），所以同样是有重复数据包的。

ICMP request 数据包，第一个是在上行连防火墙的端口的入方向抓取，紧接着该数据包往 E1/1 转发，第二个是在 E1/1 的出方向抓取；

ICMP reply 数据包，第三个是在 SW4 的 E1/1 的入方向抓取，紧接着在上行连防火墙的端口的出方向抓取。

CASE 处理

在上述抓包现象比较明确的前提下，我们向厂商开了 Case ，经过和 TAC 交流，TAC 最后给的解释如下：

1. 确认为 IP 重定向引起的问题；

2. 未开启 IP 重定向的情况下，数据包由 R1 -> SW3 -> SW4，在交换机上均是硬件转发，路由处理；

3. 在开启 IP 重定向的情况下，数据包由 R1 上至 SW3 ，由于 SW3 开启了 IP 重向的原因，数据包全部上送 CPU 需要进行软处理，但是由于全局开有 COPP 特性（简单理解对于 CPU 的保护机制），对于上送 CPU 的数据包有相应的速率限制，在低于速率的时候，就走软处理路由出去，如果高于速率，就会产生丢包；

4. 目前普遍的网络环境上也是建议关闭 IP 重定向功能的。

实际上我们的基线配置在 SVI 上也是默认关闭 IP 重定向的，该环境上有所遗漏，才产生的相关问题。至此我们也是以为问题完美解决了，皆大欢喜。

再次分析

再次产生疑惑，实际上是我在写本篇文章的时候，在复盘数据包的时候发现了新的问题，细致推理下来，甚至感觉完全推翻了上面的结论。

以下开启了 MAC 地址信息，以及截取了 TTL 相关信息。

以下以第一组（不通）的情况进行分析，从 SPAN 的结果上来看，在 E1/1 的出口发生了路由处理（重封装了 SW3 至 SW4 的 MAC 地址），以及 TTL -1，但奇怪的是这样一个看起来正常的数据包（不管是属于硬件处理转发还是 CPU 软处理转发），反而产生了丢包。

以下以第三组（通）的情况进行分析，从 SPAN 的结果上来看，在 E1/1 的出口反而是没有发生任何路由处理，包括 MAC 地址和 TTL 均保持不变，同样奇怪的是这样一个看起来不正常的数据包，反而发出去了，到了 SW4 更神奇的是 MAC 地址和 TTL 均已改变，恢复了正常的 MAC aa:02至aa:03 和 TTL 254，因此 SW4 正常接收向上连防火墙端口转发，正常连通。

总的结论就是，从数据包角度来，看起来正常的数据包产生了丢包，看起来不正常的数据包反而正常连通。带着这奇葩的结果，继续开 Case 处理，但是 TAC 认为在 IP 重定向开启的场景下，SPAN 的结果可能产生异常，不能作数，反复沟通下无果，认了。。。

总结

虽然说最后的问题确实是网络配置导致，关闭 IP 重定向的情况下也得到了相应解决，但整个排障过程下来，结果确实不令人满意，带来很多疑惑。

业内总说的一句话，数据包不说谎，也许大多数场景下适合，但我想总结的是，数据包不说谎，但生成数据包的未必准确。

参考

https://www.cisco.com/c/zh_cn/support/docs/ios-nx-os-software/nx-os-software/213841-understanding-icmp-redirect-messages.html