此产品的文档集力求使用非歧视性语言。在本文档集中,非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言,文档中可能无法确保完全使用非歧视性语言。 深入了解思科如何使用包容性语言。
思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言,希望全球的用户都能通过各自的语言得到支持性的内容。 请注意:即使是最好的机器翻译,其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任,并建议您总是参考英文原始文档(已提供链接)。
本文档介绍如何 traceroute
命令在不同的系统上运行。
本文档的读者必须具备以下操作系统之一的基本知识:
Cisco IOS®软件
Linux
Microsoft Windows
本文档中的信息适用于以下软件和硬件版本:
运行Cisco IOS软件版本12的Cisco路由器
运行Red Hat Linux的计算机
运行MS Windows的PC
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您的网络处于活动状态,请确保您了解所有命令的潜在影响。
有关文件规则的更多信息请参见“ Cisco技术提示规则”。
此 traceroute
命令允许您通过返回数据包经过的跳数序列来确定数据包从给定源到达目的地所经过的路径。此实用程序随主机操作系统(例如,Linux或Microsoft(MS)Windows)以及Cisco IOS软件一起提供。
如果您执行 traceroute ip-address
命令,它会向目的设备发送IP数据包,其中包含Time To Live(TTL)值,该值会递增到最大指定跳数。默认为 30。通常,在转发这些数据包时,通往目的地的路径中的每个路由器都会将 TTL 字段递减一个单位。当路径中间的一个路由器发现 TTL = 1 的数据包时,会向源发出一条 Internet Control Message Protocol (ICMP)“time exceeded”消息进行响应。通过此消息,源可以知道数据包将该特定路由器作为一个跃点。
与IT部门的 traceroute
命令在本文档讨论的各种操作系统中实施。
初始用户数据报协议(UDP)数据报探测功能的TTL设置为1(或用户指定的最小TTL,如扩展中的 traceroute
命令。初始数据报探测的目标UDP端口设置为33434(或按照扩展中的指定) traceroute
命令输出)。扩展 traceroute
命令是普通命令的 traceroute
命令,允许使用的参数的默认值 traceroute
操作,例如TTL和要修改的目标端口号。有关如何使用扩展 traceroute
命令,请参阅了解扩展ping和扩展traceroute命令。初始数据报探报的源 UDP 端口随机使用,并且与 0x8000 执行逻辑 OR 运算(从而确保源端口最小为 0x8000)。以下步骤说明在启动 UDP 数据报时发生的情况:
注意:参数是可配置的。此示例从 n = 1 开始,到 n = 3 结束。
UDP 数据报在调度时 TTL = 1,目的地 UDP 端口 = 33434,源端口随机使用。
UDP 目的地端口递增,源 UDP 端口随机使用,调度第二个数据报。
第2步最多重复执行三个探测(或者按照扩展中的请求进行多次) traceroute
命令输出)。对于发送的每个探报,您都会收到“TTL exceeded”消息,该消息用于生成到目的地主机的逐步路径。
如果收到ICMP超时消息,TTL将递增,并且此循环以递增目标端口号重复。您也会收到以下消息之一:
ICMP类型3,代码3(目的地不可达,端口不可达)消息,表示已到达主机。
主机无法访问、网络无法访问、超过最大TTL或超时消息类型,这意味着重新发送探测。
Cisco 路由器采用随机源端口和递增目的地端口(用以区分不同的探报)发送 UDP 探报数据包。Cisco路由器将ICMP消息超时发送回收到该UDP/ICMP数据包的源。
Linux traceroute
命令类似于Cisco路由器的实施。不过,它使用固定源端口。此 -n
选项 traceroute
命令用于避免向域名服务器发出请求。
MS Windows tracert
命令使用ICMP回应请求数据报代替UDP数据报作为探针。ICMP Echo 请求使用递增 TTL 启动,Cisco IOS 和 Linux 中也会发生同样的操作。使用ICMP回应请求数据报的意义在于,最后一跳并不依赖于来自目标主机的ICMP不可达消息的响应。而是依赖于 ICMP Echo 回复消息。
命令语法为:
tracert [-d] [-h maximum_hops] [-j computer-list] [-w timeout] target_name
下表介绍命令参数:
参数 | 描述 |
---|---|
-d | 指定不将地址解析为计算机名称。 |
-h maximum_hops | 指定搜索目标的最大跃点数。 |
-j computer-list | 指定沿计算机列表的松散源路由。 |
-w timeout | 对于每个答复等待的超时毫秒数。 |
target_name | 目标计算机的名称。 |
在 Cisco 路由器中,ICMP 不可达限制为每 500 ms 一个数据包(作为针对“拒绝服务”(DoS) 攻击的保护措施)。在 Cisco IOS 软件版本 12.1 和更高版本中,此速率值是可配置的。引入的命令是:
Router(config)#ip icmp rate-limit unreachable ? <1-4294967295> Once per milliseconds DF code 4, fragmentation needed and DF set
此限制是所有 ICMP 不可达的总速率,如以下输出所示。有关更多信息,请参阅 RFC 792 。
type = 3, code 0 = net unreachable; 1 = host unreachable; 2 = protocol unreachable; 3 = port unreachable; 4 = fragmentation needed and DF set; 5 = source route failed.
此限制不会影响其他数据包,如ICMP回应请求或ICMP超时消息。
示例中使用以下网络拓扑:
网络拓扑
在三个示例中,每个示例分别使用一个不同的 Device A。从设备A, traceroute 10.1.4.2
命令会执行到Device 7C。
在每个示例中, debug ip packet detail
命令在设备11A上运行。
此扩展 traceroute
命令示例显示可在执行 traceroute
命令。在本例中,一切均采用默认设置:
rp-10c-2611#traceroute Protocol [ip]: Target IP address: 10.1.4.2 Source address: 10.1.1.1 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 10.1.4.2 1 10.1.1.2 4 msec 0 msec 4 msec 2 10.1.2.2 4 msec 4 msec 0 msec 3 10.1.3.2 0 msec 0 msec 4 msec 4 10.1.4.2 4 msec * 0 msec rp-11a-7204# *Dec 29 13:13:57.060: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Dec 29 13:13:57.060: ICMP type=11, code=0 *Dec 29 13:13:57.064: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Dec 29 13:13:57.064: ICMP type=11, code=0 *Dec 29 13:13:57.064: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Dec 29 13:13:57.068: ICMP type=11, code=0
在此调试输出中,设备11A将ICMP超时消息发送到探测源(10.1.1.1)。这些 ICMP 消息用来回应 TTL=1 的初始探报。设备11A将TTL递减为零,并使用超时消息进行响应。
注:出于以下两个原因,您在此调试输出中看不到UDP探测:
Device 11A 不是 UDP 探报的目的地。
TTL 递减到零,并且数据包从未路由。所以,调试操作从未识别该数据包。
*Dec 29 13:13:57.068: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.068: UDP src=40309, dst=33437 *Dec 29 13:13:57.068: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.068: ICMP type=11, code=0 *Dec 29 13:13:57.072: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.072: UDP src=37277, dst=33438 *Dec 29 13:13:57.072: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.072: ICMP type=11, code=0 *Dec 29 13:13:57.076: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.076: UDP src=36884, dst=33439 *Dec 29 13:13:57.076: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.076: ICMP type=11, code=0
此调试输出显示 UDP 探报源为 10.1.1.1,目的地为 10.1.4.2。
注:在这些探测中,TTL=2(调试时无法看到此值)。Device 11A 将 TTL 递减到 1 并将 UDP 数据包转发到 Device 7A。设备7A将TTL递减为零,并以ICMP超时消息进行响应。
*Dec 29 13:13:57.080: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.080: UDP src=37479, dst=33440 *Dec 29 13:13:57.080: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.080: ICMP type=11, code=0 *Dec 29 13:13:57.084: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.084: UDP src=40631, dst=33441 *Dec 29 13:13:57.084: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.084: ICMP type=11, code=0 *Dec 29 13:13:57.084: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.088: UDP src=39881, dst=33442 *Dec 29 13:13:57.088: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.088: ICMP type=11, code=0
在此调试输出中可以看到接下来的三个 UDP 探报。这些探测器的TTL为3。设备11A将TTL递减为2并将其转发到设备7A。Device 7A将TTL递减为1并将数据包转发到Device 7B,后者将TTL递减为零,并以ICMP time exceeded消息做出响应。
*Dec 29 13:13:57.088: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.088: UDP src=39217, dst=33443 *Dec 29 13:13:57.092: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:13:57.092: ICMP type=3, code=3 *Dec 29 13:13:57.092: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:13:57.096: UDP src=34357, dst=33444 *Dec 29 13:14:00.092: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 28, forward *Dec 29 13:14:00.092: UDP src=39587, dst=33445 *Dec 29 13:14:00.092: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 13:14:00.092: ICMP type=3, code=3
在此调试输出中可以看到最后三个 UDP 探报。这些探报的原始 TTL 为 4。TTL 由 Device 11A 递减到 3,然后由 Device 7A 递减到 2,再由 Device 7B 递减到 1。设备7C以ICMP端口不可达消息做出响应,因为它是探测的目的地。
注意:由于速率限制,设备7C仅发送两个ICMP端口不可达消息。
[root#linux-pc]#traceroute -n 10.1.4.2 traceroute to 10.1.4.2 (10.1.4.2), 30 hops max, 40 byte packets 1. 10.1.1.2 1.140 ms 0.793 ms 0.778 ms 2. 10.1.2.2 2.213 ms 2.105 ms 3.491 ms 1. 10.1.3.2 3.146 ms 2.314 ms 2.347 ms 1. 10.1.4.2 3.579 ms * 2.954 ms rp-11a-7204# *Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Jan 2 07:17:27.894: ICMP type=11, code=0 *Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Jan 2 07:17:27.894: ICMP type=11, code=0 *Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Jan 2 07:17:27.894: ICMP type=11, code=0
在此调试输出中,设备11A将ICMP超时消息发送到探测源(10.1.1.1)。这些 ICMP 消息用来回应 TTL=1 的初始探报。设备11A将TTL递减为零,并使用超时消息进行响应。
出于两个原因,您在此调试输出中看不到 UDP 探报:
Device 11A 不是 UDP 探报的目的地。
TTL 递减到零,并且数据包从未路由。所以,调试操作从未识别该数据包。
*Jan 2 07:17:27.894: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.894: UDP src=33302, dst=33438 *Jan 2 07:17:27.898: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.898: ICMP type=11, code=0 *Jan 2 07:17:27.898: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.898: UDP src=33302, dst=33439 *Jan 2 07:17:27.898: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.898: ICMP type=11, code=0 *Jan 2 07:17:27.898: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.898: UDP src=33302, dst=33440 *Jan 2 07:17:27.902: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.902: ICMP type=11, code=0
注:在此调试输出中,您现在看到从源10.1.1.1发往10.1.4.2的UDP探头。
注:在这些探测中,TTL=2(调试时无法看到此值)。Device 11A 将 TTL 递减到 1 并将 UDP 数据包转发到 Device 7A。设备7A将TTL递减为零,并以ICMP超时消息进行响应。
*Jan 2 07:17:27.902: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.902: UDP src=33302, dst=33441 *Jan 2 07:17:27.906: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.906: ICMP type=11, code=0 *Jan 2 07:17:27.906: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.906: UDP src=33302, dst=33442 *Jan 2 07:17:27.910: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.910: ICMP type=11, code=0 *Jan 2 07:17:27.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.910: UDP src=33302, dst=33443 *Jan 2 07:17:27.910: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.910: ICMP type=11, code=0
现在,在此调试输出中可以看到接下来的三个 UDP 探报。这些探测器的TTL为3。设备11A将TTL递减为2并将其转发到设备7A。Device 7A将TTL递减为1并将数据包转发到Device 7B,后者将TTL递减为零,并以ICMP time exceeded消息做出响应。
*Jan 2 07:17:27.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.910: UDP src=33302, dst=33444 *Jan 2 07:17:27.914: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:27.914: ICMP type=3, code=3 *Jan 2 07:17:27.914: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:27.914: UDP src=33302, dst=33445 *Jan 2 07:17:32.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0), g=10.1.2.2, len 40, forward *Jan 2 07:17:32.910: UDP src=33302, dst=33446 *Jan 2 07:17:32.914: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0), g=10.1.1.1, len 56, forward *Jan 2 07:17:32.914: ICMP type=3, code=3
此调试输出显示最后三个 UDP 探报。这些探报的原始 TTL 为 4。TTL 由 Device 11A 递减到 3,然后由 Device 7A 递减到 2,再由 Device 7B 递减到 1。
然后,设备7C以ICMP端口无法到达消息做出响应,因为它是探测的目的地。
注意:由于速率限制,设备7C仅发送两个ICMP端口不可达消息。
C:\>tracert 10.1.4.2 1 <10 ms <10 ms <10 ms 10.1.1.2 1 <10 ms <10 ms <10 ms 10.1.2.2 1 <10 ms <10 ms <10 ms 10.1.3.2 1 <10 ms 10 ms 10 ms 10.1.4.2 Trace complete rp-11a-7204# *Dec 29 14:02:22.236: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 78, forward *Dec 29 14:02:22.236: UDP src=137, dst=137 *Dec 29 14:02:22.240: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:22.240: ICMP type=3, code=3 *Dec 29 14:02:23.732: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 78, forward *Dec 29 14:02:23.732: UDP src=137, dst=137 *Dec 29 14:02:23.736: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:23.736: ICMP type=3, code=3 *Dec 29 14:02:25.236: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 78, forward *Dec 29 14:02:25.236: UDP src=137, dst=137 *Dec 29 14:02:25.236: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:25.240: ICMP type=3, code=3 *Dec 29 14:02:26.748: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Dec 29 14:02:26.748: ICMP type=11, code=0 *Dec 29 14:02:26.752: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Dec 29 14:02:26.752: ICMP type=11, code=0 *Dec 29 14:02:26.752: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0), len 56, sending *Dec 29 14:02:26.752: ICMP type=11, code=0
在此调试输出中,设备11A将ICMP超时消息发送到探测源(10.1.1.1)。这些 ICMP 消息用于响应初始探报,初始探报是 TTL=1 的 ICMP Echo 请求数据包。Device 11A 将 TTL 递减到零并以 ICMP 消息进行响应。
注:在顶部您会看到NETBIOS名称请求。这些请求被看作源和目的地端口均为 137 的 UDP 数据包。为清楚起见,我们从余下的调试输出中删除了 NETBIOS 数据包。您可以使用 -d
选项 tracert
命令禁用NETBIOS行为。
出于两个原因,您在此调试输出中看不到 ICMP 探报:
Device 11A 不是 ICMP 探报的目的地。
TTL 递减到零,并且数据包从未路由。所以,调试操作从未识别该数据包。
*Dec 29 14:02:32.256: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:32.256: ICMP type=8, code=0 *Dec 29 14:02:32.260: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:32.260: ICMP type=11, code=0 *Dec 29 14:02:32.260: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:32.260: ICMP type=8, code=0 *Dec 29 14:02:32.260: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:32.260: ICMP type=11, code=0 *Dec 29 14:02:32.264: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:32.264: ICMP type=8, code=0 *Dec 29 14:02:32.264: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:32.264: ICMP type=11, code=0
在此调试输出中,现在可以看到 ICMP 探报源为 10.1.1.1,目的地为 10.1.4.2。
注:在这些探测中,TTL=2(调试时无法看到此值)。设备11A将TTL减为1并将UDP数据包转发到设备7A。设备7A将TTL递减为零,并以ICMP超时消息进行响应。
*Dec 29 14:02:37.776: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:37.776: ICMP type=8, code=0 *Dec 29 14:02:37.776: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:37.776: ICMP type=11, code=0 *Dec 29 14:02:37.780: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:37.780: ICMP type=8, code=0 *Dec 29 14:02:37.780: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:37.780: ICMP type=11, code=0 *Dec 29 14:02:37.780: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:37.780: ICMP type=8, code=0 *Dec 29 14:02:37.784: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 56, forward *Dec 29 14:02:37.784: ICMP type=11, code=0
在此调试输出中可以看到接下来的三个 ICMP 探报。这些探测器的TTL为3。设备11A将TTL递减为2并将其转发到设备7A。Device 7A将TTL递减为1并将数据包转发到Device 7B,后者将TTL递减为零,并以ICMP time exceeded消息做出响应。
*Dec 29 14:02:43.292: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:43.292: ICMP type=8, code=0 *Dec 29 14:02:43.296: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 92, forward *Dec 29 14:02:43.296: ICMP type=0, code=0 *Dec 29 14:02:43.296: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:43.296: ICMP type=8, code=0 *Dec 29 14:02:43.300: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 92, forward *Dec 29 14:02:43.300: ICMP type=0, code=0 *Dec 29 14:02:43.300: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0), g=10.1.2.2, len 92, forward *Dec 29 14:02:43.300: ICMP type=8, code=0 *Dec 29 14:02:43.304: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0), g=10.1.1.1, len 92, forward *Dec 29 14:02:43.304: ICMP type=0, code=0
此调试输出显示最后三个 ICMP 探报。这些探报的原始 TTL 为 4。TTL 由 Device 11A 递减到 3,然后由 Device 7A 递减到 2,再由 Device 7B 递减到 1。然后,Device 7C 以 ICMP Echo 回复消息 (type=0, code=0) 进行响应,因为它是探报的目的地。
注意:ICMP回应应答消息并不像ICMP端口不可达消息那样受速率限制。在本例中,可以看到全部三条 ICMP Echo 回复消息均已发送。
在Cisco路由器中, traceroute
命令应答为:
! -- success * -- time out N -- network unreachable H -- host unreachable P -- protocol unreachable A -- admin denied Q -- source quench received (congestion) ? -- unknown (any other ICMP message)
如果您运行 traceroute
命令,请注意以下事项:
您可以接收 traceroute: icmp socket: Permission denied
消息。
此 traceroute
程序依靠网络接口分路器(NIT)在网络中监听。此设备只能由根访问。必须将该程序作为根运行,或者设置根的用户 ID。
本文档演示了如何 traceroute
命令使用UDP和ICMP数据包确定数据包从给定源到给定目的地的路径。输出中可能存在以下 ICMP 消息类型:
如果 TTL 在中转中超时,type=11、code=0,那么,只要探报数据包的 TTL 在数据包到达目的地之前到期,中转路由器就会退回数据包。
如果端口不可达,type=3、code=3,那么,当 UDP 探报数据包到达目的地时(UDP 应用程序未定义),会在对 UDP 探报数据包的响应中退还数据包。这些数据包限制为每 500 ms 一个数据包。这解释了在平稳的响应中来自目的地的响应(请参阅 Cisco 路由器和 Linux 的输出)仍然失败的原因。设备7C不生成ICMP消息,并且 traceroute
每台设备中的命令输出等待多秒钟。对于MS Windows tracert
命令输出中,ICMP消息是生成的,因为Cisco路由器中不存在UDP端口137。
如果有 Echo,type=8,code=0,则 Echo 探报数据包由 MS Windows PC 发送。
如果有 Echo 回复,type=0,code=0,则在到达目的地时会发送对上一数据包的回复。这仅适用于微软窗口 tracert
命令。
版本 | 发布日期 | 备注 |
---|---|---|
2.0 |
16-Oct-2023 |
重新认证 |
1.0 |
11-Apr-2002 |
初始版本 |