traceroute 命令

在线编辑

traceroute 命令可以用来做网络测试、测量和管理。

虽然 ping 命令可以验证是否能够到达 IP 网络，但您不能够对一些单独的问题进行精确定位和改善。 请考虑下面的情况：

  • 如果在您的主机和目标地址之间有很多转发单元（比如，网关或是路由），而且在沿路径的某处好像有问题存在。 目标系统可能有问题，但是您需要知道信息包实际上在哪儿丢失的。
  • ping 命令会终止，但不会告诉您信息包丢失的缘由。
traceroute 命令可以告诉您信息包的位置，也能告诉您为什么路由会丢失。 如果您的信息包必须通过路由器和链接，而这些都是属于其他组织或是公司并且由它们来管理，那么要通过 telnet 命令来检查相关的路由器就很困难。 traceroute 命令为 ping 命令提供了一个追加功能。
注: traceroute 命令应主要用于手动故障隔离。 由于它对网络施加了负载，所以在标准的操作或是自动运行的脚本下不要使用 traceroute 命令。

成功的 traceroute 示例

traceroute 命令使用 UDP 信息包和 ICMP 错误通报功能。 它发送 3 次 UDP 信息包，发送到路径上的每一个网关或路由器上。 它从最近的网关开始启动，通过转发扩展搜索。 最后，搜索到了目标系统。 在输出中，您可以看到网关名称、网关的 IP 地址和网关 3 次往返的时间。 请参阅以下示例：
# traceroute aix1
trying to get source for aix1
source should be 10.53.155.187
traceroute to aix1.austin.ibm.com (10.53.153.120) from 10.53.155.187 (10.53.155.187), 30 hops max
outgoing MTU = 1500
 1  10.111.154.1 (10.111.154.1)  5 ms  3 ms  2 ms
 2  aix1 (10.53.153.120)  5 ms  5 ms  5 ms
下面是另一个示例：
# traceroute aix1
trying to get source for aix1
source should be 10.53.155.187
traceroute to aix1.austin.ibm.com (10.53.153.120) from 10.53.155.187 (10.53.155.187), 30 hops max
outgoing MTU = 1500
 1  10.111.154.1 (10.111.154.1)  10 ms  2 ms  3 ms
 2  aix1 (10.53.153.120)  8 ms  7 ms  5 ms

地址解析协议 (ARP) 登录终止后，依然重复同样的命令。 注意，发送到每个网关或是目标地址的第一个信息包需要较长的回返时间。 这是因为 ARP 造成的时间开销。 如果在路径中 有公共交换网络 (WAN)，第一个信息包就会因为创建连接消耗很多的内存，可能会导致超时。 每个信息包缺省的超时为 3 秒。 您可以通过 -w 参数项来改变其值。

第一个 10 ms 是因为在源系统 (9.53.155.187) 和网关 9.111.154.1 之间的 ARP 造成的。 第二个 8 ms 是因为网关和最终目标（波）之间的 ARP 造成的。 这种情况下，您使用 DNS，而且每次都在 traceroute 命令之前发送一个信息包，就可以搜索到 DNS 服务器。

失败的 traceroute 示例

如果距您的目标地址有很长的距离或者是网络路由很复杂，那么您或许可以通过 traceroute 命令查看出很多问题。 因为很多事情都是依赖于具体实现的， 所以搜索问题可能只是浪费您的时间。 如果涉及到的所有路由器或子系统都在您的控制范围内，您或许可以完整的调查这个问题。

网关（路由器）问题

在下面的示例中，信息包从系统 9.53.155.187 中发出。 在链接到网桥的路径上有两个路由器系统。 通过将 no 命令的 ip转发 选项设置为 0 ，有意从第二个路由器系统中除去了路由功能。 请参阅以下示例：
# traceroute lamar
trying to get source for lamar
source should be 9.53.155.187
traceroute to lamar.austin.ibm.com (9.3.200.141) from 9.53.155.187 (9.53.155.187), 30 hops max
outgoing MTU = 1500
 1  9.111.154.1 (9.111.154.1)  12 ms  3 ms  2 ms
 2  9.111.154.1 (9.111.154.1)  3 ms !H *  6 ms !H

如果 ICMP 错误消息，排除Time Exceeded和Port Unreachable，已接收，显示如下:

!H
不能到达的主机
!N
不能到达的网络
!P
不能到达的协议
!S
源路由失效
!F
需要分段

目标系统问题

如果目标系统在 3 秒的超时间隔内没有响应，所有的查询都会发生超时，结果会采用星号（*）显示。
# traceroute chuys
trying to get source for chuys
source should be 9.53.155.187
traceroute to chuys.austin.ibm.com (9.53.155.188) from 9.53.155.187 (9.53.155.187), 30 hops max
outgoing MTU = 1500
 1  * * *
 2  * * *
 3  * * *
^C#

如果您认为这个问题是由于通信链路所造成的，可以使用 -w 标记来延长超时等待时间。 可能会使用所有的查询端口，虽然这种情况很少见。 您可以更改端口，然后重试。

到目标地址的中继段的数目

另一个输出文件可能如下所示：
# traceroute mysystem.university.edu (129.2.130.22)
traceroute to mysystem.university.edu (129.2.130.22), 30 hops max
1 helios.ee.lbl.gov (129.3.112.1) 0 ms 0 ms 0 ms
2 lilac-dmc.university.edu (129.2.216.1) 39 ms 19 ms 39 ms
3 lilac-dmc.university.edu (129.2.215.1) 19 ms 39 ms 19 ms
4 ccngw-ner-cc.university.edu (129.2.135.23) 39 ms 40 ms 19 ms
5 ccn-nerif35.university.edu (129.2.167.35) 39 ms 39 ms 39 ms
6 csgw/university.edu (129.2.132.254) 39 ms 59 ms 39 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 rip.university.EDU (129.2.130.22) 59 ms! 39 ms! 39 ms!