你是不是也遇到過這種情況：

其實，十次有九次，問題就在網關配置或者轉發路徑出錯。

這時候，最簡單的辦法就是：

第一步：先跑一遍 ，看看死在哪一跳

先來一張圖說下工作原理。

命令通過發送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、像物理故障，

但其實只是 路由指錯 或 下一跳寫漏，

真的是“網工排障現場最快速的定位神器”。