traceroute 怎么判读
每一跳都是靠 TTL 超时与 ICMP 回应得到的，所以中间节点不回应 ICMP 超时是常态，星号并不等于故障点。判读要看「从哪一跳开始出现连续星号、并且后续也一直不通」；单跳或间歇星号而后续正常，通常只是该设备做了策略限制。关键结论要用两端 ping 与接口计数交叉验证。
基本信息
| 适用设备 | 三厂通用（华为 VRP / H3C Comware / 思科 IOS） |
|---|---|
| 命令拼写 | 华为/H3C 是 tracert；思科是 traceroute |
| 常用参数 | 最大跳数：华为/H3C 用 -m；超时：华为/H3C 用 -w，思科用 timeout |
| 核心判读 | 连续星号 + 后续不通 = 问题区段 |
| 佐证手段 | 两端长 ping、接口错包计数、路由表路径核对 |
典型使用场景
- 确认路径是否按设计走（排查绕行与次优路径）
- 判断不通发生在网络哪一段，缩小排查范围
- 路由变更后验证转发表路径是否同步变化
- 双向各跑一次，判断是否存在路径不对称
- 与防火墙、负载均衡共存的场景下作为参考而非结论
华为 VRP
华为 VRP
tracert 3.3.3.3
tracert -m 10 -w 2 3.3.3.3 # 最大 10 跳，超时 2 秒
tracert -a 10.1.1.1 3.3.3.3 # 指定源地址，验证特定源路径思科 IOS
思科 IOS
traceroute 3.3.3.3
traceroute 3.3.3.3 numeric timeout 2
traceroute 3.3.3.3 source 10.1.1.1
! numeric 只显示地址，便于贴进工单与文档H3C Comware
H3C Comware
tracert 3.3.3.3
tracert -m 10 -w 2 3.3.3.3
tracert -a 10.1.1.1 3.3.3.3输出逐列读法
| 列 | 含义 | 判读要点 |
|---|---|---|
| 跳数 | 第几跳路由器 | 关注连续星号的起始跳 |
| IP 地址 | 该跳回应的接口地址 | 可能不是实际转发接口，回程路径不同时会有偏差 |
| 时延（多个探测值） | 三次探测的往返时延 | 数值突增需结合两端长 ping，控制面处理慢也会造成偏大 |
| * 星号 | 该跳未返回 ICMP 超时 | 单跳或间歇星号属常态，连续星号且后续不通才是问题区 |
| 到达提示 | 目标已响应 | 说明端到端可达 |
traceroute 依赖 TTL 超时与 ICMP 应答，防火墙与负载均衡会屏蔽或改写中间回应，看到的路径视图可能与实际转发不一致。关键结论必须用两端 ping 与接口计数交叉验证。
合理设置超时与最大跳数能显著加快排障：默认超时较长时一次运行可能耗时很久，先缩短超时、限制跳数定位区间，再对可疑区段做细查。