注：本文是同事的大作，雖是翻譯的一篇英文PPT，但內容實在精彩，小小的Traceroute竟包含如此大的信息量，真是讓人感慨！內容不涉及公司機密，所以一直想轉到自己的Blog上來，自己需要時可以再翻閱學習。
-----------------------------------------------------
-
原文Created and last modified by tanzh on 十月 14, 2014
本人網絡知識比較欠缺，最近就在網上游逛，學習網絡知識，機緣巧合找到一個思路很廣的PPT，於是就將其翻譯改寫，查找相關資料，加入自己學習過程中的理解和實驗，分享給大家，共同學習，共同進步。
一、概述
1.1 什么是Traceroute
當遇到網絡問題，通常會用Traceroute去排查，但Traceroute是什么？
根據百度百科定義，Traceroute是一種電腦網絡工具，它可顯示數據包在IP網絡經過的路由器的IP地址。
Traceroute有三大特點：
-
跨平台。Traceroute工具存在與各個操作系統平台，包括主流系統MAC OS、Windows、Linux、Android、IOS等；
-
使用方便。只要在Traceroute后輸入IP或域名即可；
-
信息全面。Traceroute能夠顯示跳數、丟包情況、延時等信息。
但使用Traceroute並根據路由跟蹤情況就能排查出問題？答案是否定的。
1.2 Traceroute的問題所在
使用Traceroute並根據路由跟蹤情況也不能排查出問題，到底是怎么回事？
-
現代商業網絡運行情況良好。低級的問題如擁塞、環路，在實際問題中占非常低的概率；更多的問題是非常復雜以至於只靠單純的Traceroute已無法准確排查；
-
很少人是真正的理解Traceroute並且利用其分析問題。大部分ISP NOC甚至是專業的網絡工程師也難以解釋一個復雜的路由；有非常多的誤判報告充斥着世界各地NOC；高誤判率導致幾乎無法從這些報告中判斷出真正最根本的網絡問題。
二、Traceroute原理
2.1 Traceroute實現原理
-
從SRC發出一個探測包到DST，並將TTL設置為1；
-
每一跳TTL將會減一；
-
當TTL變為0時，包被丟棄，路由器向SRC發回一個ICMP TTL Exceed包；
-
當SRC收到該ICMP包時，顯示這一跳信息；
-
重復1～5，並每次TTL加1；
-
直至DST收到探測數據包，並返回ICMP Dest Unreachable包；
-
當SRC收到ICMP Dest Unreachable包時停止traceroute。
2.2 Traceroute實現細節
-
傳統UNIX系統使用UDP包進行探測，目標端口號為33434，每次探測目標端口號增加1；Windows的tracert.exe和MTR則使用ICMP Echo Request包探測；
-
如果DST沒有返回ICMP Dest Unreachable包則不能探測到DST。這是會發生在某些情況下，如DST前有防火牆，或者DST進行了配置，或者是DST上有一個真實的應用在監聽該端口；
-
通過設置UDP/TCP/ICMP包中的CLI標識位都能夠實現Traceroute，一般來說，不推薦使用TCP包，因為通常會被過濾掉；
-
不同的實現方式通常都會向每跳發送多個探測包，典型的Traceroute默認發送3個探測包，如果沒有收到那一跳的回應，延時數據將會輸出3個*號；MTR會循環發送無數個探測包；
-
每個探測包都有唯一的標識號，使得Traceroute能夠識別返回的包，UDP/TCP使用遞增的目標端口號進行標識，ICMP使用seq #；
-
由於4層哈希能使每個探測包走不同的路由，對於Traceroute來說，在三層的等價多路徑（ECMP）下可見，在二層的聚合鏈路LAG下不可見；
-
雖然探測包走不同路徑引起不同的結果，但TTL還是相同的。
2.3 Traceroute延時計算
-
在探測包發出時打上時間戳；
-
當收到ICMP響應時打上時間戳；
-
根據兩個時間戳計算往返時間；
注：延時計算的是包的往返時間，但Traceroute顯示的是去的路徑上所經過的路由，在包返回過程中產生的時延也會影響你的測試結果。
2.4 每一跳產生原理
-
SRC發送TTL為1的包給Router 1；
-
Router 1收到包后將TTL減1，Router 1發現TTL=0后，丟棄該包，不再轉發，並向SRC發送ICMP TTL Exceed包，該包目標IP為SRC的IP，源IP為Router 1的Ingress Interface的IP，Traceroute就會根據ICMP TTL Exceed包的源IP顯示一跳；
-
在上圖中SRC會顯示兩跳，172.16.2.1 10.3.2.2；
-
你無法從Traceroute中得知包返回的路徑以及路由器使用的ICMP Return Interface和Egress Interface的IP。
注：值得一提的是在RFC1812 4.3.2.4 ICMP Message Source Address中提到，ICMP包的源地址必須是傳包出去的物理接口綁定的其中一個IP（Except where this document specifies otherwise, the IP source address in an ICMP message originated by the router MUST be one of the IP addresses associated with the physical interface over which the ICMP message is transmitted.）。
經過與hewt實驗證實了這個問題。一個探測包確實會有可能從路由器的一個接口進，ICMP TTL Exceed包從另外一個接口出，並且源IP是進的接口IP，按照個人理解其原因是路由器會把進的接口產生的TTL超時包當作外來的包並遵循路由表進行路由轉發，轉發過程不會改變包的源目IP。因此在外部看來這個ICMP包並不符合RFC文檔的定義。
三、Traceroute中的DNS反向解析
理解Traceroute中的DNS反向解析是使用Traceroute的一個非常重要的一個方面。
在Traceroute中的DNS反向解析我們能夠獲取到以下信息：
-
路由器地理位置
-
接口類型與帶寬
-
路由類型與角色
-
網絡自治系統的邊界與關系
對於推斷問題原因，以上信息顯得尤為重要。
3.1 路由器地理位置
為什么我們需要知道地理位置？
-
確定不對或者是不太合適的路由。從亞特蘭大到邁阿密經過紐約，那就不太理想了。
-
確定高延時是否合理。從印度到美國要300ms，但從日本到美國並不需要300ms。
-
幫助你理解網絡互聯的節點。
我們常用的幫助識別位置信息的有：
-
IATA Airport Codes(International Air Transport Association Airport Codes)
-
CLLI Codes(Common Language Location Identifier)
-
非標准簡寫的城市名
-
Country Codes
-
還有一些其他的信息
3.2 接口類型與帶寬
很多網絡都會嘗試將接口信息放在DNS，需要注意的是：
-
接口信息通常是幫助他們排查自己網絡的問題；
-
接口信息有可能不是最新的。雖然很多大型網絡會自動產生DNS，但其余的不會；
-
可以幫助你識別接口的類型，通過接口類型甚至可以知道路由器的型號。
例子：xe-11-1-0.edge1.NewYork1.Level3.net
xe-11-1-0是Juniper 10GE端口，該設備至少有12個板卡槽
至少一台40G/板卡槽的路由器，因為它有一塊10GE板卡在板卡槽1
常見接口類型對照表：
| Interface Type |
Cisco IOS |
Cisco IOS XR |
Juniper |
|---|---|---|---|
| Fast Ethernet | Fa#/# | fe-#/#/# | |
| Gigabit Ethernet | Gi#/# | Gi#/#/#/# | ge-#/#/# |
| 10 Gigabit Ethernet | Te#/# | Te#/#/#/# | xe-#/#/# (*) |
| SONET | Pos#/# | POS#/#/#/# | so-#/#/# |
| T1 | Se#/# | t1-#/#/# | |
| T3 | t3-#/#/# | ||
| Ethernet Bundle | Po# / Port-channel# | BE#### | ae# |
| SONET Bundle | PosCh# | BS#### | as# |
| Tunnel | Tu# | TT# or TI# | ip-#/#/# or gr-#/#/# |
| ATM | ATM#/# | AT#/#/#/# | at-#/#/# |
| Vlan | Vl### | Gi#/#/#/#.### | ge-#-#-#.### |
3.3 路由類型與角色
知道路由器角色是非常有用的，但每個AS都不一樣，使用不同的角色命名，並且他們也不會一直遵循自己的命名規則。
總的來說，你只能通過你的網絡知識去猜路由器的角色。
通常來說有以下規律：
-
Core routers – CR, Core, GBR, BB, CCR, EBR
-
Peering routers – BR, Border, Edge, IR, IGR, Peer
-
Customer routers – AR, Aggr, Cust, CAR, HSA, GW
3.4 網絡自治系統的邊界與關系
識別網絡自治系統邊緣很重要：
-
能幫助你知道路由策略變化的地方。如：不同的返回路徑是基於本地優先級的；
-
能幫助你知道帶寬與路由最差的地方，這些地方可能就是產生問題的地方；
-
當然也能幫助你知道應該去聯系誰。
識別網絡自治系統的關系同樣有所幫助：
-
典型三個角色：Transit Provider、Peer、Customer
-
很多網絡都會嘗試將以上信息寫在DNS上。如etworkname.customer.alter.net
有時能夠看到反解域名的明顯變化：
|
|
有時能夠看到DNS的某一部分變化：
|
|
當然有時DNS的信息根本沒有用：
|
|
以上無法判斷GBLX的邊界，同時無法判斷192.205.34.109是在哪里。
來看更多的信息：
|
|
ar5.DCA3.gblx.net有多個DNS域名解析，通過以上分析，就算第5跳的DNS中沒有cogent字眼提示也能判斷第5跳與第4跳分屬兩個自治系統（命名規則發生變化）。
以上分析涉及到一個關鍵點，根據/30掩碼獲取對端IP。
如上圖，兩個接口雖然同在一個/30掩碼網段內，但路由器並不會收集或維護鄰居的DNS信息，所以當一個包發出時路由器並不知道鄰居的DNS信息，這時就會填充上自己接口的DNS信息而不是留空白讓鄰居去填充。因此通過分析對端的接口信息，就能夠知道路由器所屬自治系統（若64.212.107.89的域名是cogent-0.ar5.DCA3.gblx.net，那么ar5.DCA3路由器將屬於兩個自治系統）。
四、網絡延時
三種主要網絡延時：
-
串行延時。該延時是路由器或交換機發送數據包的時間，串行延時=包大小(bits)/傳輸速率(bps)；
-
排隊延時。該延時是數據包在路由器隊列中等待發出的時間，非擁塞情況下排隊延時可忽略不計；
-
傳播延時。該延時是數據包在傳播介質中傳播所用時間，該延時主要取決於光或電磁的傳播速度。
4.1 串行延時
該延時產生在轉發數據包的時候，產生原因：
-
一個數據包被移動到網絡上的時候是一個不可分的單元；
-
在一個數據包傳輸完畢之前另外一個數據包無法發送。
在高速網絡中該延時非常小
1500 bytes over a 56k link (56Kbps) = 214.2ms delay
1500 bytes over a T1 (1.536Mbps) = 7.8ms delay
1500 bytes over a FastE (100Mbps) = 0.12ms delay
1500 bytes over a GigE (1Gbps) = 0.012ms delay
4.2 排隊延時
1. 利用率
1G的接口跑到500Mbps我們會說利用率是50%，但實際上，一個接口只能進行轉發數據（100%利用）或者不能轉發數據（0%利用），故所謂的50%利用率實際上是指1s內有0.5s用來了傳輸數據。
2. 排隊
當一個接口在被使用，下一個包必須排隊等待被發送。通常來說，一個接口90%使用率等於將要轉發的包90%都在排隊。當一個接口達到飽和時，排隊時間將迅速增加，當一個接口過飽和時，一個包排隊可能要耗費幾百甚至幾千毫秒，排隊延時通常與擁塞程度相關聯。
4.3 傳播延時
該延時由光信號或電磁信號在介質中的傳播速度與距離決定。光速（真空狀態下傳播）約為300,000km/s，但光纖是由玻璃制作，非真空，故光在光纖內傳播速度較真空狀態慢，約為0.67c，即200,000km/s，1ms的往返延時距離為100km。
例子：
環地球赤道一圈（約為40000km）傳播延時大概為200ms（往返延時為400ms）。
知道以上數據，通過traceroute的每一跳地理位置信息，通過距離計算傳播延時就知道延時是否正常了。
|
|
美國紐約到英國倫敦只需要67.6ms，兩地相距約6759km，延時正常。
|
|
在美國本土傳播耗時220ms，延時不正常。