Traceroute手册翻译+特殊案例分析

TRACEROUTE 手册翻译

简介

 traceroute -- 打印网络数据包到网络主机的路由信息

格式

 traceroute [-adeFISdNnrvx] [-A as_server] [-f first_ttl] [-g gateway] [-i iface] [-M first_ttl] [-m max_ttl] [-P proto] [-p port] [-q nqueries] [-s src_addr] [-t tos] [-w waittime]
            [-z pausemsecs] host [packetsize]

详细描述

• 互联网是一个庞大而复杂的网络硬件聚合体，通过网关连接在一起。跟踪单个数据包的路由路径（或找到那些丢弃你的数据包的恶意网关）可能很困难。所以traceroute利用IP协议“生存时间TTL”信息，尝试从每个网关沿着到某个主机的路径引出"ICMP TIME_EXCEEDED响应"和具体路径。

• 唯一必需的参数是目标主机名或IP号。默认探测数据报长度为40个字节，但可以通过在目标主机名之后指定数据包大小（以字节为单位）来增加此值。

详细参数说明

    -a      为每一个跳跃节点开启AS#查询
    -A as_server    
            打开AS＃查找并使用给定的服务器而不是默认服务器。
    -d      启用socket调试
    -D      当收到对我们的探测数据报的ICMP响应时，打印发送的数据包与ICMP响应引用的数据包之间的差异。打印一个显示传输数据包中字段位置的键，然后是十六进制的原始数据包，接着是十六进制的引用数据包。引用数据包中未更改的字节显示为下划线。注意，IP校验和和引用数据包的TTL预计不匹配。默认情况下，此选项仅发送每跳一个探测。
    -e      防火墙逃避模式。使用固定目标端口进行UDP和TCP探测。
    -f first_ttl
            设置第一个传出探测包中使用的初始生存时间。
    -F      设置“不分段”比特。
    -g gateway
            指定松散的源路由网关（最多8个）。
    -i iface
            指定网络接口以获取传出探测包的源IP地址。这通常仅适用于多宿主主机。（有关执行此操作的其他方法，请参阅-s参数。）
    -I      使用ICMP ECHO而不是UDP数据报。（等同于"-P icmp"）
    -M first_ttl
            设置传出探测包中使用的初始生存时间值。默认值为1，即从第一跳开始。
    -m max_ttl
            设置传出探测包中使用的最大生存时间（最大跳数）。默认值为net.inet.ip.ttl hops（与TCP连接相同的默认值）。
    -n      以数字方式而不是符号和数字方式打印跳跃地址（为路径上找到的每个网关保存名称服务器地址到名称查找）。
    -P proto
            发送指定IP协议的数据包。当前支持的协议是：UDP，TCP，GRE和ICMP其他协议也可以指定（通过名称或编号），但traceroute不会实现其数据包格式的任何特殊知识。此选项对于确定路径中的哪个路由器可能会根据IP协议号阻止数据包很有用。但请参阅下面的BUGS。
    -p port
            特定协议。对于UDP和TCP，设置探针中使用的基本端口号（默认为33434）。 traceroute希望没有任何东西在UDP端口上监听目标主机上的base + nhops-1（因此将返回ICMP PORT_UNREACHABLE消息以终止路由跟踪）。如果某些内容正在侦听默认范围内的端口，则此选项可用于选择未使用的端口范围。
    -q nqueries
            将每个“ttl”的探测次数设置为nqueries（默认为三个探测器）。
    -r      绕过正常的路由表并直接发送到连接网络上的主机。如果主机不在直接连接的网络上，则会返回错误。此选项可用于通过没有路由的接口ping本地主机（例如，在路由被路由（8）丢弃之后）
    -s src_addr
            使用src_addr（必须以IP号码，而不是主机名）作为传出探测数据包中的源地址。在具有多个IP地址的主机上，此选项可用于强制源地址不是发送探测数据包的接口的IP地址。如果IP地址不是本机的接口地址之一，则返回错误并且不发送任何内容。 （有关其他方法，请参阅-i标志。）
    -S      打印每个跃点未应答的丢包率。
    -t tos  将探测包中的服务类型设置为以下值（默认为零）。 该值必须是0到255范围内的十进制整数。此选项可用于查看不同类型的服务是否会产生不同的路径。 （如果您没有运行4.4BSD或更高版本的系统，这可能是学术性的，因为正常的网络服务，如telnet和ftp不允许您控制TOS）。 并非所有TOS值都是合法或有意义的 - 请参阅IP规范以了解定义。 有用的值可能是`-t 16'（低延迟）和`-t 8'（高吞吐量）。
    -v      详细输出。 列出了除TIME_EXCEEDED和UNREACHABLE之外的已接收ICMP数据包。
    -w      设置等待探测响应的时间（以秒为单位）（默认为5秒）。
    -x      切换IP校验和。 通常，这会阻止traceroute计算IP校验和。 在某些情况下，操作系统可以覆盖部分传出数据包，但不会重新计算校验和（因此在某些情况下，默认情况下不计算校验和，使用-x会导致计算校验和）。 请注意，使用ICMP ECHO探测器（-I）时，最后一跳通常需要校验和。 所以在使用ICMP时总会计算出它们。
    -z pausemsecs
            设置探针之间暂停的时间（以毫秒为单位）（默认为0）。 某些系统（如Solaris）和路由器（如Ciscos）限制ICMP消息。 与此一起使用的推荐值是500（例如1/2秒）。

该程序试图通过启动具有比较小的小ttl（生存时间）的UDP探测包，然后侦听来自网关的ICMP超时信息回复来跟踪IP包在某一个特定因特网内的路由信息。我们用一个ttl开始我们的探测并每一跳都+1，直到我们得到一个ICMP信息端口无法访问（这意味着我们到达主机）或达到最大值（默认为net.inet.ip.ttl，当然这个值可以用-m标志改变）。在每个ttl设置发送三个探针（可以用-q标志更改），并打印一行显示ttl+IP地址+每个探测的网关和往返时间的信息。如果探测答案来自不同的网关，则将打印每个响应系统的地址。如果在5秒内没有响应。超时间隔（使用-w标志更改），为该探测器打印*。

通常我们不希望目标主机处理UDP探测数据包，所以traceroute会把目标端口设置为一个不太可能在用的端口值（如果目标上的某些clod使用该值，则可用-p标志改变）。

一个可能的示例使用和输出：

 [yak 71]% traceroute nis.nsf.net.
 traceroute to nis.nsf.net (35.1.1.48), 64 hops max, 38 byte packet
 1  helios.ee.lbl.gov (128.3.112.1)  19 ms  19 ms  0 ms
 2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  39 ms
 5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  39 ms  39 ms  39 ms
 6  128.32.197.4 (128.32.197.4)  40 ms  59 ms  59 ms
 7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  59 ms
 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.3 BSD的分布式版本中的错误）。所以要注意，您必须猜测数据包通过了哪些路径，因为NSFNet（129.140）不为其NSS提供地址到名称的转换。

下面是一个更有意思的案例:

 [yak 72]% traceroute allspice.lcs.mit.edu.
 traceroute to allspice.lcs.mit.edu (18.26.0.115), 64 hops max
 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)  20 ms  39 ms  39 ms
 6  128.32.197.4 (128.32.197.4)  59 ms  119 ms  39 ms
 7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  39 ms
 8  129.140.70.13 (129.140.70.13)  80 ms  79 ms  99 ms
 9  129.140.71.6 (129.140.71.6)  139 ms  139 ms  159 ms
 10  129.140.81.7 (129.140.81.7)  199 ms  180 ms  300 ms
 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 ms  279 ms  279 ms

请注意，网关12,14,15,16和17跳要么不发送ICMP超时消息，要么发送它们的ttl太小而无法返回到用户主机。 14-17正在运行MIT C Gate-way代码。鬼知道12跳发生了啥。

上面的静音网关12可能是4中的错误的结果。因为，对于网关，剩余的ttl为零的时候，ICMP超时信息必然不会返回给我们。 当它出现在目标系统上时，此错误的行为会更有趣：

 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)  39 ms  59 ms  39 ms
 7  * * *
 8  * * *
 9  * * *
 10  * * *
 11  * * *
 12  * * *
 13  rip.Berkeley.EDU (128.32.131.22)  59 ms !  39 ms !  39 ms !

请注意，有12个“网关”（13个是最终目的地），并且它们的后半部分完全“丢失”。真正原因的是rip（运行SunOS3.5的Sun-3）正在使用我们到达的数据报中的ttl作为其ICMP回复中的ttl。因此，回复将在返回路径上超时（由于未发送ICMP，因此未向任何人发送通知ICMP），除非我们使用至少两倍路径长度的ttl进行探测。 即，rip实际上只有7跳。 以ttl为1的返回信息是分析这个问题的线索。

traceroute在ttl <= 1之后会打出"!"。由于供应商提供了大量过时的（DEC的Ultrix，Sun 3.x）或非标准（HPUX）软件，如果不妥善选择探针主机则会经常看到这种问题。

原作者

由Van Jacobson先生在Steve Deering先生的提一下进行撰写。 并且由上千位开发者提出修改意见，特别是来自C. Philip Wood，Tim Seaver和Ken Adelman的修改意见。