解释Traceroute命令

当试图诊断与其他网络上的主机的连接问题时，Traceroute是一个非常宝贵的工具。然而，为了有效地使用它，你必须了解它是如何工作的，以及输出意味着什么。

Traceroute通过操纵IP头中的Time-To-Live（TTL）值来工作（图1）。由于我必须使用Stratus 内部网络来做我的例子，我已经在数据包跟踪中X'ed出了IP地址的十六进制表示法，并将所有的八位数在任何带点的十进制符号中翻译成一个独特的字母代码A到W。即AAA代表3位数，而J代表1位数。

图1 - TTL高亮的packet_monitor帧

每一个处理数据包的路由器都会将TTL值递减1，如果TTL值大于0，将把数据包传给下一个路由器或最终目的地。如果TTL值为0，路由器将丢弃该数据包，并*may*向发送方发送ICMP超时消息。关键是*may*，有些路由器不会发超时消息回去，或者只有在不忙的时候才会发。此外，一些防火墙会阻止ICMP消息，所以即使路由器发送了超时消息，运行traceroute的主机也可能永远看不到。

Traceroute从向目标目的地发送TTL值为1的消息开始，它乘以从发送消息到得到响应所需的时间。

图2 - packet_monitor跟踪路由帧和响应

默认情况下，traceroute命令会发送三条TTL为1的消息，并报告这三次消息和发送回复的路由器的名称和或IP地址。我总是使用-numeric参数，这样我就不必等待名称解析（图3）。然后Traceroute将TTL递增1，再做一次。它将继续递增 TTL，直到收到目标目的地的响应，或者达到某个限制，30（默认）。你可以在OpenVOS STREAMS TCP/IP Administrator's Guide (R419 )手册中找到所有traceroute参数的文档。

图3 - 跟踪路由输出

你会期望随着TTL的增加，时间会增加，一般情况下是这样，但并不总是这样，比较图3中跳6（79毫秒）和跳5（80毫秒）的第三次报告时间。这有几个原因。第一，网络不是确定的，有时只是需要更长的时间。其次，跳N-1的路由器可能比跳N的路由器更忙，需要更长的时间来发送ICMP消息。最后，路由器N的返回路径可能比路由器N-1的返回路径更快。例如不要求第4个路由器通过路由器3、2和1把响应送回源头，它可以直接把响应送到路由器1，这样可能会快很多。这意味着，虽然traceroute很擅长报告数据包从发送主机到目标主机的路径，但你不能依赖从目标主机到发送主机的数据包只走相同的反向路径。这就是所谓的不对称路由。

Traceroute可以在时间上附加一个标志，表示它收到的不是预期时间超出的消息。这些标志是：

!H - 主机无法连接
!N - 网络无法连接
!"P"-------------------------------协议无法到达

例如，图4显示，第一个路由器不知道如何到达目标网络，所以它返回一个网络不可到达的消息，traceroute在此时终止。

图4 网络无法到达的消息

用星号（*）代替时间表示traceroute没有收到回复。正如我上面所说的，可能是路由器没有发送ICMP超时报文，也可能是防火墙在回程中拦截了超时报文，或者是防火墙拦截了出站报文。也有可能是网络刚刚丢弃了发出的消息或返回的消息。

在一跳上出现一次甚至两次超时(图5)，很可能说明路由器因为忙而没有发送消息，或者是网络在丢包(或者两者都有)。注意图5中的第8个跳，IP地址前的星号表示该组中的第一个报文超时了。

图5 - 繁忙的路由器或丢弃的数据包

如果三条消息都超时了，但后续的跳数却报告了时间（图6），很可能是该跳的路由器只是没有发送ICMP超时消息。

图6--无响应的路由器

如果所有的跳转都超过了某个点的超时时间（图7），很可能是有防火墙阻挡了发信或回信。

图7 - 防火墙阻挡

还有一个原因是，一切过了一定时间就会超时。那就是当目标没有反应的时候。并不是所有的目标都会有响应，当这种情况发生时，你就会出现图8这样的情况。图7和图8的区别是，在图8中，最后一个发送响应的路由器是目标本地的路由器。如何判断是这种情况呢？有时候从地址上就可以看出，比如目标是192.168.1.12，192.168.1.1是最后一个响应的路由器。在图9中就不太明显，EEE.FFF.W.XXX可能是EEE.FFF.GGG.HHH之前的最后一个路由器，他们确实有前16位的共同点。但是在不知道目标网络使用的子网方案的情况下，不问清楚是无法确定的。

图8 -- -- 未答复的目标

也有可能在同一跳得到两个或多个路由器的响应（图9）。如果路由器是负载均衡的，或者网络不稳定，路由在变化，或者像图9的情况一样，路由器AAA.BBB.CC.KK不是最优的路由器，在将数据包转发到AAA.BBB.II.J后，它发了一个重定向消息回源头，改变了它的路由表，就会出现这种情况。

图9--同一跳的两种反应

有两种类型的traceroute命令，根据它们发送的消息类型来区分。有些traceroutes，比如在Microsoft Windows系统上发现的traceroutes发送ICMP回声请求（ping）消息；其他的traceroutes，比如在STCP下运行的traceroutes发送UDP消息。如果你需要配置防火墙让数据包通过或编写协议分析器过滤器，知道你使用的是哪种类型的traceroute是很重要的。另外，目标的响应也会不同。如果目标收到ping请求，它会发回ping回复；如果收到UDP消息，那么响应取决于端口号。如果端口在使用中，监听的应用程序多半会丢弃这个数据包，因为它不符合应用程序的消息结构要求。如果端口不在使用中，主机*可能会发送一个ICMP目的端口不可达的消息回来。为此traceroute会选择通常不使用的端口。

目标主机看到的端口号取决于到达目标主机所需的跳数。Traceroute 将目标端口设置为 33435（默认情况下），并为每条消息递增端口号（图 10）。因此，目标看到的是3个不同的端口，有可能不是所有的三个端口都在使用。源端口是根据发送进程的进程ID来确定的。一个给定的进程总是使用同一个源端口。

最后, 除非有一个问题，在第一跳可能没有很多你要能够做的修复问题.一旦STCP (或任何主机的网络堆栈) 发送一个数据包到本地路由器，它是出了它的 (和你) 手。然而，如果你知道最后一跳响应的IP地址，或者是突然开始出现超时的那一跳，你就会知道问题出在哪里，并可以联系正确的网络管理员组来解决它。