本文转载至微信官方账号“功夫运维”。“高效运维”致力于打造F2F的垂直运维共享社区,与运维一起快乐成长。
编者按:对于阿基米德来说,给我一个支点就可以托起地球,但是对于网络大牛来说,给我一个Traceroute就可以嗅出整个网络~你知道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超过数据包。
SRC收到ICMP数据包时,显示跳数信息;
重复1 ~ 4,生成的探测包TTL每次增加1;
SRC重复该包,直到DST收到探测包并返回ICMP目的地不可达包;
当SRC收到ICMP目的地不可达数据包时,Traceroute停止。
2.2 Traceroute实现细节传统UNIX系统使用UDP包进行探测,目标端口号为33434,目标端口号每次增加1;通过ICMP回应请求包检测窗口的tracert.exe和中期审查。
如果夏令时没有返回ICMP目的地不可达数据包,则无法检测到夏令时。在某些情况下会出现这种情况,比如DST前面有防火墙,或者配置了DST,或者DST上有真实应用在监听端口;
可以通过在UDP/TCP/ICMP数据包中设置CLI标识位来实现Traceroute。一般来说,不建议使用TCP数据包,因为它们通常会被过滤掉。
不同的实现通常向每一跳发送多个探测包,典型的Traceroute默认发送三个探测包。如果没有收到来自该跳的响应,延迟的数据将输出三个*符号;港铁会循环发送无数探测包;
每个探测包都有唯一的标识号,这样Traceroute就可以标识返回的包,UDP/TCP通过增加目的端口号来标识,ICMP通过seq #;;
因为4层哈希可以使每个探测包采用不同的路由,所以在3层的ECMP下可以看到Traceroute,而在2层的聚合链路LAG下看不到Traceroute。
尽管探测包采用不同的路径并导致不同的结果,但TTL是相同的。
2.3 Traceroute延时计算Traceroute可用于延迟计算,从本地计算机到每个传输节点的延迟可通过Traceroute检测。具体计算方法如下:
发送探测包时的时间戳;
接收ICMP响应时的时间戳;
根据两个时间戳计算往返时间;
注1:路由器不处理包时间,只是简单转发数据;
注2延迟计算数据包的往返时间,但跟踪路由显示到达它的路由。
2.4 每一跳产生原理SRC向路由器1发送TTL为1的数据包;
路由器1收到数据包后将TTL减1,发现TTL=0后丢弃数据包,不转发。并向SRC发送ICMP TTL over数据包,数据包的目的IP为SRC IP,源IP为路由器1的入口接口IP,Traceroute会根据ICMP TTL over数据包的源IP显示一跳;
在上图中,SRC将显示两跳,172 . 16 . 2 . 1 10 . 3 . 2 . 2;
您不能从跟踪路由中知道数据包的返回路径以及路由器使用的ICMP返回接口和出口接口的IP。
思考与验证
值得一提的是,RFC 1812 4.3.2.4 ICMP消息源地址中提到,ICMP数据包的源地址必须是其中一个IP(除非本文档另有规定,否则由路由器发出的ICMP消息中的IP源地址必须是与传输ICMP消息的物理接口相关联的IP地址之一。)。
然而,实验显示了一个问题。一个探测包确实有可能从路由器的一个接口进入,ICMP TTL over包有可能从另一个接口退出,源IP就是传入接口IP。
据个人了解,原因是路由器会将入接口产生的TTL超时数据包作为外部数据包,按照路由表进行路由转发,转发过程不会改变数据包的源IP。因此,从外部来看,这个ICMP数据包不符合RFC文档的定义。
三、Traceroute中通过DNS反向解析进行信息追溯了解Traceroute中的DNS逆向解析是使用Traceroute的一个非常重要的方面。
在Traceroute中,我们可以在反向DNS解析后获得以下信息:
路由器的地理位置
接口类型和带宽
路由类型和角色
网络自治系统的边界和关系
以上信息对于推断问题原因尤为重要。
3.1路由器地理位置的作用
为什么我们需要知道地理位置?
优化线路布线,以确定不正确或不适当的路线。从亚特兰大经纽约去迈阿密不太理想。
现实生活中的比较,以确定高延迟是否合理。印度到美国需要300ms,日本到美国不需要300ms。
建立一个拓扑来帮助你理解网络互联的节点。
我们帮助识别位置信息的常用数据源有:
国际航空运输协会机场代码
CLLI代码(通用语言位置标识符)
带有非标准缩写的城市名称
国家代码
还有一些其他的信息
3.2 接口类型与带宽很多网络会尝试把接口信息放入DNS。应该指出的是:
接口信息通常有助于他们解决自己的网络问题;
界面信息可能不是最新的。虽然很多大型网络会自动生成DNS,但其他的不会;
它可以帮助您识别接口的类型,甚至可以通过接口类型知道路由器的型号。
例子
xe-11-1-0.edge1.NewYork1.Level3.net
Xe-11-1-0是Juniper 10GE端口,至少有12个卡槽
至少一个40G/卡插槽的路由器,因为它在卡插槽1中有一个10GE卡
通用接口类型对照表
Interface TypeCisco IOSCisco IOS XRJuniperFastEthernetFa#/#fe-#/#/#Gigabit EthernetGi#/#Gi#/#/#/#ge-#/#/#10 Gigabit EthernetTe#/#Te#/#/#/#xe-#/#/# (*)SONETPos#/#POS#/#/#/#so-#/#/#T1Se#/#t1-#/#/#T3t3-#/#/#Ethernet BundlePo# / Port-channel#BE####ae#SONET BundlePosCh#BS####as#TunneTu#TT# or TI#ip-#/#/# or gr-#/#/#ATMATM#/#AT#/#/#/#at-#/#/#VlanVl###Gi#/#/#/#.###ge-#-#-#.###3.3 路由类型与角色知道路由器角色是非常有用的,但是每个AS都是不同的,使用不同的角色来命名它,他们不会总是遵循自己的命名规则。
一般来说,你只能通过你的网络知识来猜测路由器的作用。一般来说,有以下规则:
核心路由器——核心路由器、核心路由器、GBR路由器、宽带路由器、核心路由器、基站路由器
对等路由器–BR、边界、边缘、IR、IGR、对等
客户路由器–澳大利亚、澳大利亚、加拿大、HSA、佐治亚州
3.4 网络自治系统的边界与关系识别网络自治系统的边界(边缘很重要);
DNS反向域名解析可以帮助你知道路由策略在哪里变化。例如,不同的返回路径基于本地优先级;
可以帮助你知道带宽和路由最差的地方,可能是问题出现的地方;
也可以帮你知道联系谁。
识别网络自治系统之间的关系(对管理也有帮助);
典型的三个角色:运输提供商、同行和客户
很多网络会尝试把上面的信息写在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)>;64.212.107.89 = te2-3-10GE.ar5.DCA3.gblx.net
ar5.DCA3.gblx.net有多种域名解析方式。通过以上分析,即使第五跳的DNS中没有令人信服的单词提示(命名规则发生变化),也可以判断第五跳和第四跳属于两个自治系统。
以上分析涉及到一个关键点,就是根据/30掩码获取对面IP。
如上图所示,虽然两个接口在同一个/30掩码网段,但路由器并不收集或维护邻居的DNS信息,所以在发送数据包时,路由器并不知道邻居的DNS信息,然后会填写自己接口的DNS信息,而不是留下空让邻居填写。因此,通过分析对端的接口信息,我们可以知道路由器属于哪个自治系统(如果64.212.107.89的域名是cogent-0.ar5.DCA3.gblx.net,那么ar5。DCA3路由器将属于两个自治系统)。
第四,网络延迟
三种主要的网络延迟:
串行延迟。延迟是路由器或交换机发送数据包的时间,串行延迟=数据包大小(比特)/传输速率(bps);
排队延迟。该延迟是数据包在路由器队列中等待发送的时间,在非拥塞的情况下,队列延迟可以忽略
传播延迟。延迟是数据包在传播介质中传播所用时间,延迟主要取决于光或电磁的传播速度。
4.1 串行延时转发数据包时会出现这种延迟,原因如下:
当数据包被移动到网络时,它是一个不可分割的单元。
一个包在另一个包传输之前不能被发送。
这种延迟在高速网络中非常小
56k链路上的1500字节(56 Kbps)= 214.2毫秒延迟
T1上的1500字节(1.536 Mbps)= 7.8毫秒延迟
FastE (100Mbps) = 0.12ms延迟,1500字节
千兆以太网(1Gbps) = 0.012ms延迟,1500字节
4.2 排队延时实用比
当1G的接口运行到500Mbps时,我们会说利用率是50%,但实际上一个接口只能转发数据(100%利用率)或者不能转发数据(0%利用率),所以所谓的50%利用率,其实就是用0.5s在1 s内传输数据。
排队
当一个接口正在使用时,下一个数据包必须排队才能发送。一般来说,一个接口90%的利用率等于要转发的数据包的90%。当一个接口饱和时,排队时间会迅速增加。当接口过饱和时,数据包排队可能需要数百甚至数千毫秒。排队延迟通常与拥挤程度有关。
4.3 传播延时延迟由光信号或电磁信号在介质中的传播速度和距离决定。光的速度(真空状态下的传播)约为300,000 km/s,但光纤是玻璃制成的,这不是真空,所以光在光纤中的传播速度比真空状态下慢,约为0.67c,即200,000km/s。
例子
围绕地球赤道的一个圆(约40000公里)的传播延迟约为200毫秒(往返延迟为400毫秒)。
知道了以上数据,通过traceroute每一跳的地理位置信息,通过距离计算传播时延,就可以知道时延是否正常。
3 xe-3-0-0.cr1.nyc3.us.nlayer.net(69.22.142.74)6.570毫秒4 xe-0-0-0.cr1.lhr1.uk.nlayer.net(69.22.142.10)74.144毫秒
从美国纽约到英国伦敦仅需67.6ms,两地距离约6759km,正常延迟。
5 cr2.wswdc.ip.att.net(12.122.3.38)[MPLS:标签17221 Exp 0] 8毫秒8毫秒8毫秒6 tbr2.wswdc.ip.att.net(12.122.16.102)[MPLS:标签32760 Exp 0] 8毫秒8毫秒7 ggr3.wswdc.ip.att.net(12.122.80.69)8毫秒8毫秒8毫秒8 192.205.34.106[AS 7018]228毫秒228毫秒228毫秒9 te1-4.mpd01.iad01.atlas.cogentco.com(154 . 54 . 3 . 222)[AS 174]228毫秒228毫秒228毫秒228毫秒
在美国传播需要220ms,延迟不正常。
动词 (verb的缩写)网络优先级和限速相关问题分析5.1追踪路径延迟判断的影响因素
Traceroute延迟包括三点:
探测数据包到达特定路由器的时间
路由器生成IPMI时间长度超出的时间
ICMP TTL超过它返回到服务请求控制的时间
第一次和第三次受实际网络情况影响,第二次不受影响。只有第一次和第三次才能帮助判断网络问题,第二次往往起误导作用。
5.2路由器的工作原理
路由器具有数据平面和控制平面的功能。
路由器转发数据包有两种模式:
快速路径:硬件实现转发源数据包(几乎所有网络数据包)
慢路径:软件实现对“异常”数据包的处理(IP选项,ICMP生成←Traceroute发生在这里)
路由器可以接收直接发送到路由器上绑定的IP的数据包,接收到的数据包可以是BGP、IGP、SNMP、CLI访问(telnet/ssh)、ping等
但是路由器的CPU性能相对较差。一个320-640+Gbps背板的路由器,只有一个单核的600MHz MIPS CPU,通常用来做其他事情,而不是Traceroute。因此,ICMP Generation在路由器中的优先级较低,大多数情况下都有速度限制和性能下降。
使降级
在一些常见的路由器平台上,慢速路径的转发和接收是常见的资源,没有使用最好的软件调度器。因此,一些控制数据处理,如BGP流失和CLI,会消耗CPU资源,延迟ICMP TTL Exceed数据包的生成。
限速
大多数路由器都会限制自己的ICMP包生成,不同的厂商会有不同的、不可设置的限速值,这极大地影响了Traceroute的效果,尤其是很多用户同时使用MTR的时候。
例子
MLX铸造厂/XMR:每个接口400pps的硬编码限制。
Force10 E系列:每个接口200pps或600pps的硬编码限制。
5.3 排除假延时那么有什么办法可以消除第二次对整个延迟的影响呢?答案是肯定的。最重要的规则:如果某一跳出现问题,所有后续跳的延迟都会持续或增加。
以下示例中的第二跳不是问题
1 ae3.cr2.iad1.us.nlayer.net 0.275毫秒0.264毫秒0.137毫秒2 xe-1-2-0.cr1.ord1.us.nlayer.net 18.271毫秒68.257毫秒18.001毫秒3 tge2-1.ar1.slc1.us.nlayer.net 53.373毫秒53.213毫秒53.227毫秒
Traceroute中突然出现的高延迟不是问题,主要有两个原因:
通常是路由器的限速和优先级;
最糟糕的情况是由路由器在数据包返回期间采用的不同路径(不对称转发路径)引起的。
六、对于非对称转发路径情况的问题分析网络中的路由不能保证对称的转发路径,即进出网络的路径完全相同。Traceroute只显示要走的方向上的路径,但是应该注意的是,对于往返来说,延迟是很耗时的。对于Traceroute,返回的路径是完全不可见的,并且返回的每一跳可能与其经过的时间完全不同。排除故障时,您可以反向跟踪路由,查看返回的路径上是否有任何问题。当然,也不能保证路径都一样。
6.1不对称转发路径和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.881
上面的例子说明了什么问题?
拥堵发生在GBLX和Sprint的交界处。
这可能是由于正向或反向路径中的拥塞造成的。
两个AS退出政策不一致导致的拥堵非常普遍。
6.2多路互连
不对称路径可能出现在每一跳,尤其是在多条路径到达的节点。
第一跳(紫色):转折点是华盛顿DC
第二跳(红色):转折点是芝加哥IL
第三跳(绿色):转折点是加州圣何塞
可以看出,第三跳并不是由原路由返回的。如果芝加哥IL返回的路由出现拥塞,那么第三跳不会出现拥塞,因此可以看出Traceroute期间第二跳的延迟高于第三跳。
如果出现上述情况,如何排除故障?
假设你有多条Sprint的路径,但是Traceroute显示给你的是->:全局穿越->;冲刺,问题出现在第三跳的冲刺。
如何证明问题不在GX的道路上?
使用前面提到的/30掩码方法,用全局穿越的/30掩码找到对面IP,Traceroute作为SRC,那么可以保证返回路径是sprint->全局穿越;
同样的方法Traceroute另一跳路径;
对比两边的延迟,就能知道哪条路径有问题。
当然,/30掩码方法可能无法准确找到对端IP,这完全取决于路由配置。
思考:Traceroute为什么能保证设置源IP后第一跳的返回路径?
Traceroute的源IP是你的IP空之间的IP(比如环回),你在返回数据包的时候可以返回到任何接口。但是,如果在对面路由器的IGP中配置了带有/30掩码的IP,数据包将被强制返回到带有指定IP的接口。
七、对于等价路由情况下的问题分析 7.1 等价路由基于流的哈希算法可以保证相同的TCP/UDP数据流通过相同的路径。但是UDP/TCP Tracerroute探测包的目标端口不断增加,在路由器看来可能不是同一个数据流,这可能导致探测包采用不同的并行路径。
根据上图,Traceroute的结果可能与实际完全不同,应该是一个-->:B1->;C1-& gt;d或a->:B2->;C2-& gt;d,但结果可能是->:B1->;C2-& gt;d,这和拓扑学完全不一样。
例如:
ldn-bb2-link.telia.net(80.91.251.14)74.139 ms 74.126 ldn-bb1-link.telia.net(80.91.249.77)74.144 hbg-bb1-link.telia.net(80.91.249.11)89.773 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
这对正常的数据流是有好处的。基于流的哈希算法可以避免数据包的重组,但对于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 2 . 0 . 14版,-U可以不改变目标端口,-p指定目标端口)。
但是,应该注意的是,从Traceroute开始的路径不一定是实际数据包采用的路径。多路径的Traceroute可以通过对多个traceroute在目标IP上加1或减1来完成。
区分网络中数据流的策略有很多。三层网络通常根据源IP和目标IP来区分一个数据流。因此,固定目标端口和改变目标IP可以使探测包采取不同的路径,从而使Traceroute更加准确。
上图是我从实际环境中截取的包。
Gz-ganglia2执行到gz-ganglia1的Traceroute,并截获gz-ganglia1上的数据包。从上图可以看出,固定端口为55555,接收到多个TTL大于1的UDP数据包,这与Traceroute的原理有关。默认情况下,Traceroute每跳发送3个数据包,超时时间为5s,每三个数据包的TTL增加1,直到它在接收到ICMP目的地不可达数据包后停止发送数据包。
因此,在收到ICMP Dest不可达数据包之前,Traceroute仍然认为自己没有到达目标,继续发出数据包,因此目标主机可以接收TTL大于1的数据包。如果追踪路由从未接收到ICMP目的地不可达数据包,默认情况下,它将被发送到TTL=30以停止发送。
八、对于多协议标签交换(MPLS)追踪路由应该注意的问题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.822 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 over数据包应该由每一跳的路由直接返回给SRC。
但是,在MPLS ICMP隧道中,ICMP数据包在返回SRC之前会一直到达MPLS的出口,这导致MPLS上的所有跳的延迟几乎相同。
九.结论
一个看似简单的Traceroute包含了那么多网络知识,以至于有那么多因素让Traceroute无法正确嗅出网络拓扑,那么真的没有办法吗?
不会,巴黎Traceroute是一种新的Traceroute,可以更准确地嗅出网络拓扑,为网络故障排除提供更准确的依据。我学完巴黎traceroute再分享。
参考文献:
1.traceroute 2故障排除实用指南(正确)。使用巴黎追踪路线3避免追踪路线异常。RFC 1812 4。百度百科5。维基百科(一个基于wiki技术的多语言的百科全书协作计划ˌ也是一部用不同语言写成的网络百科全书ˌ 其目标及宗旨是为全人类提供自由的百科全书)ˌ开放性的百科全书
想知道
更多?
更深?
GOPS 2017北京站有更多专家分享
2017.7.28-7.29
1.《允许traceroute探测 没那么简单!网络故障排除神器 traceroute 探秘》援引自互联网,旨在传递更多网络信息知识,仅代表作者本人观点,与本网站无关,侵删请联系页脚下方联系方式。
2.《允许traceroute探测 没那么简单!网络故障排除神器 traceroute 探秘》仅供读者参考,本网站未对该内容进行证实,对其原创性、真实性、完整性、及时性不作任何保证。
3.文章转载时请保留本站内容来源地址,https://www.lu-xu.com/tiyu/1190684.html