注：本文是同事的大作，虽是翻译的一篇英文PPT，但内容实在精彩，小小的Traceroute竟包含如此大的信息量，真是让人感慨！内容不涉及公司机密，所以一直想转到自己的Blog上来，自己需要时可以再翻阅学习。
-----------------------------------------------------
-
原文Created and last modified by tanzh on 十月 14, 2014
本人网络知识比较欠缺，最近就在网上游逛，学习网络知识，机缘巧合找到一个思路很广的PPT，于是就将其翻译改写，查找相关资料，加入自己学习过程中的理解和实验，分享给大家，共同学习，共同进步。
一、概述
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并且利用其分析问题。大部分ISP NOC甚至是专业的网络工程师也难以解释一个复杂的路由；有非常多的误判报告充斥着世界各地NOC；高误判率导致几乎无法从这些报告中判断出真正最根本的网络问题。
二、Traceroute原理
2.1 Traceroute实现原理
-
从SRC发出一个探测包到DST，并将TTL设置为1；
-
每一跳TTL将会减一；
-
当TTL变为0时，包被丢弃，路由器向SRC发回一个ICMP TTL Exceed包；
-
当SRC收到该ICMP包时，显示这一跳信息；
-
重复1～5，并每次TTL加1；
-
直至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延时计算
-
在探测包发出时打上时间戳；
-
当收到ICMP响应时打上时间戳；
-
根据两个时间戳计算往返时间；
注：延时计算的是包的往返时间，但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.）。
经过与hewt实验证实了这个问题。一个探测包确实会有可能从路由器的一个接口进，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# |
| Tunnel | 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 网络自治系统的边界与关系
识别网络自治系统边缘很重要：
-
能帮助你知道路由策略变化的地方。如：不同的返回路径是基于本地优先级的；
-
能帮助你知道带宽与路由最差的地方，这些地方可能就是产生问题的地方；
-
当然也能帮助你知道应该去联系谁。
识别网络自治系统的关系同样有所帮助：
-
典型三个角色：Transit Provider、Peer、Customer
-
很多网络都会尝试将以上信息写在DNS上。如etworkname.customer.alter.net
有时能够看到反解域名的明显变化：
|
|
有时能够看到DNS的某一部分变化：
|
|
当然有时DNS的信息根本没有用：
|
|
以上无法判断GBLX的边界，同时无法判断192.205.34.109是在哪里。
来看更多的信息：
|
|
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 排队延时
1. 利用率
1G的接口跑到500Mbps我们会说利用率是50%，但实际上，一个接口只能进行转发数据（100%利用）或者不能转发数据（0%利用），故所谓的50%利用率实际上是指1s内有0.5s用来了传输数据。
2. 排队
当一个接口在被使用，下一个包必须排队等待被发送。通常来说，一个接口90%使用率等于将要转发的包90%都在排队。当一个接口达到饱和时，排队时间将迅速增加，当一个接口过饱和时，一个包排队可能要耗费几百甚至几千毫秒，排队延时通常与拥塞程度相关联。
4.3 传播延时
该延时由光信号或电磁信号在介质中的传播速度与距离决定。光速（真空状态下传播）约为300,000km/s，但光纤是由玻璃制作，非真空，故光在光纤内传播速度较真空状态慢，约为0.67c，即200,000km/s，1ms的往返延时距离为100km。
例子：
环地球赤道一圈（约为40000km）传播延时大概为200ms（往返延时为400ms）。
知道以上数据，通过traceroute的每一跳地理位置信息，通过距离计算传播延时就知道延时是否正常了。
|
|
美国纽约到英国伦敦只需要67.6ms，两地相距约6759km，延时正常。
|
|
在美国本土传播耗时220ms，延时不正常。