当遇到网络问题,通常会用Traceroute去排查,但Traceroute是什么?
根据百度百科定义,Traceroute是一种电脑网络工具,它可显示数据包在IP网络经过的路由器的IP地址。
Traceroute有三大特点:
但使用Traceroute并根据路由跟踪情况就能排查出问题?答案是否定的。
使用Traceroute并根据路由跟踪情况也不能排查出问题,到底是怎么回事?
注:延时计算的是包的往返时间,但Traceroute显示的是去的路径上所经过的路由,在包返回过程中产生的时延也会影响你的测试结果。
注:值得一提的是在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的一个非常重要的一个方面。
在Traceroute中的DNS反向解析我们能够获取到以下信息:
对于推断问题原因,以上信息显得尤为重要。
为什么我们需要知道地理位置?
我们常用的帮助识别位置信息的有:
很多网络都会尝试将接口信息放在DNS,需要注意的是:
例子:xe-11-1-0.edge1.NewYork1.Level3.net
常见接口类型对照表:
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-#-#-#.### |
知道路由器角色是非常有用的,但每个AS都不一样,使用不同的角色命名,并且他们也不会一直遵循自己的命名规则。
总的来说,你只能通过你的网络知识去猜路由器的角色。
通常来说有以下规律:
识别网络自治系统边缘很重要:
识别网络自治系统的关系同样有所帮助:
有时能够看到反解域名的明显变化:
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路由器将属于两个自治系统)。
三种主要网络延时:
该延时产生在转发数据包的时候,产生原因:
在高速网络中该延时非常小
1. 利用率
1G的接口跑到500Mbps我们会说利用率是50%,但实际上,一个接口只能进行转发数据(100%利用)或者不能转发数据(0%利用),故所谓的50%利用率实际上是指1s内有0.5s用来了传输数据。
2. 排队
当一个接口在被使用,下一个包必须排队等待被发送。通常来说,一个接口90%使用率等于将要转发的包90%都在排队。当一个接口达到饱和时,排队时间将迅速增加,当一个接口过饱和时,一个包排队可能要耗费几百甚至几千毫秒,排队延时通常与拥塞程度相关联。
该延时由光信号或电磁信号在介质中的传播速度与距离决定。光速(真空状态下传播)约为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.570ms4 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] 8ms 8ms 8ms6 tbr2.wswdc.ip.att.net (12.122.16.102) [MPLS: Label 32760 Exp 0] 8ms 8ms 8ms7 ggr3.wswdc.ip.att.net (12.122.80.69) 8ms 8ms 8ms8 192.205.34.106 [AS 7018] 228ms 228ms 228ms9 te1-4.mpd01.iad01.atlas.cogentco.com (154.54.3.222) [AS 174] 228ms 228ms 228ms |
---|
在美国本土传播耗时220ms,延时不正常。