遇到網絡故障的時候，你一般會最先使用哪條指令進行排障？
除了Ping，還有Traceroute、Show、Telnet又或是Clear、Debug等等。
今天安排的，是Traceroute排障指令詳解，給你分享2個經典排障案例哈。
01
Traceroute原理和功能
Traceroute是為了探測源節點到目的節點之間資料封包所經過的路徑。
利用IP封包的TTL域在每經過一個路由器的轉發後減一，當TTL=0時則向源節點報告TTL逾時這個的特性。
Traceroute首先發送一個TTL為1的Icmp request封包，是以第一跳發送回一個ICMP錯誤消息以指明此資料報不能被發送（因為TTL逾時）。
之後Traceroute再發送一個TTL為2的封包，同樣第二跳傳回TTL逾時，這個過程不斷進行，直到到達目的地。
此時，由于資料報中使用了無效的端口号（預設為33434），目的主機會傳回一個ICMP的目的地不可達消息，表明該Traceroute操作結束。
Traceroute記錄下每一個ICMP TTL逾時消息的源位址，進而提供給使用者封包到達目的地所經過的網關IP位址。
Traceroute 指令用于測試資料封包從發送主機到目的地所經過的網關。
主要用于檢查網絡連接配接是否可達，以及分析網絡什麼地方發生了故障。
02
不同平台的Traceroute指令
01 RGNOS平台的Traceroute指令
舉個例子，在銳捷RG系列路由器上，Traceroute指令的格式如下：
Traceroute host 『destination』
例如：檢視到目的主機10.15.50.1 中間所經過的網關。
RG# traceroute 10.15.50.1
Type esc/CTRL^c/CTRL^z/q to abort.
traceroute 192.168.0.1 ......
1 10.110.40.1 1 4 ms 5 ms 5 ms
2 10.110.0.64 10 ms 5 ms 5 ms
3 10.110.7.254 10 ms 5 ms 5 ms
4 10.3.0.177 175 ms 160 ms 145 ms
5 129.9.181.254 185 ms 210 ms 260 ms
6 10.15.50.1 230 ms 185 ms 220 ms
Trace complete successfully.
02 Windows平台的Tracert 指令
在PC機上或Windwos為平台的伺服器上，Tracert指令的格式如下：
tracert [ -d ] [ -h maximum_hops ] [ -j host-list ] [ -w timeout ] host
-d ：不解析主機名。
-h：指定最大TTL大小。
-j：設定松散源位址路由清單。
-w：用于設定UDP封包的逾時時間，機關毫秒；例如：檢視到目的主機10.15.50.1 中間所經過的前兩個網關。
:\>tracert -h 2 10.15.50.1
Tracing route to 10.15.50.1 over a maximum of 2 hops:
1 3 ms 2 ms 2 ms 10.110.40.1
2 5 ms 3 ms 2 ms 10.110.0.64
Trace complete.
03
使用Traceroute指令進行故障排除
排障案例① 使用Traceroute指令定位不當的網絡配置點
1、現象描述：
組網情況如下圖所示：
某校園網中，RouterB和RouterC同屬于一個運作RIPv2路由協定的網絡，主機4.0.0.2通路資料庫伺服器5.0.0.2，使用者抱怨通路性能差。
2、相關資訊：
在主機上ping 5.0.0.2顯示如下：
C:\Documents and Settings\c>ping -n 10 -l 1000 5.0.0.2
Pinging 5.0.0.2 with 1000 bytes of data:
Reply from 5.0.0.2: bytes=1000 time=552ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=5735ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=551ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=5734ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=549ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=5634ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=555ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=5738ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=455ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=5811ms TTL=250
3、原因分析：
上面的Ping顯示出一個規律，奇數封包的傳回時長短，而偶數封包傳回時長很長（是奇數封包的10倍多）。
可以初步判斷奇數封包和偶數封包是通過不同的路徑傳輸的。
現在我們需要使用Traceroute指令來追蹤這不同的路徑。在RouterC上，Traceroute遠端RouterA的以太網接口5.0.0.1。
RouterC(config)#traceroute
Target IP address or host: 5.0.0.1
Maximum number of hops to search for target [30]:10
Repeat count for each echo[3]:8
Wait timeout milliseconds for each reply [2000]:
Type esc/CTRL^c/CTRL^z/q to abort.
traceroute 5.0.0.1 ......
1 6 ms 4 ms 4 ms 4 ms 4 ms 4 ms 4 ms 4 ms 4.0.0.1
。。。。。。（中間省略）
5 20 ms 16 ms 15 ms 16 ms 16 ms 16 ms 16 ms 16 ms 3.0.0.2
6 30 ms 278 ms 25 ms 279 ms 25 ms 278 ms 25 ms 277 ms 5.0.0.1
RouterC(config)#
從上面的顯示可看到，直至3.0.0.2，UDP探測封包的傳回時長都基本一。
而到5.0.0.1時，則發生明顯變化，呈現奇數封包時長短，偶數封包時長長的現象。
于是判斷，問題發生在RouterB和RouterA之間。
通過詢問該段網絡的管理者，得知這兩路由器間有一主一備兩串行鍊路，主鍊路為2.048Mbps（s0口之間），備份鍊路為128Kbps（s1口之間）。
網絡管理者在此兩路由器間配置了靜态路由。
RouterB上如下配置：
RouterB（config）# ip route 5.0.0.0 255.0.0.0 1.0.0.2
RouterB（config）# ip route 5.0.0.0 255.0.0.0 2.0.0.2
RouterA上如下配置：
outerA（config）# ip route 0.0.0.0 0.0.0.0 1.0.0.1
RouterA（config）# ip route 0.0.0.0 0.0.0.0 2.0.0.1
于是問題就清楚了。
例如RouterB，由于管理者配置時沒有給出靜态路由的優先級，這兩條路由項的管理距離就同為預設值1。
然後就同時出現在路由表中，實作的是負載分擔，而不能達到主備的目的。
4、處理過程：
可以有兩種處理方法。
一個是，繼續使用靜态路由，進行配置更改 RouterB上進行如下更改：
RouterB（config）# ip route 5.0.0.0 255.0.0.0 1.0.0.2 （主鍊路仍使用預設1）
RouterB（config）# ip route 5.0.0.0 255.0.0.0 2.0.0.2 100（備份鍊路的降低至100）
RouterA上進行如下更改：
RouterA（config）# ip route 0.0.0.0 0.0.0.0 1.0.0.1
RouterA（config）# ip route 0.0.0.0 0.0.0.0 2.0.0.1 100
這樣，隻有當主鍊路發生故障，備份鍊路的路由項才會出線在路由表中，進而接替主鍊路完成封包轉發，實作主備目的。
第二個是，在兩路由器上運作動态路由協定，如OSPF，但不要運作RIP協定（因為RIP協定是僅以hop作為Metric的）。
5、建議和總結：
本案例的目的不是為了解釋網絡配置問題，而是用來展示Ping指令和Traceroute指令的互相配合來找到網絡問題的發生點。
尤其在一個大的組網環境中，維護人員可能無法沿着路徑逐機排查，此時，能夠迅速定位出發生問題的線路或路由器就非常重要了。
排障案例② 使用Traceroute指令發現路由環路
1、現象描述：
組網情況如下圖所示：
三台路由器均配置靜态路由，完成後，登入到RouterA上Ping主機4.0.0.2，發現不通。
2、相關資訊：
RouterA# ping 4.0.0.2
Sending 5, 100-byte ICMP Echos to 4.0.0.2,
timeout is 2000 milliseconds.
.....
Success rate is 0 percent (0/5)
RouterA# traceroute 4.0.0.2
Type esc/CTRL^c/CTRL^z/q to abort.
traceroute 4.0.0.2 ......
1 6 ms 4 ms 4 ms 1.0.0.1（RouterB）
2 8 ms 8 ms 8 ms 1.0.0.2（RouterA）
3 12 ms 12 ms 12 ms 1.0.0.1（RouterB）
4 16 ms 16 ms 16 ms 1.0.0.2（RouterA）
。。。。。。
3、原因分析：
從上面的Traceroute指令的顯示可以立即發現，在RouterA和RouterB間産生了路由環路。
由于是配置的是靜态路由，基本可以斷定是RouterA或RouterB的靜态路由配置錯誤。
檢查RouterA的路由表，配置的是預設靜态路由：ip route 0.0.0.0 0.0.0.0 1.0.0.1，沒有問題。
檢查RouterB的路由表，配置到4.0.0.0網絡的靜态路由為：ip route 4.0.0.0 255.0.0.0 1.0.0.2――下一跳配置的是1.0.0.2，而不是3.0.0.1。這正是錯誤所在。
4、處理過程：
修改RouterB的配置如下：
RouterB（config）# no ip route 4.0.0.0 255.0.0.0 1.0.0.2
RouterB（config）# ip route 4.0.0.0 255.0.0.0 3.0.0.1
故障排除。
5、建議和總結：
Traceroute指令能夠很容易發現路由環路等潛在問題。
當路由器A認為路由器B知道到達目的地的路徑，而路由器B也認為路由器A知道目的地時，就是路由環路發生了。
使用Ping指令隻能知道接收端出現逾時錯誤，而Traceroute能夠立即發現環路所在――如果Traceroute指令兩次或者多次顯示同樣的接口。
當通過Traceroute發現路由環路後，如果配置為：
- 靜态路由：幾乎可以肯定是手工配置有問題，如本案例所示。
- OSPF協定：可能是位址聚合産生的問題。
- 多路由協定：可能是路由引入産生的問題。
本文轉載網絡工程師俱樂部，侵删。