Traceroute 就像ping命令一样,可以帮助我们排查网络故障,但ping 有时候会有局限性,例如下面192.168.1.1 ping 不通192.168.3.1,但我们不知道问题是否在 H1-R1、R1-R2、R2-R3 或 R3-S1 之间。假设你知道有多少台路由器以及每台设备的IP 地址,那么你可以逐跳去ping测试,但对于一个大型网络在你不知道中间设备以及流量路径的情况下,你可能会需要使用traceroute来快速判断问题点在哪。
那么,traceroute 是如何工作的呢?
Traceroute 使用 IP 数据包头中的 TTL(生存时间)字段。通常TTL 用于在存在路由环路时能够防止数据包永远无休止的转发下去,每当路由器转发 IP 数据包时,TTL 减 1,当TTL 为零时,IP 数据包将被丢弃。
traceroute是如何工作的请看下面案例,假设从 (192.168.1.1) 向 S1 (192.168.3.1) 发送跟踪,H1 发送的第一个 IP 数据包的 TTL 为 1;
当 R1 收到此 IP 数据包时,它想要将其转发给 R2,但它必须将 TTL 从 1 减少到 0,结果IP 数据包将被丢弃,R1 将使用TTL 超出消息响应 H1,H现在将发送第二个包其TTL为 2;
R1 会将 TTL 从 2 减少到 1,转发它到R2,现在 R2 必须丢弃它,R2 将回复一个 TTL超时消息。H1现在将发送另一个 TTL 为 3 的 IP 数据包;
R1将TTL从3减少到 2,R2将其从 2 减少到1,R3将不得不丢它,R3将TTL 超时消息发送给 H1,紧接着H1 将发送的最后一个 IP 数据包其 TTL 为 4;
每个路由器都会将 TTL 减 1,另一端的服务器S1将收到一个 TTL 为 1 的 IP 数据包,并以ICMP 协议回复 H1。现在我们知道目的地是可达的,并且了解了路径上所经过的设备。
traceroute发送的每个 IP 数据包都称为一个probe。Traceroute 可用于 ICMP、UDP 和 TCP,具体取决于其操作系统类型。
Traceroute的wireshark报文分析:
上面有两台主机,H1 是 Windows 计算机(192.168.1.1),H2 是Linux 计算机(192.168.1.2)
如下为windows系统的traceroute:
C:\Users\vmware>tracert 192.168.3.1
Tracing route to 192.168.3.1 over a maximum of 30 hops
1 1 ms 1 ms <1 ms 192.168.1.254
2 1 ms 1 ms 1 ms 192.168.12.2
3 1 ms 1 ms 1 ms 192.168.23.3
4 1 ms <1 ms <1 ms 192.168.3.1
Trace complete.
通过上面的输出我们可以看到所有的路由器,对于每一跳,traceroute 将发送三个 IP 数据包,这样是为了获得每跳的往返时间的平均值,让我们看看 Wireshark 中的 IP 数据包是什么样的,这是第一个包;
上面我们看到第一个 TTL 为 1 的 IP 数据包,我们可以看到这是一个ICMP请求,当 R1 收到这个 IP 数据包时,它会这样回应:
上面我们看到 R1 用 TTL 超时消息响应 H1,在抓包文件中,你会看到上面的两个数据包发了三次。我们看下一个IP包:
这一次TTL 值为2,将发往R2;
第三个包TTL 值为3;
R3 回复TTL 超时消息
最后,H1 将发送一个TTL值为4 的IP 数据包;
这个最后一个包发往S1,并可以看到ICMP reply报文:
这就是 traceroute 在 Windows 上的工作方式,下面看traceroute在Linux上面的工作方式。
Linux 上的 traceroute 命令的工作方式与 Windows 类似。一个重要的区别是它不使用 ICMP,而是使用 UDP。它还允许您指定要发送的 IP 数据包(探测)的数量。为了便于观看wireshak,仅配置发送一次探测;
$ traceroute -N 1 -q 1 192.168.3.1
traceroute to 192.168.3.1 (192.168.3.1), 30 hops max, 60 byte packets
1 192.168.1.254 (192.168.1.254) 1.202 ms
2 192.168.12.2 (192.168.12.2) 1.122 ms
3 192.168.23.3 (192.168.23.3) 1.192 ms
4 192.168.3.1 (192.168.3.1) 1.886 ms
下面是这个 traceroute 在 Wireshark 中的样子
上面我们可以看到 H2 正在发送 UDP 数据包而不是 ICMP 请求,如下是第一个报文:
上面我们看到 H2 发送的第一个 TTL 为 1 的 IP 数据包,我们看到它使用的是UDP,目的端口号是33434,R1回复如下信息:
由于 TTL 为零,R1 将其丢弃并回复 TTL 超时消息,如下第二个TTL为2的数据包;
上面的数据包与第一个相同,只是可以看到目标端口号从 33434 增加到 33435,R2 将会继续丢弃:
TTL 为 3 的数据包:
上面你可以看到目标端口号从 33435 增加到 33436,R3 会继续丢弃此报文:
最后一个数据包的 TTL 为 4,目的端口号为 33437:
这个包将一直传送到S1,由于 S1 没有监听这些 UDP 端口号中的任何一个,它会回复目标/端口不可达:
这里告诉 H2 我们已经到达目的地了
思科IOS
我们还可以在 Cisco IOS 上使用 traceroute 命令。与 Linux 一样,Cisco 使用 UDP 进行跟踪路由。从 R1 到 S1 进行跟踪,使用单个探针:
R1#traceroute 192.168.3.1 probe 1
Type escape sequence to abort.
Tracing the route to 192.168.3.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 0 msec
2 192.168.23.3 4 msec
3 192.168.3.1 0 msec
在上面我们看到这条轨迹到达了目的地。
Cisco IOS 上的跟踪路由可能非常慢,这是因为它将尝试对每个 IP 地址进行 DNS 查找,为了使其更快,请确保可以解析这些查找或使用no ip domain-lookup 命令禁用 DNS 查找。
以下是 Wireshark 报文:
这个抓图和刚刚看到的Linux抓图是一样的,所以不再添加更多的截图了。
故障排除案例:
在这个例子中我只需要三个路由器:
让我们从一个无法到达的目的地开始,在 R3 上添加一个具有 IP 地址的环回口:
R3(config)#interface loopback 0
R3(config-if)#ip address 3.3.3.3 255.255.255.255
目前,路由器都不知道如何到达 3.3.3.3。让我们先看看 traceroute 输出是什么样的:
R1#traceroute 3.3.3.3
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 * * *
2 * * *
3 * * *
上面我们看到没有一个探测器可到达目的地,然后我们在 R1 上添加一条静态路由,以便此流量至少到达 R2:
R1(config)#ip route 3.3.3.3 255.255.255.255 192.168.12.2
并执行另一个跟踪路由:
R1#traceroute 3.3.3.3
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 4 msec 0 msec 4 msec
2 192.168.12.2 !H * !H
现在我们可以看到 R1 能够转发它,R2 响应它不可达,然后我们在 R2 上添加静态路由:
R2(config)#ip route 3.3.3.3 255.255.255.255 192.168.23.3
再尝试一个跟踪:
R1#traceroute 3.3.3.3
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 0 msec 4 msec 0 msec
2 192.168.23.3 4 msec * 0 msec
现在我们可以到达目的地了。
源不可达
我们可以使用 traceroute 来确定我们是否可以到达某个目的地,但也可以使用它来检查其他路由器是否知道您的来源,这次在R1 上面添加一个环回口:
R1(config)#interface loopback 0
R1(config-if)#ip address 1.1.1.1 255.255.255.255
我现在将使用 1.1.1.1 作为我们的源对 192.168.3.1 进行跟踪路由,我们知道 192.168.3.1 是可达的,因为我们之前尝试过,让我们来看看:
R1#traceroute 192.168.3.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 192.168.3.1
VRF info: (vrf in name/id, vrf out name/id)
1 * * *
2 * * *
3 * * *
此跟踪失败,没有人知道如何到达 1.1.1.1。让我们在 R2 上添加一条静态路由:
R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1
R2 现在知道如何达到 1.1.1.1。让我们再次尝试该 traceroute:
R1#traceroute 192.168.3.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 192.168.3.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 0 msec 4 msec 0 msec
2 * * *
3 * * *
R2 做了响应,这说明问题不在 R1 和 R2 之间,而是在更远的地方。让我们添加最后一个静态路由:
R3(config)#ip route 1.1.1.1 255.255.255.255 192.168.23.2
R3 现在也知道如何到达 1.1.1.1,让我们试试那个跟踪:
R1#traceroute 192.168.3.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 192.168.3.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 0 msec 4 msec 0 msec
2 192.168.23.3 4 msec 0 msec 0 msec
3 192.168.3.1 0 msec 0 msec 4 msec
现在成功完成。
结论
通过此文档相信您已经了解了traceroute 如何使用 IP 数据包中的 TTL(生存时间)字段向目标发送探测,从而允许我们发现从源到目标的路径,您还看到了 Windows 如何使用 ICMP 和 Linux 如何使用 UDP 进行跟踪路由,我们还研究了如何使用 traceroute 对源和/或目标未知的网络可达性问题进行故障排除,如果您在某些路由器的跟踪中看到一些星号(超时),则也可能该路由器(或防火墙)可能配置了访问列表,并配置为不响应任何 TTL 过期消息。