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 哈希因子。