licson

非對稱路由

非對稱路由可是看traceroute的最大障礙。由於traceroute只能顯示單方的網路路徑，不過traceroute結果裡面每一個節點的延遲值可是由兩部分組成：由你到達該節點的時間，再加上節點傳送ICMP TTL Exceed封包回來的時間。而且，除了traceroute不能顯示反向路徑以外，反向路徑是可以和traceroute顯示的路徑完全不同的。唯一的解決方法就是去看雙方的traceroute結果，不過就算是這樣也不一定可以看出夾在中間的非對稱路徑。

非對稱路徑通常會出現在網路邊緣，因為在這一些地方是兩個不同網路的交換點，而且網管的規條都會隨著不同的網路而一起轉變。我們首先以以下的路徑作為例子：

1. te1-1.ar2.DCA3.gblx.net (69.31.31.209) 0.719 ms 0.560 ms 0.428 ms
   
2. te1-2-10g.ar3.DCA3.gblx.net (67.17.108.146) 0.574 ms 0.557 ms 0.576 ms
   
3. sl-st21-ash-8-0-0.sprintlink.net (144.232.18.65) 100.280 ms 100.265 ms 100.282 ms
   
4. 144.232.20.149 (144.232.20.149) 102.037 ms 101.876 ms 101.892 ms
   
5. sl-bb20-dc-15-0-0.sprintlink.net (144.232.15.0) 101.888 ms 101.876 ms 101.890 ms

複製代碼

看過第一篇的朋友們都應該知道這路徑是有問題的，不過到底問題是出在哪邊呢？那有可能是Global Crossing和Sprint之間的擠塞，可是也可以是因爲非對稱的反向路由導致的。在Global Crossing去Sprint之間，路由策略就改變了。這一種情況會在很多有多餘上游ISP和互連的網路出現（因爲他們有多種可用路徑）在上面的例子，Sprint的反向路由有一個路由界面出現擠塞，但是並不能在上面的traceroute看出來。

那麼該怎麼透過traceroute知道反向路由是不是有問題？那就要透過控制你traceroute的源IP了。不過這個辦法並不是所有人都可以做到所以我就先跳過了。非對稱路由經常出現，尤其是當兩個網路在多個地點都有鏈接的時候路由器會選擇最接近自己的出口。



就像上圖的路徑，紅色的路會透過芝加哥的鏈接回去，而綠色的路則會透過矽谷的鏈接回去。

多重路徑

因爲Traceroute可以使用UDP或是TCP封包而且他們的鏈接埠號碼都不同，路由器的ECMP（Equal Cost Multi-Path）會把traceroute封包作負載平衡，造成在traceroute上看到多種路徑。這並不是什麼問題，不過可能會導致traceroute的結果很混亂。以下是一些例子

1. 1 TenGE0-1-2-0.cr04.hkg05.pccwbtn.net (63.218.174.58) 176 msec 172 msec
   
2.    TenGE0-3-0-0.cr04.hkg05.pccwbtn.net (63.218.174.34) 148 msec
   
3. 2 TenGE0-4-0-2.cr03.lax05.pccwbtn.net (63.218.214.34) 144 msec 144 msec 144 msec

複製代碼

1. 6 ldn-bb2-link.telia.net (80.91.251.14) 74.139 ms 74.126 ms
   
2.   ldn-bb1-link.telia.net (80.91.249.77) 74.144 ms
   
3. 7 hbg-bb1-link.telia.net (80.91.249.11) 89.773 ms
   
4.   hbg-bb2-link.telia.net (80.91.250.150) 88.459 ms 88.456 ms
   
5. 8 s-bb2-link.telia.net (80.91.249.13) 105.002 ms
   
6.   s-bb2-link.telia net (80.239.147.169) 102.647 ms 102.501 ms

複製代碼

上面的例子中，三個traceroute有兩個是走一條路徑，剩下的一個就走其他的路徑。以下是一個更加複雜的路徑：

1. 1 *
   
2.   TenGE0-1-0-0.cr04.tok01.pccwbtn.net (63.223.26.42) 109 msec
   
3.   TenGE0-0-0-16.cr01.tok13.pccwbtn.net (63.223.26.50) 106 msec
   
4. 2 TenGE0-0-0-6.cr04.lax05.pccwbtn.net (63.223.16.2) [MPLS: Label 17563 Exp 0] 108 msec
   
5.   TenGE0-0-0-20.cr01.tok13.pccwbtn.net (63.223.26.46) 106 msec
   
6.   TenGE0-1-0-5.cr02.tok01.pccwbtn.net (63.223.33.45) 110 msec
   
7. 3 TenGE0-5-0-6.cr03.lax05.pccwbtn.net (63.223.41.6) [MPLS: Label 16051 Exp 0] 106 msec
   
8.   TenGE0-0-0-6.cr04.lax05.pccwbtn.net (63.223.16.2) 109 msec
   
9.   TenGE0-5-0-6.cr03.lax05.pccwbtn.net (63.223.41.6) 106 msec
   
10. 4 ae11.PCCW.lax.us.AS40676.net (23.238.223.9) 106 msec 105 msec
    
11.   TenGE0-0-1-0.br03.lax05.pccwbtn.net (63.218.72.66) 106 msec
    
12. 5 edge-owb.psychz.net (192.184.37.164) 106 msec 108 msec
    
13.   ae11.PCCW.lax.us.AS40676.net (23.238.223.9) 105 msec
    
14. 6 lg.lax.psychz.net (104.149.18.203) 106 msec 106 msec 106 msec

複製代碼

上面的traceroute看起來又向前又向後很混亂對吧？那是因爲路由器負載平衡的路徑是不同長度而導致的。想避免這種混亂是有辦法，你可以設定traceroute程式每一次只傳送一個traceroute封包，那樣就不會看到多重路徑了。不過要記着如果這樣做的話出問題的地方不一定是你traceroute的那個路徑，嘗試別的路徑的辦法包括把IP位置加一又或是改變源IP位置。

MPLS 和 traceroute 的關係

現在有很多大型網路的核心路由器都在使用MPLS，甚至有一些路由器連BGP路由表也沒有，單純靠封包上的MPLS Label作轉送。這對於傳送封包當然一點問題也沒有，不過在路由器遇到Traceroute封包需要產生ICMP回應就變得麻煩了。到底一個只支援MPLS的路由器是要怎麼發需要使用IP協議的ICMP封包呢？其中一個辦法叫做ICMP Tunneling，當只支援MPLS的路由器需要發送ICMP封包的時候，他會把產生的ICMP封包塞在與Traceroute封包同樣的Label-Switched Path裏面，當該ICMP封包離開Label-Switched Path以後就會在末端的路由器送回去。這樣雖然是可以正確發送信息，不過卻會令traceroute看起來很奇怪。



在有MPLS的情況下，traceroute就不是這樣運作了。ICMP封包需要到Label-Switched Path的末端才能把ICMP回應送回去（如下圖）。



由於所有在Label-Switched Path裏面產生的ICMP回應都一定要到達MPLS路徑末端才能折返，這會令每一個在Label-Switched Path裏面的路由器的回應時間都和目標的回應時間差不多。以下是一些例子：

1. 1  bbs-1-250-0-210.on-nets.com (210.0.250.1)  1.055 ms  0.934 ms  0.890 ms
   
2. 2  10.2.194.9 (10.2.194.9)  1.003 ms  1.019 ms  1.078 ms
   
3. 3  116.0.67.65 (116.0.67.65)  1.340 ms  1.380 ms  1.342 ms
   
4. 4  if-ae-5-2.tcore1.TV2-Tokyo.as6453.net (180.87.112.206)  225.622 ms
   
5.     if-ae-3-2.tcore1.TV2-Tokyo.as6453.net (180.87.112.6)  231.923 ms
   
6.     if-ae-5-2.tcore1.TV2-Tokyo.as6453.net (180.87.112.206)  225.294 ms
   
7. 5  * * *
   
8. 6  if-ae-5-2.tcore2.SQN-San-Jose.as6453.net (64.86.21.1)  229.382 ms  226.593 ms  224.672 ms
   
9. 7  if-ae-29-2.tcore1.CT8-Chicago.as6453.net (64.86.21.105)  226.783 ms  228.131 ms  227.053 ms
   
10. 8  if-ae-22-2.tcore2.CT8-Chicago.as6453.net (64.86.79.1)  232.270 ms  229.951 ms  245.002 ms
    
11. 9  if-ae-3-2.tcore1.W6C-Montreal.as6453.net (66.198.96.45)  240.296 ms  254.460 ms  253.818 ms
    
12. 10  if-ae-5-2.tcore1.MTT-Montreal.as6453.net (64.86.31.5)  226.321 ms  237.972 ms  225.478 ms
    
13. 11  64.86.173.20 (64.86.173.20)  229.200 ms  230.520 ms  225.507 ms

複製代碼

1. 1 te2-4.ar5.PAO2.gblx.net (69.22.153.209) 1.160 ms 1.060 ms 1.029 ms
   
2. 2 192.205.34.245 (192.205.34.245) 3.984 ms 3.810 ms 3.786 ms
   
3. 3 tbr1.sffca.ip.att.net (12.123.12.25) 74.848 ms 74.859 ms 74.936 ms
   
4. 4 cr1.sffca.ip.att.net (12.122.19.1) 74.344 ms 74.612 ms 74.072 ms
   
5. 5 cr1.cgcil.ip.att.net (12.122.4.122) 74.827 ms 75.061 ms 74.640 ms
   
6. 6 cr2.cgcil.ip.att.net (12.122.2.54) 75.279 ms 74.839 ms 75.238 ms
   
7. 7 cr1.n54ny.ip.att.net (12.122.1.1) 74.667 ms 74.501 ms 77.266 ms
   
8. 8 gbr7.n54ny.ip.att.net (12.122.4.133) 74.443 ms 74.357 ms 75.397 ms
   
9. 9 ar3.n54ny.ip.att.net (12.123.0.77) 74.648 ms 74.369 ms 74.415 ms
   
10. 10 12.126.0.29 (12.126.0.29) 76.104 ms 76.283 ms 76.174 ms
    
11. 11 route-server.cbbtier3.att.net (12.0.1.28) 74.360 ms 74.303 ms 74.272 ms

複製代碼

licson

回覆 33# evantkh


    我看是全CN2沒錯。

ccu

好有用，一直都想知多d traceroute

冷

去程趕時間行西隧, 回程有時間行紅隧.
雯雯 發表於 2016-5-13 09:31

    唔係應該話兜左去東隧咩

雯雯

咁又直係直連，不過個段路經常塞車，感覺好像紅隨。。。^_^!!
hkjimmytam 發表於 2016-5-13 19:16

ISP無俾足咁多部車既隧道費, 可能淨係俾行西隧慢線.

冷

應該係話，留返西隨比 ViP 客。。。平民百姓。。。當然慢慢塞車。。。
hkjimmytam 發表於 2016-5-13 20:25

就咁當然無得用，不過traceroute CN2既ip都試到
tracert 60.247.96.2
除左PCCW，其它都要用人地架車先可以入西隧
想問下你條九倉係咪都係直連?