[转]Traceroute网络排障实用指南（2）

五、优先级与限速

5.1 Traceroute延时判断影响因素

Traceroute延时包括三点：

1. 探测包到达一个特定路由器的时间

2. 路由器生成IPMI TTL Exceed的时间

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

第一个和第三个时间都是受实际网络情况影响的，而第二个时间不是。能够对网络问题的判断起到帮助作用的仅仅只有第一个和第三个时间，第二个时间往往起到误导的作用。

5.2 路由器工作原理

路由器有转发（data-plane）和接收（control-plane）的功能。

路由器转发包有两种模式：

1. Fast Path：硬件实现转发源包（几乎所有的网络的数据包）

2. Slow Path：软件实现处理“异常”包（IP Options， ICMP generation <--Traceroute发生在这里）

路由器能够接收直接发送到路由器上绑定的IP的包，接收的包可以是BGP、IGP、SNMP、CLI访问（telnet/ssh）、ping等；但是，路由器的CPU性能是比较差的。一个320-640+Gbps背板的路由器，却只有一个单核600MHz MIPS CPU，通常CPU用来做其他事而不是做Traceroute，因此ICMP Generation在路由器看来优先级较低，大多数情况下更是有速度限制和降级的处理。

1. 降级

在一些常见的路由器平台上，Slow path中的转发与接收是公用资源，同时没有使用最好的软件调度器。因此一些控制性的数据处理比如BGP churn、CLI等会消耗CPU资源，使得ICMP TTL Exceed包的产生延迟。

2. 限速

大部分路由器会限制他们的ICMP包产生，不同厂商会有不同的并且不可设置的限速值，这大大影响了Traceroute的效果，特别是在很多用户同时使用MTR时。

例子

Foundry MLX/XMR：Hard-coded limit of 400pps per interface.

Force10 E-series：Hard-coded limit of 200pps or 600pps per interface.

5.3 排除假延时

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

下面例子中第二跳并没有问题

1 ae3.cr2.iad1.us.nlayer.net 0.275ms 0.264 ms 0.137 ms

2 xe-1-2-0.cr1.ord1.us.nlayer.net 18.271 ms 68.257 ms 18.001 ms

3 tge2-1.ar1.slc1.us.nlayer.net 53.373 ms 53.213 ms 53.227 ms

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

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

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

六、非对称的转发路径

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

6.1 非对称转发路径与AS边界

非对称路径通常是在AS边界开始的。为什么？那是因为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.892 ms

sl-bb20-dc-15-0-0.sprintlink.net(144.232.15.0) 101.888 ms 101.876 ms 101.890 ms

上面例子中有什么问题？

1. 在GBLX和Sprint的边界出现拥塞；

2. 可能是由于正向或反向路径出现拥塞。

由于两个AS出口策略不一致造成的拥塞是很常见的。

6.2 多路径互联

非对称的路径可出现在每一跳，特别是有多条路径到达的节点。

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

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

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

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

如果出现以上情况时，该如何去排查问题？

假设如下的情况，你有多条路径可到达Sprint，但Traceroute显示You->Global Crossing->Sprint，并且问题出现在第三跳的Sprint。

如何证明问题不是出现在GX这边的路径？

1. 使用之前提到的/30掩码方法，使用Global Crossing的/30掩码找到对端IP，并作为SRC进行Traceroute，那么就能保证返回路径为Sprint->Global Crossing；

2. 同样的方法Traceroute另外一跳路径；

3. 两边的延时对比后，就知道哪条路径出现问题。

当然/30掩码方法不一定能够准确找到对端IP，这完全取决于路由的配置。

为什么Traceroute设置源IP后能够保证第一跳的返回路径？

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

七、等价路由

7.1 等价路由

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

以上图来说，Traceroute的结果可能与实际完全不同，正常应该是A -> B1 -> C1 -> D或A -> B2 -> C2 -> D，但结果可能是A -> B1 -> C2 -> D，这跟拓扑完全不一样。

例如：

6 ldn-bb2-link.telia.net (80.91.251.14) 74.139 ms 74.126 ms

  ldn-bb1-link.telia.net (80.91.249.77) 74.144 ms

7 hbg-bb1-link.telia.net (80.91.249.11) 89.773 ms

  hbg-bb2-link.telia.net (80.91.250.150) 88.459 ms 88.456 ms

8 s-bb2-link.telia.net (80.91.249.13) 105.002 ms

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

上图是我从实际环境截获的包。gz-ganglia2向gz-ganglia1进行Traceroute，在gz-ganglia1上截包，从上图能够看到固定端口为55555，且收到多个TTL大于1的UDP包，这跟Traceroute的原理有关，Traceroute每跳默认发3个包，超时时间为5s，每三个包TTL增加1，直至收到ICMP Dest Unreachable包后停止发包，故在收到ICMP Dest Unreachable包之间，Traceroute还是认为没有到达目标，仍然继续发包，故目标主机可以收到TTL大于1的包。若Traceroute一直没有收到ICMP Dest Unreachable包则默认会一直发到TTL=30停止发送。

八、多协议标签交换（MPLS）与Traceroute

8.1 MPLS ICMP隧道

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

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

1. te2-4.ar5.PAO2.gblx.net (69.22.153.209) 1.160 ms 1.060 ms 1.029 ms

2. 192.205.34.245 (192.205.34.245) 3.984 ms 3.810 ms 3.786 ms

3. tbr1.sffca.ip.att.net (12.123.12.25) 74.848 ms 74.859 ms 74.936 ms

4. cr1.sffca.ip.att.net (12.122.19.1) 74.344 ms 74.612 ms 74.072 ms

5. cr1.cgcil.ip.att.net (12.122.4.122) 74.827 ms 75.061 ms 74.640 ms

6. cr2.cgcil.ip.att.net (12.122.2.54) 75.279 ms 74.839 ms 75.238 ms

7. cr1.n54ny.ip.att.net (12.122.1.1) 74.667 ms 74.501 ms 77.266 ms

8. gbr7.n54ny.ip.att.net (12.122.4.133) 74.443 ms 74.357 ms 75.397 ms

9. ar3.n54ny.ip.att.net (12.123.0.77) 74.648 ms 74.369 ms 74.415 ms

10.12.126.0.29 (12.126.0.29) 76.104 ms 76.283 ms 76.174 ms

11.route-server.cbbtier3.att.net (12.0.1.28) 74.360 ms 74.303 ms 74.272 ms

为什么会这样？

根据Traceroute原理ICMP TTL Exceed包应该是由每一跳的路由直接返回给SRC。

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

九、结语

一个看似简单的Traceroute里面包含如此多的网络知识，有那么多的因素导致Traceroute无法正确嗅探出网络拓扑，那么是否真的没有办法？不是的，Paris Traceroute就是一种新式的Traceroute，它能够更加准确的嗅探出网络拓扑，为网络排障提供更加准确的依据。等我研究完了Paris traceroute再做分享。

参考文献：

1. A Practical Guide to (Correctly) Troubleshooting with Traceroute

2. Avoiding traceroute anomalies with Paris traceroute

3. RFC1812

4. 百度百科

5. 维基百科