traceroute - 打印路由数据包到网络主机
概要
traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g 网关 ]
[ -i iface ] [ -m max_ttl] [ -p port ]
[ -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）