tracert命令的作用(tracert命令的作用 linux)

本文转载至公众号“ 功夫运维”。“高效运维”致力于打造F2F的垂直运维分享社区与运维一同愉快的成长。

编者案：对于阿基米德来说，给我一个支点我可以翘起地球，但对于网络大牛来说，给我一个tracerout我可以嗅探整个网络~你可知道Traceroute的详细原理？小知识有大学问，Traceroute是解决网络故障的一把神器哟~

一、概述 1.1 什么是Traceroute

当遇到网络问题，通常会用Traceroute去排查，但Traceroute是什么？

根据百度百科定义，Traceroute是一种用来检测发出数据包主机到目标主机之间所经过网关数量的工具，它可显示数据包在IP网络经过的路由器的IP地址。

Traceroute有三大特点：

跨平台，Traceroute工具存在于各个操作系统平台，包括主流系统MAC OS、Windows、Linux、Android、IOS等；

使用方便，只要在Traceroute命令后输入IP或域名即可；

信息全面，Traceroute能够显示跳数、丢包情况、延时等信息。

但使用Traceroute，根据路由跟踪情况就能排查出问题？答案是否定的。

1.2 用Traceroute却查不出问题的原因

使用Traceroute并根据路由跟踪情况也不能排查出问题，到底是怎么回事？

对于专业人士：基础运营商网络运营质量提高，简单的网络故障问题发生概率降低。低级的问题如拥塞、环路，在实际问题中占非常低的概率；更多的问题是非常复杂以至于只靠单纯的Traceroute已无法准确排查；

对于非专业人士：很少人是真正的理解Traceroute并且利用其分析问题。其次网络情况复杂有非常多的误判报告充斥着世界各地NOC；高误判率导致几乎无法从这些报告中判断出真正展示出最根本的网络问题。

二、Traceroute原理 2.1 Traceroute实现原理

从SRC发出一个探测包到DST，并将TTL设置为1；

探测包每一跳TTL将会减一；

当TTL变为0时，包被丢弃，路由器向SRC发回一个ICMP TTL Exceed包；

当SRC收到该ICMP包时，显示这一跳信息；

重复1～4，并且发生的探测包TTL每次加1；

SRC重复发包直至DST收到探测数据包，并返回ICMP Dest Unreachable包；

当SRC收到ICMP Dest Unreachable包时停止traceroute。

2.2 Traceroute实现细节

传统UNIX系统使用UDP包进行探测，目标端口号为33434，每次探测目标端口号增加1；Windows的tracert.exe和MTR则使用ICMP Echo Request包探测；

如果DST没有返回ICMP Dest Unreachable包则不能探测到DST。这是会发生在某些情况下，如DST前有防火墙，或者DST进行了配置，或者是DST上有一个真实的应用在监听该端口；

通过设置UDP/TCP/ICMP包中的CLI标识位都能够实现Traceroute，一般来说，不推荐使用TCP包，因为通常会被过滤掉；

不同的实现方式通常都会向每跳发送多个探测包，典型的Traceroute默认发送3个探测包，如果没有收到那一跳的回应，延时数据将会输出3个*号；MTR会循环发送无数个探测包；

每个探测包都有唯一的标识号，使得Traceroute能够识别返回的包，UDP/TCP使用递增的目标端口号进行标识，ICMP使用seq #；

由于4层哈希能使每个探测包走不同的路由，对于Traceroute来说，在三层的等价多路径（ECMP）下可见，在二层的聚合链路LAG下不可见；

虽然探测包走不同路径引起不同的结果，但TTL还是相同的。

2.3 Traceroute延时计算

Traceroute可以用于延迟计算，通过Traceroute可以探知到本地计算机到各个传输节点的延迟。详细计算方法如下：

在探测包发出时打上时间戳；

当收到ICMP响应时打上时间戳；

根据两个时间戳计算往返时间；

注意1：路由器不对包的时间做任何处理，只是单纯的转发数据；

注意2延时计算的是包的往返时间，但Traceroute显示的是去的路径上所经过的路由。

2.4 每一跳产生原理

SRC发送TTL为1的包给Router 1；

Router 1收到包后将TTL减1，Router 1发现TTL=0后，丢弃该包，不再转发。并向SRC发送ICMP TTL Exceed包，该包目标IP为SRC的IP，源IP为Router 1的Ingress Interface的IP，Traceroute就会根据ICMP TTL Exceed包的源IP显示一跳；

在上图中SRC会显示两跳，172.16.2.1 10.3.2.2；

你无法从Traceroute中得知包返回的路径以及路由器使用的ICMP Return Interface和Egress Interface的IP。

思考与验证

值得一提的是，在RFC1812 4.3.2.4 ICMP Message Source Address中提到，ICMP包的源地址必须是传包出去的物理接口绑定的其中一个IP（Except where this document specifies otherwise, the IP source address in an ICMP message originated by the router MUST be one of the IP addresses associated with the physical interface over which the ICMP message is transmitted.）。

但经过实验反映出了一个问题。一个探测包确实会有可能从路由器的一个接口进，ICMP TTL Exceed包从另外一个接口出，并且源IP是进的接口IP。

按照个人理解其原因是路由器会把进的接口产生的TTL超时包当作外来的包并遵循路由表进行路由转发，转发过程不会改变包的源目IP。因此在外部看来这个ICMP包并不符合RFC文档的定义。

三、Traceroute中通过DNS反向解析进行信息追溯

理解Traceroute中的DNS反向解析是使用Traceroute的一个非常重要的一个方面。

在Traceroute中同通过DNS反向解析后我们能够获取到以下信息：

路由器地理位置

接口类型与带宽

路由类型与角色

网络自治系统的边界与关系

对于推断问题原因，以上信息显得尤为重要。

3.1 路由器地理位置的作用

为什么我们需要知道地理位置？

优化线路路由，确定不对或者是不太合适的路由。从亚特兰大到迈阿密如果要经过纽约，那就不太理想了。

实景对比，确定高延时是否合理。从印度到美国要300ms，但从日本到美国并不需要300ms。

构建拓扑，帮助你理解网络互联的节点。

我们常用的帮助识别位置信息的数据来源有：

IATA Airport Codes(International Air Transport Association Airport Codes)

CLLI Codes(Common Language Location Identifier)

非标准简写的城市名

Country Codes

还有一些其他的信息

3.2 接口类型与带宽

很多网络都会尝试将接口信息放在DNS，需要注意的是：

接口信息通常是帮助他们排查自己网络的问题；

接口信息有可能不是最新的。虽然很多大型网络会自动产生DNS，但其余的不会；

可以帮助你识别接口的类型，通过接口类型甚至可以知道路由器的型号。

例子

xe-11-1-0.edge1.NewYork1.Level3.net

xe-11-1-0是Juniper 10GE端口，该设备至少有12个板卡槽

至少一台40G/板卡槽的路由器，因为它有一块10GE板卡在板卡槽1

常见接口类型对照表

Interface Type

Cisco IOS

Cisco IOS XR

Juniper

Fast

Ethernet

Fa#/#

fe-#/#/#

Gigabit Ethernet

Gi#/#

Gi#/#/#/#

ge-#/#/#

10 Gigabit Ethernet

Te#/#

Te#/#/#/#

xe-#/#/# (*)

SONET

Pos#/#

POS#/#/#/#

so-#/#/#

T1

Se#/#

t1-#/#/#

T3

t3-#/#/#

Ethernet Bundle

Po# / Port-channel#

BE####

ae#

SONET Bundle

PosCh#

BS####

as#

Tunne

Tu#

TT# or TI#

ip-#/#/# or gr-#/#/#

ATM

ATM#/#

AT#/#/#/#

at-#/#/#

Vlan

Vl###

Gi#/#/#/#.###

ge-#-#-#.###

3.3 路由类型与角色

知道路由器角色是非常有用的，但每个AS都不一样，使用不同的角色命名，并且他们也不会一直遵循自己的命名规则。

总的来说，你只能通过你的网络知识去猜路由器的角色。通常来说有以下规律：

Core routers – CR, Core, GBR, BB, CCR, EBR

Peering routers – BR, Border, Edge, IR, IGR, Peer

Customer routers – AR, Aggr, Cust, CAR, HSA, GW

3.4 网络自治系统的边界与关系

识别网络自治系统的边界（边缘很重要）：

DNS反向域名解析能帮助你知道路由策略变化的地方。如：不同的返回路径是基于本地优先级的；

能帮助你知道带宽与路由最差的地方，这些地方可能就是产生问题的地方；

当然也能帮助你知道应该去联系谁。

识别网络自治系统的关系(同样对管理有所帮助)：

典型三个角色：Transit Provider、Peer、Customer

很多网络都会尝试将以上信息写在DNS上。如networkname.customer.alter.net

有时能够看到反解域名的明显变化：

4 te1-2-10g.ar3.DCA3.gblx.net (67.17.108.146) 5 sl-st21-ash-8-0-0.sprintlink.net (144.232.18.65)

有时能够看到DNS的某一部分变化：

4 po2-20G.ar5.DCA3.gblx.net (67.16.133.90) 5 cogent-1.ar5.DCA3.gblx.net (64.212.107.90)

当然有时DNS的信息根本没有用：

2 po2-20G.ar4.DCA3.gblx.net (67.16.133.82) 3 192.205.34.109 (192.205.34.109) 4 cr2.wswdc.ip.att.net (12.122.84.46)

以上无法判断GBLX的边界，同时无法判断192.205.34.109是在哪里。

来看更多的信息：

4 po2-20G.ar5.DCA3.gblx.net (67.16.133.90) 5 cogent-1.ar5.DCA3.gblx.net (64.212.107.90) > nslookup 64.212.107.89 = te2-3-10GE.ar5.DCA3.gblx.net

ar5.DCA3.gblx.net有多个DNS域名解析，通过以上分析，就算第5跳的DNS中没有cogent字眼提示也能判断第5跳与第4跳分属两个自治系统（命名规则发生变化）。

以上分析涉及到一个关键点，根据/30掩码获取对端IP。

如上图，两个接口虽然同在一个/30掩码网段内，但路由器并不会收集或维护邻居的DNS信息，所以当一个包发出时路由器并不知道邻居的DNS信息，这时就会填充上自己接口的DNS信息而不是留空白让邻居去填充。因此通过分析对端的接口信息，就能够知道路由器所属自治系统（若64.212.107.89的域名是cogent-0.ar5.DCA3.gblx.net，那么ar5.DCA3路由器将属于两个自治系统）。

四、网络延时

三种主要网络延时：

串行延时。该延时是路由器或交换机发送数据包的时间，串行延时=包大小(bits)/传输速率(bps)；

排队延时。该延时是数据包在路由器队列中等待发出的时间，非拥塞情况下排队延时可忽略不计；

传播延时。该延时是数据包在传播介质中传播所用时间，该延时主要取决于光或电磁的传播速度。

4.1 串行延时

该延时产生在转发数据包的时候，产生原因：

一个数据包被移动到网络上的时候是一个不可分的单元；

在一个数据包传输完毕之前另外一个数据包无法发送。

在高速网络中该延时非常小

1500 bytes over a 56k link (56Kbps) = 214.2ms delay

1500 bytes over a T1 (1.536Mbps) = 7.8ms delay

1500 bytes over a FastE (100Mbps) = 0.12ms delay

1500 bytes over a GigE (1Gbps) = 0.012ms delay

4.2 排队延时

利用率

1G的接口跑到500Mbps我们会说利用率是50%，但实际上，一个接口只能进行转发数据（100%利用）或者不能转发数据（0%利用），故所谓的50%利用率实际上是指1s内有0.5s用来了传输数据。

排队

当一个接口在被使用，下一个包必须排队等待被发送。通常来说，一个接口90%使用率等于将要转发的包90%都在排队。当一个接口达到饱和时，排队时间将迅速增加，当一个接口过饱和时，一个包排队可能要耗费几百甚至几千毫秒，排队延时通常与拥塞程度相关联。

4.3 传播延时

该延时由光信号或电磁信号在介质中的传播速度与距离决定。光速（真空状态下传播）约为300,000km/s，但光纤是由玻璃制作，非真空，故光在光纤内传播速度较真空状态慢，约为0.67c，即200,000km/s，1ms的往返延时距离为100km。

例子

环地球赤道一圈（约为40000km）传播延时大概为200ms（往返延时为400ms）。

知道以上数据，通过traceroute的每一跳地理位置信息，通过距离计算传播延时就知道延时是否正常了。

3 xe-3-0-0.cr1.nyc3.us.nlayer.net (69.22.142.74) 6.570ms 4 xe-0-0-0.cr1.lhr1.uk.nlayer.net (69.22.142.10) 74.144ms

美国纽约到英国伦敦只需要67.6ms，两地相距约6759km，延时正常。

5 cr2.wswdc.ip.att.net (12.122.3.38) [MPLS: Label 17221 Exp 0] 8 msec 8 msec 8 msec 6 tbr2.wswdc.ip.att.net (12.122.16.102) [MPLS: Label 32760 Exp 0] 8 msec 8 msec 8 msec 7 ggr3.wswdc.ip.att.net (12.122.80.69) 8 msec 8 msec 8 msec 8 192.205.34.106 [AS 7018] 228 msec 228 msec 228 msec 9 te1-4.mpd01.iad01.atlas.cogentco.com (154.54.3.222) [AS 174] 228 msec 228 msec 228 msec

在美国本土传播耗时220ms，延时不正常。

五、对于网络优先级与限速相关故障的问题分析 5.1 Traceroute延时判断影响因素

Traceroute延时包括三点：

探测包到达一个特定路由器的时间

路由器生成IPMI TTL Exceed的时间

ICMP TTL Exceed返回到SRC的时间

第一个和第三个时间都是受实际网络情况影响的，而第二个时间不是。能够对网络问题的判断起到帮助作用的仅仅只有第一个和第三个时间，第二个时间往往起到误导的作用。

5.2 路由器工作原理

路由器有转发（data-plane）和接收（control-plane）的功能。

路由器转发包有两种模式：

Fast Path：硬件实现转发源包（几乎所有的网络的数据包）

Slow Path：软件实现处理“异常”包（IP Options， ICMP generation ←Traceroute发生在这里）

路由器能够接收直接发送到路由器上绑定的IP的包，接收的包可以是BGP、IGP、SNMP、CLI访问（telnet/ssh）、ping等

但是，路由器的CPU性能是比较差的。一个320-640+Gbps背板的路由器，却只有一个单核600MHz MIPS CPU，通常CPU用来做其他事而不是做Traceroute，因此ICMP Generation在路由器看来优先级较低，大多数情况下更是有速度限制和降级的处理。

降级

在一些常见的路由器平台上，Slow path中的转发与接收是公用资源，同时没有使用最好的软件调度器。因此一些控制性的数据处理比如BGP churn、CLI等会消耗CPU资源，使得ICMP TTL Exceed包的产生延迟。

限速

大部分路由器会限制他们的ICMP包产生，不同厂商会有不同的并且不可设置的限速值，这大大影响了Traceroute的效果，特别是在很多用户同时使用MTR时。

例子

Foundry MLX/XMR：Hard-coded limit of 400pps per interface.

Force10 E-series：Hard-coded limit of 200pps or 600pps per interface.

5.3 排除假延时

那么有办法排除第二个时间对整个延时的影响吗？答案是有的。最重要的一个规则：如果在某一跳中发生问题，那么所有后续跳的延时将会持续或增长。

下面例子中第二跳并没有问题

1 ae3.cr2.iad1.us.nlayer.net 0.275ms 0.264 ms 0.137 ms 2 xe-1-2-0.cr1.ord1.us.nlayer.net 18.271 ms 68.257 ms 18.001 ms 3 tge2-1.ar1.slc1.us.nlayer.net 53.373 ms 53.213 ms 53.227 ms

在Traceroute过程中出现的延时突高并不是什么问题，造成这种现象主要有两种原因：

通常是路由器的限速与优先级问题；

最坏情况是路由器回包过程中走的路径不同导致的（非对称转发路径）。

六、对于非对称转发路径情况的问题分析

网络中的路由是没法保证对称的转发路径，即往返的路径完全相同。而Traceroute显示的只是去的方向的路径，但仍然要注意延时是往返的耗时。对于Traceroute来说，返回的路径是完全不可见的，返回的每一跳可能跟去的时候完全不一样。排查问题的时候可以进行反向的Traceroute，看返回的路径上是否出现问题，当然，这样也不能保证路径是一样的。

6.1 非对称转发路径与AS边界

非对称路径通常是在AS边界开始的。为什么？那是因为AS边界通常是AS管理策略改变的地方。

te1-1.ar2.DCA3.gblx.net (69.31.31.209) 0.719 ms 0.560 ms 0.428 ms te1-2-10g.ar3.DCA3.gblx.net (67.17.108.146) 0.574 ms 0.557 ms 0.576 ms sl-st21-ash-8-0-0.sprintlink.net(144.232.18.65) 100.280 ms 100.265 ms 100.282 ms 144.232.20.149 (144.232.20.149) 102.037 ms 101.876 ms 101.892 ms sl-bb20-dc-15-0-0.sprintlink.net(144.232.15.0) 101.888 ms 101.876 ms 101.890 ms

上面例子说明了什么问题？

在GBLX和Sprint的边界出现拥塞；

可能是由于正向或反向路径出现拥塞。

由于两个AS出口策略不一致造成的拥塞是很常见的。

6.2 多路径互联

非对称的路径可出现在每一跳，特别是有多条路径到达的节点。

第一跳（紫色）：折回点为Washington DC

第二跳（红色）：折回点为Chicago IL

第三跳（绿色）：折回点为San Jose CA

可以看到第三跳不是原路返回的，如果Chicago IL返回的路径上出现拥塞，那么第三跳上将不会出现拥塞情况，故在Traceroute时可能会看到第二跳延时高于第三跳。

如果出现以上情况时，该如何去排查问题？

假设如下的情况，你有多条路径可到达Sprint，但Traceroute显示You->Global Crossing->Sprint，并且问题出现在第三跳的Sprint。

如何证明问题不是出现在GX这边的路径？

使用之前提到的/30掩码方法，使用Global Crossing的/30掩码找到对端IP，并作为SRC进行Traceroute，那么就能保证返回路径为Sprint->Global Crossing；

同样的方法Traceroute另外一跳路径；

两边的延时对比后，就知道哪条路径出现问题。

当然/30掩码方法不一定能够准确找到对端IP，这完全取决于路由的配置。

思考：为什么Traceroute设置源IP后能够保证第一跳的返回路径？

Traceroute的源IP为你IP空间的IP时（比如是loopback），回包的时候可回到任一接口。但如果在对端路由器配置了/30掩码的IP在IGP时，那么就会强制回包至指定IP的接口。

七、对于等价路由情况下的问题分析 7.1 等价路由

基于流的哈希算法能够保证同一个TCP/UDP数据流通过相同的路径。而UDP/TCP Traceroute的探测包的目标端口是递增的，在路由器看来可能不是同一个数据流，这可能造成探测包会走不同的平行路径。

以上图来说，Traceroute的结果可能与实际完全不同，正常应该是A -> B1 -> C1 -> D或A -> B2 -> C2 -> D，但结果可能是A -> B1 -> C2 -> D，这跟拓扑完全不一样。

例如：

ldn-bb2-link.telia.net (80.91.251.14) 74.139 ms 74.126 ms ldn-bb1-link.telia.net (80.91.249.77) 74.144 ms hbg-bb1-link.telia.net (80.91.249.11) 89.773 ms hbg-bb2-link.telia.net (80.91.250.150) 88.459 ms 88.456 ms s-bb2-link.telia.net (80.91.249.13) 105.002 ms s-bb2-link.telia.net (80.239.147.169) 102.647 ms 102.501 ms

这对于正常的数据流流来说是有好处的，基于流的哈希算法能够避免了数据包的重组，但对于Traceroute来说就有点问题了。

7.2 等价不等长路由

这种情况会令Traceroute看上去令人觉得跳来跳去，这使得排查问题难上加难。

以上图来说，正常应该是A → B1 → C 或 A → B2 → X → C，这样测出来已经令人迷惑了，究竟是三跳还是四跳？

但实际情况可能更加糟糕，可能是 A → B1 → X → C，这完全与拓扑不相符；同时也可能是 A → B1 → C → C，看到了吗，出现“回路”了。

对于上面一条路来说，TTL=3时是C，对于下面一条路来说，TTL=4时是C，两个探测包刚好走了两条不同的路，所以正好出现了这样的“回路”。

7.3 单路径Traceroute

那么有办法能够让Traceroute固定走一条路吗？有的。

利用Traceroute强大的参数设置，固定目标端口不变，就能够Traceroute出同一条路径了（Traceroute 2.0.14版本，-U可固定目标端口不变，-p指定目标端口）。

但是需要注意Traceroute出来的路径不一定是实际数据包走的路径。可以通过目标IP加1或减1进行多次Traceroute来完成多路径的Traceroute。

网络中区分数据流的策略很多，三层网络通常是根据源IP、目标IP来区分一个数据流，因此固定目标端口，更改目标IP能够让探测包走不同的路径，从而让Traceroute更加准确。

上图是我从实际环境截获的包。

gz-ganglia2向gz-ganglia1进行Traceroute，在gz-ganglia1上截包，从上图能够看到固定端口为55555，且收到多个TTL大于1的UDP包，这跟Traceroute的原理有关，Traceroute每跳默认发3个包，超时时间为5s，每三个包TTL增加1，直至收到ICMP Dest Unreachable包后停止发包。

故在收到ICMP Dest Unreachable包之间，Traceroute还是认为没有到达目标，仍然继续发包，故目标主机可以收到TTL大于1的包。若Traceroute一直没有收到ICMP Dest Unreachable包则默认会一直发到TTL=30停止发送。

八、对于多协议标签交换（MPLS）情况下Traceroute应注意的问题 8.1 MPLS ICMP隧道

很多大型网络都有运用MPLS，有些路由器只根据MPLS的标签进行转发而没有IP路由表，当ICMP包产生时问题就出现了，这些路由器要怎么去转发这些ICMP包？其中一种解决方案是MPLS ICMP隧道。

当一个ICMP包产生并打上标签时，路由器会根据标签交换路径（LSP）转发表将ICMP包转发至下一跳，这会导致Traceroute的结果看起来非常奇怪，你会看到中间很多跳的延时会跟某一跳的延时是一样的，如下例。

te2-4.ar5.PAO2.gblx.net (69.22.153.209) 1.160 ms 1.060 ms 1.029 ms 192.205.34.245 (192.205.34.245) 3.984 ms 3.810 ms 3.786 ms tbr1.sffca.ip.att.net (12.123.12.25) 74.848 ms 74.859 ms 74.936 ms cr1.sffca.ip.att.net (12.122.19.1) 74.344 ms 74.612 ms 74.072 ms cr1.cgcil.ip.att.net (12.122.4.122) 74.827 ms 75.061 ms 74.640 ms cr2.cgcil.ip.att.net (12.122.2.54) 75.279 ms 74.839 ms 75.238 ms cr1.n54ny.ip.att.net (12.122.1.1) 74.667 ms 74.501 ms 77.266 ms gbr7.n54ny.ip.att.net (12.122.4.133) 74.443 ms 74.357 ms 75.397 ms ar3.n54ny.ip.att.net (12.123.0.77) 74.648 ms 74.369 ms 74.415 ms 12.126.0.29 (12.126.0.29) 76.104 ms 76.283 ms 76.174 ms route-server.cbbtier3.att.net (12.0.1.28) 74.360 ms 74.303 ms 74.272 ms

为什么会这样？

根据Traceroute原理ICMP TTL Exceed包应该是由每一跳的路由直接返回给SRC。

但是，在MPLS ICMP隧道中，ICMP包会一直走到MPLS的出口才会返回给SRC，这就造成在MPLS上的所有跳的延时都是几乎一样的。

九、结语

一个看似简单的Traceroute里面包含如此多的网络知识，有那么多的因素导致Traceroute无法正确嗅探出网络拓扑，那么是否真的没有办法？

不是的，Paris Traceroute就是一种新式的Traceroute，它能够更加准确的嗅探出网络拓扑，为网络排障提供更加准确的依据。等我研究完了Paris traceroute再做分享。

参考文献：

1. A Practical Guide to (Correctly) Troubleshooting with Traceroute 2. Avoiding traceroute anomalies with Paris traceroute 3. RFC1812 4. 百度百科 5. 维基百科

想了解

更多？

更深？

GOPS 2017 北京站有更多专家的分享哟

2017.7.28-7.29