traceroute - 打印路由數據包到網絡主機
概要
traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g 網關 ]
[ -i iface ] [ -m max_ttl] [ -p 端口 ]
[ -q nqueries ] [ -s src_addr ] [ -t tos ]
[ -w 等待時間 ] [ -z pausemsecs ]
主機 [ packetlen ]
描述
互聯網是由網關連接在一起的一個龐大而復雜的網絡硬件。 跟踪一個人的數據包所遵循的路線（或者找到丟棄數據包的惡意網關）可能很困難。 Traceroute使用IP協議 “生存時間”字段，並嘗試從每個網關沿某個主機的路徑引發ICMP TIME_EXCEEDED響應。
唯一的必需參數是目標主機名或IP號 。 默認的探測數據報長度是40 字節 ，但是可以通過在目標主機名後面指定數據包長度（以字節為單位）來增加。
其他選項是：
-F
設置第一個傳出探測包中使用的初始生存時間。
-F
設置“不碎片”位。
-d
啟用套接字級調試。
-G
指定一個鬆散的源路由網關（最多8個）。
-一世
指定網絡接口以獲取傳出探測數據包的源IP地址。 這通常只對多宿主主機有用。 （有關執行此操作的另一種方法，請參閱-s標誌。）
-一世
使用ICMP ECHO而不是UDP數據報。
-m
設置傳出探測數據包中使用的最大生存時間（最大跳數）。 默認值為30跳（與TCP連接使用相同的默認值）。
-n
以數字方式打印躍點地址，而不是以符號和數字方式打印躍點地址（保存路徑上找到的每個網關的名稱服務器地址到名稱查找）。
-p
設置探頭中使用的基本UDP端口號（默認值為33434）。 Traceroute希望在目標主機上沒有監聽UDP端口base + nhops - 1 （因此ICMP PORT_UNREACHABLE消息將被返回以終止路由跟踪）。 如果有某個端口在默認範圍內偵聽，則可以使用此選項來選擇未使用的端口範圍。
-r
繞過正常路由表並直接發送到連接網絡上的主機。 如果主機不在直接連接的網絡上，則返回錯誤。 此選項可用於通過無路由的接口ping本地主機（例如，在接口被路由 （8C）丟棄後）。
-s
使用下面的IP地址（通常以IP號碼，而不是主機名稱）作為傳出探測數據包中的源地址。 在多宿主主機（具有多個IP地址的主機）上，可以使用此選項強制源地址不是發送探測數據包的接口的IP地址。 如果IP地址不是本機的接口地址之一，則會返回錯誤並且不發送任何內容。 （有關執行此操作的另一種方法，請參閱-i標誌。）
-t
將探測包中的服務類型設置為以下值（默認為零）。 該值必須是0到255之間的十進制整數。此選項可用於查看不同的服務類型是否導致不同的路徑。 （如果你沒有運行4.4bsd，這可能是理論上的，因為正常的網絡服務如telnet和ftp不允許你控制TOS）。 並非所有TOS值都是合法或有意義的 - 請參閱IP規範中的定義。 有用的值可能是' -t 16 '（低延遲）和' -t 8 '（高吞吐量）。
-v
詳細輸出。 列出除TIME_EXCEEDED和UNREACHABLEs之外的所有ICMP數據包。
-w
設置等待探測響應的時間（以秒為單位）（默認5秒）。
-X
切換ip校驗和。 通常情況下，這可以防止traceroute計算ip校驗和。 在某些情況下，操作系統可能會覆蓋部分外發數據包，但不會重新計算校驗和（因此在某些情況下，缺省值不計算校驗和，並使用-x導致它們被計算）。 請注意，當使用ICMP ECHO探測（ -I ）時，通常需要使用校驗和。 所以在使用ICMP時總是計算它們。
-z
設置探針間暫停的時間（以毫秒為單位）（默認為0）。 一些系統如Solaris和路由器如Ciscos限制icmp消息。 使用這個值很好，就是500（例如1/2秒）。
該程序試圖通過啟動具有小ttl（生存時間）的UDP探測包然後監聽來自網關的ICMP“超過時間”應答來跟踪IP包將會跟隨到某個互聯網主機的路由。 我們用一個ttl開始我們的探測並增加一個，直到我們得到一個ICMP“端口不可達”（這意味著我們到達“主機”）或達到最大值（默認為30跳並且可以用-m更改旗）。 在每個ttl設置下發送三個探針（用-q標誌進行更改），並打印一行顯示網關的ttl，地址和每個探針的往返時間。 如果探測答案來自不同的網關，則會打印每個響應系統的地址。 如果在5秒內沒有反應。 超時間隔（用-w標誌改變），為該探針打印“*”。
我們不希望目標主機處理UDP探測包，因此目標端口被設置為不可能的值（如果目標上的某個塊使用該值，則可以使用-p標誌更改）。
示例使用和輸出可能是：
[犛牛71]％traceroute nis.nsf.net。 跟踪路由到nis.nsf.net（35.1.1.48），最多30跳，38字節的數據包1 helios.ee.lbl.gov（128.3.112.1）19 ms 19 ms 0 ms 2 lilac-dmc.Berkeley.EDU（128.32。 （128.32.136.23）39毫秒40毫秒39毫秒19毫秒3毫秒39毫秒39毫秒19毫秒-nerif22.Berkeley.EDU（128.32.168.22）39ms 39ms 39ms 6 128.32.197.4（128.32.197.4）40ms 59ms 59ms 7 131.119.2.5（131.119.2.5）59ms 59ms 59ms 8 129.140。 70.13（129.140.70.13）99 ms 99 ms 80 ms 9 129.140.71.6（129.140.71.6）139 ms 239 ms 319 ms 10 129.140.81.7（129.140.81.7）220 ms 199 ms 199 ms 11 nic.merit.edu（35.1 .1.48）239 ms 239 ms 239 ms請注意，第2行和第3行是相同的。 這是由於第二跳系統中的內核有問題 - lbl-csam.arpa - 它以零ttl（4.3BSD分佈式版本中的錯誤）轉發數據包。 請注意，由於NSFNet（129.140）不為NSS提供地址到名稱轉換，因此您必須猜測數據包採用什麼路徑進行跨國訪問。
一個更有趣的例子是：
[犛牛72]％traceroute allspice.lcs.mit.edu。 traceroute to allspice.lcs.mit.edu（18.26.0.115），30跳最大1 helios.ee.lbl.gov（128.3.112.1）0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU（128.32.216.1） 19 ms 19 ms 19 ms 3 lilac-dmc.Berkeley.EDU（128.32.216.1）39 ms 19 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU（128.32.136.23）19 ms 39 ms 39 ms 5 ccn-nerif22 .Berkeley.EDU（128.32.168.22）20ms 39ms 39ms 6 128.32.197.4（128.32.197.4）59ms 119ms 39ms 7 131.119.2.5（131.119.2.5）59ms 59ms 39ms 8 129.140.70.13（ （129.140.71.13）80ms 79ms 99ms 9 129.140.71.6（129.140.71.6）139ms 139ms 159ms 10 129.140.81.7（129.140.81.7）199ms 180ms 300ms 11 129.140.72.17（129.140.72.17）300 ms 239 ms 239 ms 12 * * * 13 128.121.54.72（128.121.54.72）259 ms 499 ms 279 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 ALLSPICE.LCS.MIT.EDU（18.26 .0.115）339毫秒279毫秒279毫秒請注意，網關12,14,15,16和17跳過，要么不發送ICMP“超時”消息，要么發送的ttl太小而無法到達我們。 14 - 17運行的MIT C網關代碼不發送“超時”。 上帝只知道12點發生了什麼。
上面的無聲網關12可能是4中的一個錯誤的結果。[23] BSD網絡代碼（及其衍生物）：4.x（x <= 3）使用原始中保留的任何ttl發送不可達消息數據報。 因為對於網關來說，剩餘的ttl為零，ICMP“超出時間”保證不會回到我們。 當它出現在目標系統上時，這個bug的行為會更有趣一些：
1 helios.ee.lbl.gov（128.3.112.1）0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU（128.32.216.1）39 ms 19 ms 39 ms 3 lilac-dmc.Berkeley.EDU（128.32.216.1） ）19 ms 39 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU（128.32.136.23）39 ms 40 ms 19 ms 5 ccn-nerif35.Berkeley.EDU（128.32.168.35）39 ms 39 ms 39 ms 6 csgw。 Berkeley.EDU（128.32.133.254）39ms 59ms 39ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 rip.Berkeley.EDU（128.32.131.22）59女士 ！ 39毫秒！ 39毫秒！請注意，有12個“網關”（13是最終目的地），而其中的後半部分“缺失”。 真正發生的事情是rip（Sun-3運行的Sun OS3.5）使用我們到達的數據報中的ttl作為其ICMP回復中的ttl。 因此，直到我們用至少為路徑長度兩倍的ttl進行探測時，回复才會在返迴路徑上超時（沒有發送給任何人的通知，因為ICMP沒有發送給ICMP）。 也就是說，撕裂實際上只有7跳。 以ttl為1返回的回復是存在此問題的線索。 Traceroute打印一個“！” 如果ttl <= 1，那麼在時間過後。由於供應商會發送大量過時的（DEC的Ultrix，Sun 3.x）或非標準（HPUX）軟件，因此希望頻繁查看此問題和/或小心挑選目標你的探測器的主機。
其他可能的註釋是！H ， ！N或！P （主機，網絡或協議不可達），！ S （源路由失敗），！ F- （需要分片 - 顯示RFC1191路徑MTU發現值）， ！X （管理通信禁止） ，！V （主機優先級違例） ，！C （有效優先截止）或！ （ICMP不可達代碼）。 這些由RFC1812（取代RFC1716）定義。 如果幾乎所有探測都會導致某種不可達的情況，traceroute會放棄並退出。
該程序旨在用於網絡測試，測量和管理。 它應該主要用於手動故障隔離。 由於負載可能會對網絡造成負擔，因此在正常操作期間或從自動化腳本中使用traceroute是不明智的。
也可以看看
pathchar（8），netstat（1），ping（8）