On Unix-like operating systems, the traceroute command prints the route that packets take to a network host.
This document covers the Linux version of traceroute.
The Internet is a large and complex aggregation of network hardware, connected together by gateways. Tracking the route your packets follow (or finding a gateway that's discarding your packets) can be difficult. The traceroute command utilizes the IP protocol "time to live" field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to some host.
The only mandatory parameter is the destination hostname or IP number. The default probe datagram length is 40 bytes, but this may be increased by specifying a packet size (in bytes) after the destination hostname.
traceroute attempts to trace the route an IP packet would follow to some Internet host by launching probe packets with a small ttl (time to live) then listening for an ICMP "time exceeded" reply from a gateway. It start its probes with a ttl of one and increases this by one until it gets an ICMP "port unreachable" (or TCP reset), which means we got to the "host", or hit a max (which defaults to 30 hops). Three probes (by default) are sent at each ttl setting and a line is printed showing the ttl, address of the gateway and round trip time of each probe. The address can be followed by additional information when requested. If the probe answers come from different gateways, the address of each responding system will be printed. If there is no response within a 5.0 seconds (default), an "*" (asterisk) is printed for that probe.
After the trip time, some additional annotation can be printed: !H, !N, or !P (host, network or protocol unreachable), !S (source route failed), !F (fragmentation needed), !X (communication administratively prohibited), !V (host precedence violation), !C (precedence cutoff in effect), or !<num> (ICMP unreachable code <num>). If almost all the probes result in some kind of unreachable, traceroute gives up and exit.
You don't want the destination host to process the UDP probe packets, so the destination port is set to an unlikely value (you can change it with the -p flag). There is no such a problem for ICMP or TCP tracerouting (for TCP we use half-open technique, which prevents our probes to be seen by applications on the destination host).
In the modern network environment the traditional traceroute methods can not be always applicable, because of widespread use of firewalls. Such firewalls filter the "unlikely" UDP ports, or even ICMP echoes. To solve this, some additional tracerouting methods are implemented (including tcp); see LIST OF AVAILABLE METHODS below. Such methods try to use particular protocol and source/destination port, to bypass firewalls (to be seen by firewalls just as a start of allowed type of a network session).
Explicitly force IPv4 or IPv6 tracerouting. By default, the program will try to resolve the name given, and choose the appropriate protocol automatically. If resolving a hostname returns both IPv4 and IPv6 addresses, traceroute will use IPv4.
-I
Use ICMP ECHO for probes.
-T
Use TCP SYN for probes.
-d
Enable socket level debugging (if the kernel supports it).
-F
Do not fragment probe packets. (For IPv4 it also sets DF bit, which tells intermediate routers not to fragment remotely as well).
Varying the size of the probing packet by the packet_len command-line parameter, you can manually obtain information about the MTU of individual network hops. The --mtu option (see below) tries to do this automatically.
Note, that non-fragmented features (like -F or --mtu) work properly since the Linux kernel 2.6.22 only. Before that version, IPv6 was always fragmented, IPv4 could use the once the discovered final mtu only (from the route cache), which can be less than the actual mtu of a device.
-f first_ttl
Specifies with what TTL to start. Defaults to 1.
-g gateway
Tells traceroute to add an IP source routing option to the outgoing packet that tells the network to route the packet through the specified gateway (most routers have disabled source routing for security reasons). In general, specifying multiple gateways is allowed (as a comma-separated list). For IPv6, the form of num,addr,addr... is allowed, where num is a route header type (default is type 2). (Note: the type 0 route header is now deprecated, according to rfc 5095).
-i interface
Specifies the interface through which traceroute should send packets. By default, the interface is selected according to the routing table.
-m max_ttl
Specifies the maximum number of hops (max time-to-live value) traceroute will probe. The default is 30.
-N squeries
Specifies the number of probe packets sent out simultaneously. Sending several probes concurrently can speed up traceroute considerably. The default value is 16. Note that some routers and hosts can use ICMP rate throttling. In such a situation specifying too large number can lead to loss of some responses.
-n
Do not try to map IP addresses to hostnames when displaying them.
-p port
For UDP tracing, specifies the destination port base traceroute will use (the destination port number will be incremented by each probe). For ICMP tracing, specifies the initial ICMP sequence value (incremented by each probe too). For TCP and others specifies just the (constant) destination port to connect. When using the tcptraceroute wrapper, -p specifies the source port.
-t tos
For IPv4, set the Type of Service (TOS) and Precedence value. Useful values are 16 (low delay) and 8 (high throughput). Note that to use some TOS precedence values, you have to be superuser. For IPv6, set the Traffic Control value.
-l flow_label
Use specified flow_label for IPv6 packets.
-w waittime
Set the time (in seconds) to wait for a response to a probe (default is 5.0).
-q nqueries
Sets the number of probe packets per hop. The default is 3.
-r
Bypass the normal routing tables and send directly to a host on an attached network. If the host is not on a directly-attached network, an error is returned. This option can be used to ping a local host through an interface that has no route through it.
-s source_addr
Chooses an alternative source address. Note that you must select the address of one of the interfaces. By default, the address of the outgoing interface is used.
-z sendwait
Minimal time interval between probes (default 0). If the value is more than 10, then it specifies a number in milliseconds, else it is a number of seconds (floating point values allowed too). Useful when some routers use rate-limit for ICMP messages.
-e
Show ICMP extensions. The general form is CLASS/TYPE: followed by a hexadecimal dump. The MPLS (Multiprotocol Label Switching) data is shown parsed, in a form: MPLS:L=label,E=exp_use,S=stack_bottom,T=TTL (with any further objects separated by a slash ("/")).
-A
Perform AS path lookups in routing registries and print results directly after the corresponding addresses.
-V
Print version information, and exit.
The following options are intended for an advanced usage (another trace methods etc.):
--sport=port
Chooses the source port to use. Implies -N 1. Normally source ports (if applicable) are chosen by the system.
--fwmark=mark
Set the firewall mark for outgoing packets (since Linux kernel 2.6.25).
-M method
Use specified method for traceroute operations. Default traditional udp method is called default, and icmp (-I) and tcp (-T) have the names icmp and tcp, respectively. Method-specific options can be passed by -O. Most methods have their simple shortcuts (-I means -M icmp, etc).
-O option
Specifies some method-specific option. Several options are separated by comma (or use several -O specifications on the command-line). Each method may have its own specific options, or many not have them at all. To print information about available options, use -O help.
-U
Use UDP to particular destination port for tracerouting (instead of increasing the port per each probe). Default port is 53 (dns).
-UL
Use UDPLITE for tracerouting (default port is 53).
-D
Use DCCP Requests for probes.
-P protocol
Use raw packet of specified protocol for tracerouting. Default protocol is 253, as per rfc3692.
--mtu
Discover MTU along the path being traced. Implies -F -N 1. New mtu is printed once in a form of F=NUM at the first probe of a hop which requires such mtu to be reached. (Actually, the correspond "frag needed" icmp message normally is sent by the previous hop).
Note, that some routers might cache once the seen information on a fragmentation. Thus you can receive the final mtu from a closer hop. Try to specify an unusual tos by -t, this can help for one attempt (then it can be cached there as well). See -F option for more info.
--back
Print the number of backward hops when it seems different with the forward direction. This number is guessed in assumption that remote hops send reply packets with initial ttl set to either 64, 128 or 255 (which is a common practice). It is printed as a negative value in a form of '-NUM' .
List Of Available Methods
In general, a particular traceroute method may have to be chosen by "-M name", but most of the methods have their simple command-line switches (you can see them after the method name, if present).
default
The traditional, ancient method of tracerouting. Used by default.
Probe packets are udp datagrams with so-called "unlikely" destination ports. The "unlikely" port of the first probe is 33434, then for each next probe it is incremented by one. Since the ports are expected to be unused, the destination host normally returns "icmp unreach port" as a final response. (Nobody knows what happens when some application listens for such ports, though).
This method is allowed for unprivileged users.
icmp, -I
The most commonly-used method, which uses icmp echo packets for probes. If you can ping the destination host, icmp tracerouting is applicable as well.
This method may be allowed for unprivileged users since the kernel 3.0 (IPv4 only), which supports new dgram icmp (or "ping") sockets. To allow such sockets, sysadmin should provide net/ipv4/ping_group_range sysctl range to match any group of the user.
Options:
raw
Use only raw sockets (this is the traditional method). This method is tried first by default (for compatibility reasons), then new dgram icmp sockets as fallback.
dgram
Use only dgram icmp sockets.
tcp, -T
Well-known modern method, intended to bypass firewalls. Uses the constant destination port (default is 80, http).
If some filters are present in the network path, then most probably any "unlikely" udp ports (as for default method) or even icmp echoes (as for icmp) are filtered, and whole tracerouting will just stop at such a firewall. To bypass a network filter, we have to use only allowed protocol/port combinations. If we trace for some, say, mailserver, then more likely -T -p 25 can reach it, even when -I cannot.
This method uses well-known "half-open technique", which prevents applications on the destination host from seeing our probes at all. Normally, a tcp syn is sent. For non-listened ports we receive tcp reset, and all is done. For active listening ports we receive tcp syn+ack, but answer by tcp reset (instead of expected tcp ack), this way the remote tcp session is dropped even without the application ever taking notice.
The tcp method may be one of the following:
syn,ack,fin,rst,psh,urg,ece,cwr
Sets specified tcp flags for probe packet, in any combination.
flags=num
Sets the flags field in the tcp header exactly to num.
ecn
Send syn packet with tcp flags ECE and CWR (for Explicit Congestion Notification, rfc3168).
sack,timestamps,window_scaling
Use the corresponding tcp header option in the outgoing probe packet.
sysctl
Use current sysctl (/proc/sys/net/*) setting for the tcp header options above and ecn. Always set by default, if nothing else specified.
mss=num
Use value of num for maxseg tcp header option (when syn).
info
Print tcp flags of final tcp replies when the target host is reached. Allows to determine whether an application listens the port and other useful things.
The default tcp method is syn,sysctl.
tcpconn
An implementation of the tcp method using a simple connect() call, which performs full tcp session opening. Not recommended for normal use, because a destination application is always affected (and can be confused).
udp, -U
Use udp datagram with constant destination port (default 53, dns). Intended to bypass firewall as well.
Note, that unlike in tcp method, the corresponding application on the destination host always receive your probes (with random data), and most can easily be confused by them. In most cases it will not respond to your packets, so you will never see the final hop in the trace. (DNS servers usually reply with something angry, however).
This method is allowed for unprivileged users.
udplite, -UL
Use udplite datagram for probes (with constant destination port, default 53).
This method is allowed for unprivileged users.
Options:
coverage=num
Set udplite send coverage to num.
dccp, -D
Use DCCP Request packets for probes (rfc4340).
This method uses the same "half-open technique" as used for TCP. The default destination port is 33434.
Options:
service=num
Set DCCP service code to num (default is 1885957735).
raw, -Pproto
Send raw packet of protocol proto. No protocol-specific headers are used, just IP header only. Implies -N 1.
Options:
protocol=proto
Use IP protocol proto (default 253).
Notes
To speed up work, normally several probes are sent simultaneously. The downside is that this creates a "storm of packages", especially in the reply direction. Routers can throttle the rate of icmp responses, and some of replies can be lost. To avoid this, decrease the number of simultaneous probes, or even set it to 1 (like in initial traceroute implementation), i.e. -N 1
The final (target) host can drop some of the simultaneous probes, and might even answer only the latest ones. It can lead to extra "looks like expired" hops near the final hop. traceroute uses a smart algorithm to auto-detect such a situation, but if it cannot help in your case, just use -N 1.
For even greater stability you can slow down the program's work with the -z option. For example, use -z 0.5 for a half-second pause between probes.
If some hops report nothing for every method, the last chance to obtain something is to use the ping command with the -R option (IPv4, and for nearest 8 hops only).
traceroute to computerhope.com (166.70.10.23), 30 hops max, 60 byte packets
1 176.221.87.1 (176.221.87.1) 1.474 ms 1.444 ms 1.390 ms
2 f126.broadband2.quicknet.se (92.43.37.126) 10.047 ms 19.868 ms 23.156 ms
3 10.5.12.1 (10.5.12.1) 24.098 ms 24.340 ms 25.311 ms
4 212.247.178.9 (212.247.178.9) 25.777 ms 27.184 ms 27.625 ms
5 vst-ncore-1.bundle-ether1.tele2.net (130.244.39.46) 30.632 ms 31.610 ms 32.194 ms
6 kst5-core-1.bundle-ether6.tele2.net (130.244.71.178) 33.608 ms 15.274 ms 16.449 ms
7 kst5-peer-1.ae0-unit0.tele2.net (130.244.205.125) 252.53 ms 11.169 ms 12.158 ms
8 avk6-peer-1.ae0-unit0.tele2.net (130.244.64.71) 19.661 ms 25.765 ms 26.730 ms
9 peer-as3257.avk6.tele2.net (130.244.200.106) 25.390 ms 24.863 ms xe-5-0-0.nyc30.ip4.tinet.net (89.149.181.109) 23.626 ms
10 fortress-gw.ip4.tinet.net (216.221.158.90) 29.943 ms 31.112 ms 29.002 ms
11 208.116.63.254 (208.116.63.254) 32.102 ms 29.862 ms 29.337 ms
traceroute computerhope.com
Trace the route that packets take between your system and the host named computerhope.com, using the default method (udp datagram, 16 simultaneous probes). The results will look similar to the following output:
traceroute to computerhope.com (166.70.10.23), 30 hops max, 60 byte packets
1 176.221.87.1 (176.221.87.1) 1.474 ms 1.444 ms 1.390 ms
2 f126.broadband2.quicknet.se (92.43.37.126) 10.047 ms 19.868 ms 23.156 ms
3 10.5.12.1 (10.5.12.1) 24.098 ms 24.340 ms 25.311 ms
4 212.247.178.9 (212.247.178.9) 25.777 ms 27.184 ms 27.625 ms
5 vst-ncore-1.bundle-ether1.tele2.net (130.244.39.46) 30.632 ms 31.610 ms 32.194 ms
6 kst5-core-1.bundle-ether6.tele2.net (130.244.71.178) 33.608 ms 15.274 ms 16.449 ms
7 kst5-peer-1.ae0-unit0.tele2.net (130.244.205.125) 252.53 ms 11.169 ms 12.158 ms
8 avk6-peer-1.ae0-unit0.tele2.net (130.244.64.71) 19.661 ms 25.765 ms 26.730 ms
9 peer-as3257.avk6.tele2.net (130.244.200.106) 25.390 ms 24.863 ms xe-5-0-0.nyc30.ip4.tinet.net (89.149.181.109) 23.626 ms
10 fortress-gw.ip4.tinet.net (216.221.158.90) 29.943 ms 31.112 ms 29.002 ms
11 208.116.63.254 (208.116.63.254) 32.102 ms 29.862 ms 29.337 ms
traceroute (顯示數據包到達網絡主機的路由)
在類似Unix的操作系統上，traceroute命令顯示數據包到達網絡主機的路由。 本文檔介紹了Linux版本的traceroute。
On Unix-like operating systems, the traceroute command prints the route that packets take to a network host. This document covers the Linux version of traceroute.
查看英文版
查看中文版
1 traceroute 運行系統環境
2 traceroute 說明
3 traceroute 語法
4 traceroute 例子
traceroute 運行系統環境
Linux
traceroute 說明
互聯網是由網關連接在一起的大型且復雜的網絡硬件集合。跟蹤數據包遵循的路由（或找到丟棄數據包的網關）可能很困難。 traceroute命令利用IP協議的“生存時間”字段，并嘗試從每個網關到某個主機的路徑中引發ICMP TIME_EXCEEDED響應。
唯一必需的參數是目標主機名或IP號。默認的探測數據報長度為40個字節，但是可以通過在目標主機名之后指定一個數據包大小（以字節為單位）來增加長度。
traceroute嘗試通過啟動具有較小ttl（生存時間）的探測數據包，然后偵聽來自網關的ICMP“超時”答復，來跟蹤IP數據包將遵循的路由到某些Internet主機的路由。它以1的ttl開始其探測，并將其增加1，直到獲得ICMP“端口不可達”（或TCP重置），這意味著我們到達了“主機”，或者達到了最大值（默認為30跳）。 。在每個ttl設置中發送三個探針（默認情況下），并打印一行以顯示ttl，網關地址和每個探針的往返時間。要求時，地址后可以有其他信息。如果探測答案來自不同的網關，則將打印每個響應系統的地址。如果在5.0秒內（默認）沒有響應，則為該探針打印一個“ *”（星號）。
在行程時間之后，可以打印一些其他注釋：！H，！N或！P（主機，網絡或協議不可訪問）、! S（源路由失敗）、! F（需要分段）、! X（管理性通信）禁止）、! V（違反主機優先級）、! C（有效優先級截止）或！（ICMP無法訪問代碼）。如果幾乎所有的探測導致某種無法到達的情況，traceroute都會放棄并退出。
您不希望目標主機處理UDP探測數據包，因此目標端口設置為不太可能的值（可以使用-p標志進行更改）。對于ICMP或TCP跟蹤路由，沒有這樣的問題（對于TCP，我們使用半開放技術，這可以防止目標主機上的應用程序看到我們的探針）。
在現代網絡環境中，由于防火墻的廣泛使用，傳統的traceroute方法不能總是適用。這樣的防火墻過濾“不太可能”的UDP端口，甚至ICMP回聲。為了解決這個問題，實現了一些其他的跟蹤方法（包括tcp）。請參閱下面的可用方法列表。此類方法嘗試使用特定的協議和源/目標端口來繞過防火墻（防火墻將其視為允許的網絡會話類型的開始）。
The Internet is a large and complex aggregation of network hardware, connected together by gateways. Tracking the route your packets follow (or finding a gateway that's discarding your packets) can be difficult. The traceroute command utilizes the IP protocol "time to live" field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to some host.
The only mandatory parameter is the destination hostname or IP number. The default probe datagram length is 40 bytes, but this may be increased by specifying a packet size (in bytes) after the destination hostname.
traceroute attempts to trace the route an IP packet would follow to some Internet host by launching probe packets with a small ttl (time to live) then listening for an ICMP "time exceeded" reply from a gateway. It start its probes with a ttl of one and increases this by one until it gets an ICMP "port unreachable" (or TCP reset), which means we got to the "host", or hit a max (which defaults to 30 hops). Three probes (by default) are sent at each ttl setting and a line is printed showing the ttl, address of the gateway and round trip time of each probe. The address can be followed by additional information when requested. If the probe answers come from different gateways, the address of each responding system will be printed. If there is no response within a 5.0 seconds (default), an "*" (asterisk) is printed for that probe.
After the trip time, some additional annotation can be printed: !H, !N, or !P (host, network or protocol unreachable), !S (source route failed), !F (fragmentation needed), !X (communication administratively prohibited), !V (host precedence violation), !C (precedence cutoff in effect), or !<num> (ICMP unreachable code <num>). If almost all the probes result in some kind of unreachable, traceroute gives up and exit.
You don't want the destination host to process the UDP probe packets, so the destination port is set to an unlikely value (you can change it with the -p flag). There is no such a problem for ICMP or TCP tracerouting (for TCP we use half-open technique, which prevents our probes to be seen by applications on the destination host).
In the modern network environment the traditional traceroute methods can not be always applicable, because of widespread use of firewalls. Such firewalls filter the "unlikely" UDP ports, or even ICMP echoes. To solve this, some additional tracerouting methods are implemented (including tcp); see LIST OF AVAILABLE METHODS below. Such methods try to use particular protocol and source/destination port, to bypass firewalls (to be seen by firewalls just as a start of allowed type of a network session).
查看英文版
查看中文版
traceroute 語法
traceroute [-46dFITUnreAV] [-f first_ttl] [-g gate,...] [-i device] [-m max_ttl] [-p port] [-s src_addr] [-q nqueries] [-N squeries] [-t tos] [-l flow_label] [-w waittime] [-z sendwait] [-UL] [-D] [-P proto] [--sport=port] [-M method] [-O mod_options] [--mtu] [--back] host [packet_len]選件
通過packet_len 命令行參數更改探測數據包的大小，您可以手動獲取有關各個網絡躍點的MTU的信息。該--mtu選項（見下文）會嘗試自動執行此操作。
請注意，僅從 Linux內核2.6.22開始，非碎片化功能（例如-F或--mtu）才能正常工作。在該版本之前，IPv6始終是零散的，IPv4只能使用一次（從路由緩存中）發現的最終mtu ，它可能小于設備的實際mtu。
以下選項旨在用于高級用途（其他跟蹤方法等）：
沿著被跟蹤的路徑發現MTU。表示-F -N 1。新的mtu在需要達到此mtu的躍點的第一個探針處以F = NUM的形式打印一次。（實際上，通常是由前一跳發送相應的“ frag needed” icmp消息）。
請注意，某些路由器可能會緩存可見的碎片信息。因此，您可以從更近的躍點接收最終的mtu。嘗試通過-t指定不尋常的tos ，這可以幫助進行一次嘗試（然后也可以將其緩存在該位置）。有關更多信息，請參見-F選項。
可用方法列表
通常，可能必須通過“ -M name ” 來選擇特定的traceroute方法，但是大多數方法都有其簡單的命令行開關（如果存在，您可以在方法名之后看到它們）。
探測數據包是帶有所謂“不太可能”目標端口的udp數據報。第一個探針的“不太可能”端口為33434，然后對于每個下一個探針將其遞增1。由于期望端口未使用，因此目標主機通常會返回“ icmp unreach port”作為最終響應。（不過，沒人知道當某些應用程序偵聽此類端口時會發生什么）。
非特權用戶可以使用此方法。
由于內核3.0（僅IPv4）支持新的dgram icmp（或“ ping”）套接字，因此非特權用戶可以使用此方法。要允許此類套接字，sysadmin應該提供net / ipv4 / ping_group_range sysctl范圍以匹配任何用戶組。
選項：
如果網絡路徑中存在一些過濾器，則很可能過濾所有“不太可能”的udp端口（對于默認方法）甚至icmp回聲（對于icmp），并且整個跟蹤路由都將在這種防火墻處停止。要繞過網絡過濾器，我們只能使用允許的協議/端口組合。如果我們跟蹤某些郵件服務器，那么-T -p 25更有可能到達它，即使-I也不能。
此方法使用眾所周知的“半開放式技術”，這完全阻止了目標主機上的應用程序看到我們的探針。通常情況下，tcp syn已發送。對于未監聽的端口，我們會收到tcp reset，所有操作都已完成。對于活動的偵聽端口，我們會收到tcp syn + ack，但通過tcp重置（而不是預期的tcp ack）進行應答，這樣即使沒有通知應用程序，也將丟棄遠程tcp會話。
tcp方法可能是以下之一：
請注意，與tcp方法不同，目標主機上的相應應用程序始終會接收您的探針（帶有隨機數據），并且大多數探針很容易將它們混淆。在大多數情況下，它不會響應您的數據包，因此您將永遠不會在跟蹤中看到最后一跳。（但是，DNS服務器通常會發出一些憤怒的回復）。
非特權用戶可以使用此方法。
將udplite數據報用于探針（具有恒定的目標端口，默認值為 53）。
非特權用戶可以使用此方法。
選項：
將DCCP請求數據包用于探針（rfc4340）。
此方法使用與TCP相同的“半開放技術”。默認目標端口為33434。
選項：
發送原始協議原始數據包。不使用特定于協議的標頭，僅使用IP標頭。表示-N 1。
選項：
筆記
為了加快工作速度，通常會同時發送多個探針。不利的一面是，這會造成“打包風暴”，尤其是在回復方向上。路由器可以限制icmp響應的速率，并且某些回復可能會丟失。為了避免這種情況，請減少同時探測的數量，甚至將其設置為1（如在初始traceroute實施中一樣），即-N 1
最終（目標）主機可以丟棄某些同時進行的探測，甚至可能僅回答最新的探測。這可能會導致在最終躍點附近產生額外的“看起來已過期”躍點。traceroute使用一種智能算法來自動檢測這種情況，但是，如果無法解決您的問題，請使用-N 1。
為了獲得更大的穩定性，您可以使用-z選項降低程序的工作速度。例如，使用-z 0.5在兩次探查之間暫停半秒。
如果某些躍點對每種方法都沒有報告任何結果，那么獲得某些結果的最后機會是將ping命令與-R選項一起使用（IPv4，并且僅用于最近的8個躍點）。
traceroute [-46dFITUnreAV] [-f first_ttl] [-g gate,...] [-i device] [-m max_ttl] [-p port] [-s src_addr] [-q nqueries] [-N squeries] [-t tos] [-l flow_label] [-w waittime] [-z sendwait] [-UL] [-D] [-P proto] [--sport=port] [-M method] [-O mod_options] [--mtu] [--back] host [packet_len]Options
Varying the size of the probing packet by the packet_len command-line parameter, you can manually obtain information about the MTU of individual network hops. The --mtu option (see below) tries to do this automatically.
Note, that non-fragmented features (like -F or --mtu) work properly since the Linux kernel 2.6.22 only. Before that version, IPv6 was always fragmented, IPv4 could use the once the discovered final mtu only (from the route cache), which can be less than the actual mtu of a device.
The following options are intended for an advanced usage (another trace methods etc.):
Discover MTU along the path being traced. Implies -F -N 1. New mtu is printed once in a form of F=NUM at the first probe of a hop which requires such mtu to be reached. (Actually, the correspond "frag needed" icmp message normally is sent by the previous hop).
Note, that some routers might cache once the seen information on a fragmentation. Thus you can receive the final mtu from a closer hop. Try to specify an unusual tos by -t, this can help for one attempt (then it can be cached there as well). See -F option for more info.
List Of Available Methods
In general, a particular traceroute method may have to be chosen by "-M name", but most of the methods have their simple command-line switches (you can see them after the method name, if present).
Probe packets are udp datagrams with so-called "unlikely" destination ports. The "unlikely" port of the first probe is 33434, then for each next probe it is incremented by one. Since the ports are expected to be unused, the destination host normally returns "icmp unreach port" as a final response. (Nobody knows what happens when some application listens for such ports, though).
This method is allowed for unprivileged users.
This method may be allowed for unprivileged users since the kernel 3.0 (IPv4 only), which supports new dgram icmp (or "ping") sockets. To allow such sockets, sysadmin should provide net/ipv4/ping_group_range sysctl range to match any group of the user.
Options:
If some filters are present in the network path, then most probably any "unlikely" udp ports (as for default method) or even icmp echoes (as for icmp) are filtered, and whole tracerouting will just stop at such a firewall. To bypass a network filter, we have to use only allowed protocol/port combinations. If we trace for some, say, mailserver, then more likely -T -p 25 can reach it, even when -I cannot.
This method uses well-known "half-open technique", which prevents applications on the destination host from seeing our probes at all. Normally, a tcp syn is sent. For non-listened ports we receive tcp reset, and all is done. For active listening ports we receive tcp syn+ack, but answer by tcp reset (instead of expected tcp ack), this way the remote tcp session is dropped even without the application ever taking notice.
The tcp method may be one of the following:
Note, that unlike in tcp method, the corresponding application on the destination host always receive your probes (with random data), and most can easily be confused by them. In most cases it will not respond to your packets, so you will never see the final hop in the trace. (DNS servers usually reply with something angry, however).
This method is allowed for unprivileged users.
Use udplite datagram for probes (with constant destination port, default 53).
This method is allowed for unprivileged users.
Options:
Use DCCP Request packets for probes (rfc4340).
This method uses the same "half-open technique" as used for TCP. The default destination port is 33434.
Options:
Send raw packet of protocol proto. No protocol-specific headers are used, just IP header only. Implies -N 1.
Options:
Notes
To speed up work, normally several probes are sent simultaneously. The downside is that this creates a "storm of packages", especially in the reply direction. Routers can throttle the rate of icmp responses, and some of replies can be lost. To avoid this, decrease the number of simultaneous probes, or even set it to 1 (like in initial traceroute implementation), i.e. -N 1
The final (target) host can drop some of the simultaneous probes, and might even answer only the latest ones. It can lead to extra "looks like expired" hops near the final hop. traceroute uses a smart algorithm to auto-detect such a situation, but if it cannot help in your case, just use -N 1.
For even greater stability you can slow down the program's work with the -z option. For example, use -z 0.5 for a half-second pause between probes.
If some hops report nothing for every method, the last chance to obtain something is to use the ping command with the -R option (IPv4, and for nearest 8 hops only).
查看英文版
查看中文版
traceroute 例子
使用默認方法（udp數據報，16個同時探測），跟蹤數據包在系統與名為computerhope.com的主機之間采取的路由。結果將類似于以下輸出：
Trace the route that packets take between your system and the host named computerhope.com, using the default method (udp datagram, 16 simultaneous probes). The results will look similar to the following output:
查看英文版
查看中文版
其他命令行
tabs | tac | talk | tail | tcopy | tty | tar | tbl | tcpdump | tcsh | time | tee | timex | telinit | telnet | test | top | touch | tput | tr | troff |