Tracert命令與PathPing命令你常用嗎：
前段時間本網吧網速不太正常.每晚8點后到11點之間網速爆慢.其余時間則正常。在8~11點間PING電信DNS TIME值要100多MS以上，但PING電信網關是正常的。PING網吧路由，網吧路由返回值正常且穩定也沒丟包現象，故先排除蠕蟲等病毒影響原因。
排除病毒干擾原因后就着手開始檢查是否局域網本身問題。因晚8~11時為高峰時段，考慮到網絡負荷問題及懷疑可能有部分網絡設備損壞，於是進行了排查。經檢測各機器網卡，網線，及其各交換機工作正常。且局域網內部游戲聯機，大規模文件復制均正常，速度理想。
既 然設備沒問題，且其余時間段網絡速度正常，就不太可能是網吧自身問題了。因為用的是4M的FTTB光纖帶不到200台機器按說還是滿輕松的。可事實又擺在 眼前，雖說看看網頁，聊聊QQ是沒問題，但上互聯網打打反恐PING值高達80多以上那也不能玩呀。去上海熱線下載頻道去下個文件平常都是300多 K/s，現在卻只有幾十K/s，呵可。那可不行啊。打電話給電信，遇到個SB技術說是我被黑客攻擊，呵呵，我路由防火牆的日志上根本就沒有攻擊記錄，又何 來的攻擊之說，再說我之前專門請我北京從事網絡安全工作的朋友幫測過，路由沒有漏洞。當然咱不排除重量級高手攻擊的可能。不過我想這小小網吧跟這種人應該 沒有什么直接利益關系吧。:)
在電話里跟那家伙理論了半天無果后只能做罷，這時腦中閃過一個念頭何不用Tracert命令跟蹤下路由看一下。於是Tracert 202.96.209.5 這個DNS看了一下。下面是跟蹤結果：
Tracing route to ns-px.online.sh.cn [202.96.209.5]
over a maximum of 30 hops:
1 <10 ms <10 ms <10 ms my.router [xxx.xxx.x.xxx]
2 <10 ms <10 ms <10 ms xxx.xxx.xxx.xxx
3 <10 ms <10 ms <10 ms 5ge0-ip-xxsn-012.online.sh.cn [218.1.2.141]
4 31 ms 47 ms 31 ms 218.1.2.29
5 47 ms 47 ms 31 ms 218.1.1.238
6 46 ms 47 ms 32 ms 1so1-0-jnpr-lc.online.sh.cn [202.109.0.58]
7 47 ms 47 ms 47 ms 1so1-0-jnpr-px.online.sh.cn [202.109.0.37]
8 63 ms 46 ms 47 ms vlan99-c6k2-px.online.sh.cn [202.109.39.5]
9 * * * Request timed out.
10 47 ms 46 ms 63 ms ns-px.online.sh.cn [202.96.209.5] Trace complete.
相 信大家看了結果懂行的心里明白的也應該差不多了。大家可以看到，從我網吧到DNS：202.96.209.5中間經過了8個路由。上面跟蹤結果中第一個路 由是我自己的。第十個是目的DNS。大家也看到了，在經過前三個路由時速度還是正常的都<10MS,從第四個開始網絡廷時開始變的時顯。當到達第九 個路由時壓根就沒反映了，來了個請求超時，由此看來是電信的部分路由出了問題無法及時處理數據而導致了網速變慢。知道原因后又致電給電信部門，叫他們技術 主管聽的電話把情況跟他說明后他看紙包不住火終於吐透了真相，原來是有部分路由器出了故障，正在准備更換成Cisco的設備，已有很多用戶向他們反映遇到 了上述問題。知道原因后讓人舒了口氣，幾天后網絡速度也恢復正常了。
好了故障敘述就到這了。下面給個PathPing的示例及注解給大家。希望能給有些朋友帶來幫助：
（PathPing 不僅具有Tracert的路由跟蹤功能，還能分析當前網絡狀況.2K及XP系統有此命令）
C:>pathping 202.96.209.133
Tracing route to ns-pd.online.sh.cn [202.96.209.133]
over a maximum of 30 hops:
0 a98 [192.168.0.98]
1 my.router [192.168.0.253]
2 218.80.229.73
3 5ge0-ip-yl-012.online.sh.cn [218.1.2.77]
4 218.1.2.1
5 4pos0-ip-jy-416.online.sh.cn [218.1.1.122]
6 218.1.1.238
7 vlan199-c6k1-pd.online.sh.cn [202.109.39.66]
8 ns-pd.online.sh.cn [202.96.209.133]
Computing statistics for 200 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 a98 [192.168.0.98]
10/ 100 = 10% | （請注意這一行：沿路徑轉發數據包丟失率的顯示在最右邊標記為 |）
1 0ms 0/ 100 = 0% 0/ 100 = 0% my.router [192.168.0.253]
0/ 100 = 0% |
2 2ms 0/ 100 = 0% 0/ 100 = 0% 218.80.229.73
0/ 100 = 0% |
3 4ms 1/ 100 = 1% 1/ 100 = 1% 5ge0-ip-yl-012.online.sh.cn [218.1.2.77]
0/ 100 = 0% |
4 3ms 0/ 100 = 0% 0/ 100 = 0% 218.1.2.1
0/ 100 = 0% |
5 4ms 0/ 100 = 0% 0/ 100 = 0% 4pos0-ip-jy-416.online.sh.cn [218.1.1.122]
0/ 100 = 0% |
6 2ms 0/ 100 = 0% 0/ 100 = 0% 218.1.1.238
0/ 100 = 0% |
7 3ms 0/ 100 = 0% 0/ 100 = 0% vlan199-c6k1-pd.online.sh.cn [202.109.39.66]
0/ 100 = 0% |
8 2ms 0/ 100 = 0% 0/ 100 = 0% ns-pd.online.sh.cn [202.96.209.133]
Trace complete.
帶有“|”標記的行顯示的信息，表示沿路徑轉發丟失的數據包。該丟失表明鏈接阻塞。顯示為百分比方式。
如上例：192.168.0.98（躍點 1）和 192.168.0.253（躍點 2）丟失 10% 的數據包。 所有其他鏈接工作正常
有個問題一直困擾了我很久了,希望各位高手幫忙解答
如下圖tracert到一個站點或者IP
問題一:tracert所經過的路由節點延遲信息1 2 3列分別是什么意思,為什么有這3列
問題二:在我們tracert一個站點時,往往會遇到中間某一個或者幾個節點延遲非常高,如圖第三跳的延遲達到了1000多ms,為什么最終ping到這個站點的延遲又是正常的.既然結果正常,那中間節點的這個延遲又充當什么角色.(這個是關鍵想知道的!)
至於大家回答的第三跳延遲這么高的原因不是重點,這個我知道原因,可能是運營商設備的icmp響應排序,大家可以忽略這點
在下例中，數據包必須通過兩個路由器（10.0.0.1 和 192.168.0.1）才能到達主機 172.16.0.99。主機的默認網關是 10.0.0.1，192.168.0.0 網絡上的路由器的 IP 地址是 192.168.0.1。
C:\>tracert 172.16.0.99
Tracing route to 172.16.0.99 over a maximum of 30 hops
1 2ms 3ms 2ms 10,0.0,1
2 75 ms 83 ms 88 ms 192.168.0.1
3 73 ms 79 ms 93 ms 172.16.0.99
Trace complete.
左邊的數字是該路由經過的路由器數目和順序。如果出現“*”表示往返時間太長，這個節點做了禁止跟蹤了，應該是核心設備的一跳，防止核心設備的IP泄露。引起一些不必要的麻煩，tracert將這個時間“忘記了”，也就是說服務器繁忙。
2ms是向經過的第一個路由器通常應該是網關了（220.170.78.166）發送報文的往返時間，由於每個報文每次的往返時間不一樣，tracert 將顯示三次往返時間。（你經過的第一個計算機發送報文的三次往返時間就不一樣，但一般的情況下是一樣的，比如你經過的第二台計算機）
在時間之后的，是設備的信息，是IP地址，它可以讓你知道，你的計算機與目的計算機在網絡上的距離有多遠，要經過多少步才能到達。
你目前的網絡，經過的第二個網關和第三個網關之間的延遲很大，如果是兩個不同的運營商之間設備的互通的話，你最好確定一下第三個網關的IP地址是那個運營商的，反饋信息給他，讓他替你解決問題
- 1. 三列 分別表示，為了准確性，tracert 每次發三個報文出去，返回三個值；
- 2. 結果不丟包或延時但過程有丟包或延時是因為：網絡設備的控制平面和轉發平面是兩套機制，你直接PING 包對於網絡設備來說，直接asic芯片轉發過去了；但你的TRACERT 報文其實是不停的去向交換機發一個目的IP是交換機的報文，這個時間，交換機需要調用CPU來處理這個報文，經常而言，像H3C 或華為這樣的設備，在CPU處理隊列中，ICMP的處理優先級是較低的（高的優先級都是用來處理路由表，MAC表，ARP表，CEF表的計算），所以你會 發現他的轉發OK，但處理ICMP報文延時嚴重甚至丟包！