从Traceroute看网络问题

traceroute送出一个TTL是1的IP 数据包到目的地，当路径上的第一个路由器收到这个数据包时，它将TTL减1。此时，TTL变为0，所以该路由器会将此数据包丢掉，并送回一个「ICMP time exceeded」消息（包括发IP包的源地址，IP包的所有内容及路由器的IP地址），traceroute收到这个消息后，便知道这个路由器存在于这个路径上，接着traceroute再送出另一个TTL是2 的数据包，发现第2 个路由器......

traceroute每次将送出的数据包的TTL 加1来发现另一个路由器，这个重复的动作一直持续到某个数据包 抵达目的地。当数据包到达目的地后，该主机则不会送回ICMP time exceeded消息，一旦到达目的地，由于traceroute通过UDP数据包向不常见端口(30000以上)发送数据包，因此会收到「ICMP port unreachable」消息，故可判断到达目的地。

一、Traceroute原理及问题

[1490343639444_1534_1490343639563.png]

[1490343662300_3600_1490343662384.png]

使用GNS3模拟器抓包分析，实验拓扑：

[1490343698186_962_1490343698250.png]

在路由器:R5上traceroute 192.168.3.10

[1490343776222_8778_1490343776424.png]

通过Wireshark抓包分析：

[1490343797993_2588_1490343798095.png]

看第9个数据包192.168.5.2使用UDP协议请求192.168.3.10大于30000不存在的端口，当src收到ICMP Dest Unreachable包时停止traceroute。

[1490343816984_3397_1490343817148.png]

第10个包192.168.3.10回ICMP Dest Unreachable包

[1490343838713_286_1490343838892.png]

问题：为什么不是显示192.168.2.1 192.168.3.1？

[1490343880293_7539_1490343880558.png]

解答：你无法从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文档的定义。

延时计算

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

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

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

路由器不对包的时间做任何处理，只是单纯的转发数据； 延时计算的是包的往返时间，但Traceroute显

[1490532900712_7647_1490532901042.png]

示的是去的路径上所经过的路由。

二、Traceroute中的DNS反向解析

Traceroute提供了比较多的信息，可以通过这些信息进行问题排查

[1490343941007_7161_1490343941221.png]

[1490533046475_2284_1490533046805.png]

从东京到美国绕欧洲过去，那就不太理想了。 从印度到美国要300ms，但从日本到美国并不需要300ms。

DNS中包含的接口信息：

[1490343988135_772_1490343988386.png]

[1490344027999_1324_1490344028290.png]

很多网络都会尝试将接口信息放在DNS，需要注意的是： 接口信息通常是帮助他们排查自己网络的问题； 接口信息有可能不是最新的。虽然很多大型网络会自动产生DNS，但其余的不会； 可以帮助你识别接口的类型，通过接口类型甚由器的型号。

例如：xe-11-1-0.edge1.NewYork1.Level3.net

xe-11-1-0是Juniper 10GE端口，该设备至少有12个板卡槽；至少一台40G/板卡槽的路由器，因为它有一块10GE板卡在板卡槽1。

[1490344078210_1867_1490344078253.png]

[1490344106418_8873_1490344106517.png]

边界的变化：

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)

路由的变化：

4 po2-20G.ar5.DCA3.gblx.net (67.16.133.90)

5 cogent-1.ar5.DCA3.gblx.net (64.212.107.90)

问题：想知道路由是否同时属于两个AS，使用/30掩码方法 两个路由器之间一般是点到点，为了省IP配置/30。

[1490344133088_4748_1490344133258.png]

三、延时

[1490344167882_4831_1490344167981.png]

串行延时产生原因：一个数据包被移动到网络上的时候是一个不可分的单元；在一个数据包传输完毕之前另外一个数据包无法发送。

队列延时

在高速网络中该延时非常小：

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

利用率

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

排队

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

[1490344271702_141_1490344272004.png]

在美国本土传播耗时220ms，延时不正常。

四、路由跟踪

Traceroute每一跳延时计算：

1. 探测包到达一个特定路由器的时间
2. 路由器生成IPMI TTL Exceed的时间

3.ICMP TTL Exceed返回到SRC的时间

第一个和第三个时间都是受实际网络情况影响的，而第二个时间不是。能够对网络问题的判断起到帮助作用的仅仅只有第一个和第三个时间，第二个时间生成涉及到路由器的CPU，第二个时间往往起到误导的作用。 其中经过的路由器是不会对时间戳做任何处理。

[1490344314314_9498_1490344314449.png]

如何排查假延时？

[1490344338171_7712_1490344338215.png]

最重要的一个规则：如果在某一跳中发生问题，那么所有后续跳的延时将会持续或增长。

影响耗时的因素 ?

1.通常是路由器的限速与优先级问题；

2.最坏情况是路由器回包过程中走的路径不同导致的（非对称转发路径）

[1490344765304_6375_1490344765610.png]

第一跳（紫色）：折回点为Washington DC

第二跳（红色）：折回点为Chicago IL

第三跳（绿色）：折回点为San Jose CA

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

如何排查？

[1490344844197_1406_1490344844525.png]

等价等长路由

[1490344886691_7199_1490344886818.png]

等价不等长路由

[1490344936974_6476_1490344937179.png]

Loop产生原因：路由器错误传递，将TTL=0的包传到下一跳; NAT路由器，会将源IP地址重写，导致NAT后面的跳数看上去都是NAT那个IP。

如何避免？

[1490344978885_2899_1490344979165.png]

利用Traceroute强大的参数设置，固定目标端口不变，就能够Traceroute出同一条路径了（Traceroute 2.0.14版本，-U可固定目标端口不变，-p指定目标端口）。但是需要注意Traceroute出来的路径不一定是实际数据包走的路径。可以通过目标 IP加1或减1进行多次Traceroute来完成多路径的Traceroute。网络中区分数据流的策略很多，三层网络通常是根据源IP、目标IP来区 分一个数据流，因此固定目标端口，更改目标IP能够让探测包走不同的路径，从而让Traceroute更加准确。

MPLS ICMP隧道 ：很多大型网络都有运用MPLS，有些路由器只根据MPLS的标签进行转发而没有IP路由表，当ICMP包产生时问题就出现了，这些路由器要怎么去转发这些ICMP包？其中一种解决方案是MPLS ICMP隧道。 当一个ICMP包产生并打上标签时，路由器会根据标签交换路径（LSP）转发表将ICMP包转发至下一跳，这会导致Traceroute的结果看起来非常奇怪，你会看到中间很多跳的延时会跟某一跳的延时是一样的

[1490345024465_119_1490345024694.png]

根据Traceroute原理ICMP TTL Exceed包应该是由每一跳的路由直接返回给SRC。 但是，在MPLS ICMP隧道中，ICMP包会一直走到MPLS的出口才会返回给SRC，这就造成在MPLS上的所有跳的延时都是几乎一样的。 其实这里还会引申出一个问题，那就是跳数缺漏。