我要投搞

标签云

收藏小站

爱尚经典语录、名言、句子、散文、日志、唯美图片

当前位置:四肖中特 > 反向掩码 >

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

归档日期:04-26       文本归类:反向掩码      文章编辑:爱尚语录

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

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

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

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

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

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

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

  如果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下不可见;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  该延时由光信号或电磁信号在介质中的传播速度与距离决定。光速(线km/s,但光纤是由玻璃制作,非真空,故光在光纤内传播速度较线km。

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

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

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

  五、对于网络优先级与限速相关故障的问题分析 5.1 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时。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文链接:http://pebeducation.com/fanxiangyanma/212.html