H3C CR16000系列路由器，ping测试异常

先做流量统计定位下丢包位置

一、现象本质总结
两台 CR16000 直连：
A：配置 ip route-static X.X.X.X 255.255.255.255 对端互联IP（/32 静态路由指向 B）
B：依靠默认路由回程
ping 目标 / 32 地址：TTL 奇数可通、偶数不通；就算在路由器 A 本机 ping 也复现故障
该现象是 CR16000 分布式转发 + ECMP 等价路由哈希选路特性 导致的经典故障，新华三知了社区有同型号同款案例。
二、完整故障成因
1. CR16000 硬件架构前提
CR16000 是分布式主控 + 多业务板转发架构，转发芯片做 ECMP 负载分担时，默认以 五元组哈希（含 TTL 字段参与哈希计算） 来选择转发板卡 / 聚合成员链路。
奇数 TTL、偶数 TTL 经过哈希计算后，会命中两条不同的回程转发路径。
2. 来回路径不对称 + 其中一条路径单向阻断
正向报文（A→B）：A 的 / 32 静态路由只有唯一下一跳，走固定链路送到 B，不会负载分担；
回程报文（B→A）：B 依靠默认路由回程，若 B 的默认路由存在 ECMP 等价多路径（比如默认路由迭代到 2 条聚合链路、跨业务板转发通道），回程报文会被哈希分流；
因为 TTL 参与哈希：
TTL=奇数：回程命中正常链路，ICMP 回复顺利回到 A，ping 通；
TTL=偶数：回程命中异常链路（某业务板转发故障、聚合成员单向阻断、ACL 丢弃回程报文、芯片 FTN 表项异常），报文被丢弃，ping 不通。
3. 为什么在路由器 A 本机 ping 也能复现？
即便本地发起 ping，ICMP 请求报文上送主控 CPU 后，下发转发面时依然会执行全局 ECMP 哈希逻辑，偶数 TTL 依然会命中故障回程路径，因此本机测试故障依旧存在。
4. 补充隐性诱因
B 的默认路由存在 2 条及以上等价下一跳（聚合口、多上联链路形成 ECMP）；
CR16000 老版本固件存在缺陷：TTL 纳入 ECMP 哈希因子，新版本默认剔除 TTL 做哈希；
聚合组成员链路存在单通故障（发方向正常、收方向丢包）。
三、分步排查验证（由浅入深）
步骤 1：确认 B 设备默认路由是否存在 ECMP 等价路径
登录路由器 B 执行：
bash
display ip routing-table 0.0.0.0 0 verbose
若输出 ECMP: Yes、存在多个出接口 / 下一跳 → 确认回程存在等价负载分担，命中故障前提；
若默认路由只有唯一下一跳，排查聚合链路单通、业务板硬件故障。
步骤 2：验证是否链路单通
在 B 上关闭默认路由其中一条 ECMP 下一跳，再次 ping 测试：
关闭其中一条等价路由后，奇偶 TTL 全部正常连通 → 证明被关闭的这条链路单向阻断；
排查 B 默认路由对应的聚合口成员状态：
bash
display link-aggregation summary
display link-aggregation member-port
查看聚合成员端口是否存在入方向丢包、CRC 错误。
步骤 3：查看转发芯片 ECMP 哈希因子（确认 TTL 参与哈希）
CR16000 查看 ECMP 哈希配置：
bash
display ecmp hash-mode
老固件默认哈希因子包含 TTL，偶数、奇数 TTL 分流至不同链路。
四、4 种落地修复方案（推荐顺序 1→2→3→4）
方案 1（最简临时修复，立刻生效）：消除回程 ECMP，让回程只有唯一路径
在路由器 B 上，给回程指向 A 的网段写精确静态路由，替换默认路由回程，彻底消除 ECMP 负载分担：
bash
# 假设A互联网段为 100.2.1.0/30，A互联地址100.2.1.1
ip route-static 100.2.1.0 255.255.255.252 100.2.1.1 preference 50
回程不再走默认路由的 ECMP 路径，所有 TTL 报文走同一条链路，奇偶 TTL 全部正常连通。
方案 2（根治方案，修改 ECMP 哈希模式，剔除 TTL 字段）
修改设备全局 ECMP 哈希策略，不再将 TTL 作为哈希因子，无论 TTL 奇偶，报文命中同一条回程路径：
bash
system-view
ecmp hash-mode src-dst-ip src-dst-port protocol
# 仅用五元组基础字段哈希，不纳入TTL
save
新版本 CR16000 固件出厂默认已经移除 TTL 哈希因子，老固件建议升级配套版本。
方案 3：修复聚合链路单通故障
定位聚合内故障成员端口，更换光模块 / 光纤；
聚合模式修改为静态聚合，关闭 LACP 乱序分担；
bash
link-aggregation group X mode static
方案 4：升级 CR16000 固件版本
升级至 R7174 及以上正式版本，新版本修复了「TTL 参与 ECMP 哈希」的设计缺陷，从底层规避该奇偶 TTL 分流故障。
五、补充避坑说明
不要怀疑 / 32 路由配置错误：正向路由是唯一路径，正向转发永远正常，问题只出在回程 ECMP 分流；
若两台设备是直连三层接口无聚合，故障基本是 B 设备业务转发板硬件异常，更换业务板即可；
复现测试方法：固定 TTL=3（奇数通）、TTL=4（偶数断），关闭 B 其中一条 ECMP 路由后，TTL=4 也能通，即可完全定位故障链路。
精简总结
病根：B 回程默认路由存在 ECMP 等价链路 + CR16000 老固件 TTL 参与哈希，奇偶 TTL 分到两条回程链路，其中一条链路单向丢包；
最快解决：在 B 配置指向 A 互联网段的精确静态路由，取消回程 ECMP；
长久根治：修改 ECMP 哈希模式、升级固件剔除 TTL 哈希因子。

你遇到的这个问题，根源在于CR16000系列路由器基于TTL（Time To Live，生存时间）值进行哈希选路的机制，导致ICMP回显请求（ECHO-REQUEST）和回显应答（ECHO-REPLY）报文走了不同的路径。

🔍 问题原因分析

这是一个典型的路由来回路径不一致问题，具体机制如下：

1. ECMP（等价多路径）：你的网络中，数据包在路由器A和B之间存在多条等价路径。

2. 基于TTL的哈希：CR16000的部分转发芯片在进行路径选择（哈希）时，会将IP报文头中的TTL值作为输入因子之一。TTL为奇数和偶数的报文，会被哈希到不同的物理链路上。

3. 路径故障：这两条路径中，有一条存在单向不通的问题，例如链路中断、板卡转发故障，或默认路由迭代到了错误的下一跳。

4. 现象：

   • TTL为奇数：A发出的请求报文走“好”的路径到达B，B的回应报文也走“好”的路径返回A，因此能通。

   • TTL为偶数：A发出的请求报文被哈希到“坏”的路径上，报文无法到达B或B的回应无法返回，因此不通。

🛠️ 排查与解决方法

第一步：确认ECMP路径

首先，登录到路由器A和B，查看路由表，确认是否存在多条等价路径。

• 在路由器A上，查看去往目标/32地址的路由：

  text

  display ip routing-table x.x.x.x 32 verbose

• 在路由器B上，查看默认路由：

  text

  display ip routing-table 0.0.0.0 0 verbose

如果输出结果显示存在多个下一跳或出接口，则说明ECMP路径确实存在。

第二步：检查链路状态

检查所有可能的物理链路、聚合接口的状态，确认是否存在隐性故障。

第三步：执行路径追踪

通过指定出接口和TTL值发送ping包，可以验证不同TTL的报文是否走了不同的路径。

通过对比，可以确认不同TTL的报文是否真的走了不同的出接口。

第四步：解决方案（三选一）

根据以上排查结果，你可以选择以下任一方法来解决：

• 方案一：调整路由，确保来回路径一致（最彻底）
  通过调整路由协议（如OSPF）的Cost值或静态路由的优先级，强制所有流量只走一条“好”的路径，避免ECMP的产生。

• 方案二：修改哈希算法，移除TTL因子（推荐）
  在系统视图下修改IP转发的哈希因子，配置为不基于TTL值进行哈希，例如只基于源IP和目的IP。

  text

  ip load-sharing mode per-flow dest-ip source-ip

  这样所有报文都会基于相同的因子（如IP地址）进行哈希，确保往返路径一致。

• 方案三：在沿途设备上开启ICMP超时报文发送功能（辅助手段）
  这条命令有助于tracert等工具更好地工作，但不能直接解决因TTL奇偶导致的路径不一致问题。

  text

  ip ttl-expires enable

  该命令的作用是让设备在收到TTL为0的报文时，能够发送ICMP超时报文