你是不是也遇到过这种情况：
其实，十次有九次，问题就在网关配置或者转发路径出错。
这时候，最简单的办法就是：
第一步：先跑一遍 ，看看死在哪一跳
先来一张图说下工作原理。
命令通过发送ICMP（ ）数据包来追踪数据包的传输路径。它利用IP数据包中的TTL（Time to Live）字段来实现这一功能。
TTL字段用于限制数据包在网络中传输的最大跳数，每经过一个路由器，TTL值减1，当TTL值为0时，数据包被丢弃，发送方会收到一个ICMP超时消息。
在源主机上：
192.168.30.10
或者
/ 华为交换机上：
192.168.30.10
怎么看输出？
举例：
1 2 * * * 请求超时
3 * * * 请求超时
这说明啥？
→ 流量成功交给网关了，但网关后面没转发出去。
第二步：查目标网段路由表，看有没有去向
直接登录到第一跳网关设备：
ip -
或者
show ip
确认有没有目标网段（比如 192.168.30.0/24）的路由。
最常见两种错误：
现场真实案例：
有一次，客户现场配置是这样的：
源网段：192.168.10.0/24 目标网段：192.168.30.0/24 两网段中间有一跳防火墙。
结果 一跑：
第一跳正常，后面直接 。
进去看交换机，发现路由根本没指向防火墙， 原本该是：
ip - 192.168.30.0 255.255.255.0 192.168.20.2
结果误写成了：
ip - 192.168.30.0 255.255.255.0 192.168.10.254
直接导致包被打回源网段，走不了。
第三步：查目标设备的回程路由
注意！ 就算你把请求发出去了，目标网段设备也得知道怎么回你这边。
如果目标网段没有回程路由，依然 ping 不通， 也断。
做法：
登录目标网段网关：
ip -
确认是否有返回源网段的路由。
如果目标段没静态路由，也没跑动态路由（OSPF/静态/）， 一样走不回来。
第四步：最后一招：双向 验证
如果条件允许，从目标网段反向 回来：
192.168.10.10
可以确认流量在反方向死在哪一跳。
总结：用 查跨网段不通，最实用就三步：从源端 ，确认死在哪一跳到对应网关查路由表，看有没有漏写、错写检查目标网段有没有回程路由，不然流量回不来
有时候问题看着像 ACL、像物理故障，
但其实只是 路由指错 或 下一跳写漏，
真的是“网工排障现场最快速的定位神器”。
