跟踪路由下一跳问题

  不是流量跳过汇聚，是 防火墙做完 SNAT 之后，TTL 超时报文被 NAT 会话劫持 + 二层直连 + M‑LAG 双活网关的回程不对称 + Linux 默认 UDP traceroute，汇聚三层虽然转发报文，但它的 TTL‑expire 回包根本回不到 Linux 终端；同时 ICMP 错误报文源地址是防火墙入接口实 IP，不会用 VRRP 虚地址回复。  

防火墙上静态路由下一跳为汇聚 M‑LAG 虚拟网关 IP，但互联接口是二层桥接接口（最高概率）

防火墙的路由：ip‑route‑static 目标网段 掩码 汇聚M‑LAG‑虚IP

• 防火墙查路由下一跳是虚拟网关 IP，在二层 VLAN 内 ARP 解析得到 M‑LAG 系统的统一虚拟 MAC；
• 防火墙不会把报文交给汇聚设备做三层转发；报文二层封装直接发给 M‑LAG 系统 MAC，报文 IP 层 TTL不做递减。

❗报文到达汇聚 M‑LAG 设备之后，才第一次做三层转发，TTL 才减 1。 Linux traceroute 探测包 TTL 到达防火墙的时候：TTL 还没耗尽；报文二层透传给到汇聚，在汇聚才发生 TTL=0、产生 ICMP TTL‑exceeded。 但是这个 ICMP 超时报文的源 IP 是汇聚 M‑LAG 的 VLANIF 虚 IP，回程报文经过防火墙 NAT 会话；防火墙的安全策略 / 状态检测会把该 ICMP 错误报文丢弃，Linux 终端收不到汇聚返回的 TTL 超时应答，所以汇聚这一跳直接消失，直接显示目的地址H3C。

解释为什么显示防火墙的实 IP：防火墙本身也会处理部分 TTL 耗尽的探测包，返回自身物理接口真实 IP，而不是 VRRP 虚 IP（VRRP 虚 IP 只用于网关接收报文，ICMP 错误报文使用出接口实 IP 回复）。

2）往返路径不对称 + M‑LAG 哈希负载分担加剧现象

防火墙→汇聚方向二层，汇聚返回防火墙方向同样二层；ICMP TTL‑exceeded 回包经过防火墙 NAT 会话，ICMP Type‑11（TTL 超时错误报文）被防火墙状态会话机制丢弃。

虽然 trust‑untrust 策略配置 any 放行业务，但 V7 防火墙 NAT 环境下，ICMP 错误报文需要专门放行，业务 permit any 不等于允许 ICMP 错误报文穿越 NAT 会话回源端。

注意：交换机侧ip ttl‑expires enable已经打开，汇聚 M‑LAG 设备内部已经生成 ICMP 超时报文，但是回包无法穿过防火墙回到 Linux 终端，不是交换机没有发送。

区分验证手段

1. 直接在防火墙上执行 traceroute 目的 IP：此时汇聚 M‑LAG 跳数可以正常显示，证明汇聚本身可以正常生成 TTL 超时报文。
2. 在汇聚交换机 debug icmp，看是否可以看到汇聚发出 ICMP‑TTL‑exceeded 报文；同时在防火墙看会话统计，确认该 ICMP 错误报文被丢弃。
3. Linux 使用 TCP 模式探测：traceroute ‑T 目的IP，部分场景可以规避 UDP 探测包 NAT‑ICMP 错误丢弃问题。

整改方案（分两种思路）

方案 A：优化三层互联（根治，推荐）

防火墙与汇聚 M‑LAG 之间不要二层 VLAN 对接，改为三层互联（子接口 / 三层路由口）：

1. 防火墙侧、汇聚侧建立三层互联网段，防火墙上静态路由下一跳填写汇聚三层实接口 IP，不再填写 M‑LAG 虚拟网关 IP；
2. 报文经过防火墙三层转发（TTL‑1），再到汇聚三层接口（TTL 再‑1）；汇聚产生 ICMP‑TTL‑exceeded 报文，该 ICMP 回包源 IP 为三层互联网段地址，经过防火墙更容易正常转发回源终端，tracert 可以正常看到汇聚跳数。

优点：彻底解决隐身跳问题；缺点：需要改动现有二层对接组网。

方案 B：不改动现有二层组网，调整防火墙放行 ICMP 错误报文（临时改善，有局限）

现有二层对接保留，防火墙上配置专门放行 ICMP 错误报文（ICMP type11），使汇聚 M‑LAG 发出的 TTL‑exceeded 报文，经过防火墙 NAT 之后可以回送到 Linux 源终端。

1. V7 防火墙 NAT 环境，需要开启nat alg icmp‑error，用于处理 NAT 之后 ICMP 错误报文转换；

2. 安全策略需要放行 ICMP type‑11 时间超时报文，注意：业务策略为 any，不代表自动放行 ICMP 错误报文，部分版本会话检测会拦截该类差错报文。

⚠️该方案有局限：M‑LAG 哈希负载分担场景下，仍然有部分探测报文会出现跳丢失；不能 100% 保证每次 traceroute 都完整显示全部跳数，业务完全不受影响，仅排障工具体验改善。

重要业务说明

该现象只影响 traceroute 工具显示，业务 ping、转发、NAT、HA、M‑LAG 双活业务全部正常，不影响现网业务运行，不建议为 tracert 显示完整跳数大规模改动现网架构。

补充踩坑点

1. 不要混淆 VRRP 虚 IP 与 M‑LAG 双活网关：防火墙 VRRP 仅用于内网侧，防火墙去往汇聚的静态路由下一跳指向 M‑LAG 虚网关，就会触发 “二层透传、TTL 不在防火墙递减” 这个现象。
2. Linux traceroute 默认使用 UDP 高阶端口探测包；Windows tracert 默认使用 ICMP Echo 探测包，二者行为会有区别，同一网络 Windows tracert 输出结果可能和 Linux 不一样。

总结：

1. 根因：防火墙二层对接 M‑LAG 汇聚，静态路由下一跳指向 M‑LAG 虚拟网关，报文二层透传给汇聚，在汇聚才发生 TTL 耗尽；汇聚发出 ICMP‑TTL‑exceeded 回包被防火墙 NAT 会话拦截，终端收不到应答，汇聚跳隐身。
2. 根治：防火墙‑汇聚改成三层互联；兼容方案开启nat alg icmp‑error enable放行 ICMP 差错报文。
3. 业务不受影响，仅 traceroute 工具显示异常。