没那么简单！网络故障排除神器 traceroute 探秘

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

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

一、概述

1.1 什么是Traceroute

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

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

Traceroute有三大特点：

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

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

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

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

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

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

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

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

二、Traceroute原理

2.1 Traceroute实现原理

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

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

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

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

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

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

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

2.2 Traceroute实现细节

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

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

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

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

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

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

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

2.3 Traceroute延时计算

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

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

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

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

注意1： 路由器不对包的时间做任何处理，只是单纯的转发数据；
注意2 延时计算的是包的往返时间，但Traceroute显示的是去的路径上所经过的路由。

2.4 每一跳产生原理

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

2. 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显示一跳；

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

4. 你无法从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反向解析后我们能够获取到以下信息：

1. 路由器地理位置

2. 接口类型与带宽

3. 路由类型与角色

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

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

3.1 路由器地理位置的作用

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

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

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

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

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

1. IATA Airport Codes(International Air Transport Association Airport Codes)

2. CLLI Codes(Common Language Location Identifier)

3. 非标准简写的城市名

4. Country Codes

5. 还有一些其他的信息

3.2 接口类型与带宽

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

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

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

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

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

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

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

常见接口类型对照表

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 网络自治系统的边界与关系

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

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

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

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

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

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

2. 很多网络都会尝试将以上信息写在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是在哪里。