1 Traceroute简介
Traceroute 是继 ping 之后使用最广泛的网络诊断工具之一，因为它简单且应用范围非常广泛。 traceroute 的可能应用范围从简单的网络错误诊断到揭示底层网络拓扑的大型扫描。然而，由于 traceroute 不是在考虑现代网络技术的情况下构建的，因此它在如今的网络环境中面临许多问题。这些问题通常表现为奇怪或错误的探测返回结果。这极大地影响了 traceroute 的网络诊断和分析能力，尤其是在大型网络中。在下文中，我们将逐步介绍traceroute的原理以及该工具在当前网路环境下面临的问题。
2 Traceroute原理
经典的 Traceroute 跟踪路由通过发送具有固定 TTL 的 ICMP 回显请求（即所谓的探测）来工作。 TTL 值通常从 1 开始，并在每次探测时递增。路径中的路由器在转发数据包时每一跳将 TTL 减一，如果 TTL 达到零，则发送回 ICMP TTL 超时错误。这样，traceroute 从它自己和目的地之间的每一跳都得到一条错误消息，其中包含每一跳的 IP 地址。通过在发送探测时减去接收到错误的时间，traceroute 还能够计算每一跳的 RTT。最后，当探测到达目的地时，traceroute 收到 ICMP 回显回复并停止。基本的 traceroute 消息流如下图所示：
现代跟踪路由变体还包括对 UDP 和 TCP 以及 IPv6 的支持。使用 UDP 或 TCP 时，与 ICMP 的唯一区别是从目的地接收到的数据包通常分别是 ICMP 端口不可达或 TCP RST 数据包。典型的例外情况是数据包被防火墙阻止或端口正在使用中，在这种情况下不会返回错误。
3 当前网络环境
当今互联网的规模相对于早期的网络来说已经扩大了非常多倍。因此涌现了非常多帮助提高网络承载能力和传输速度的技术，其中非常具有代表性的有负载均衡和 MPLS（多协议标签交换）。以下详细介绍。
3.1 负载均衡
负载均衡通常是在几个不同的链接或路径之间分配数据包。负载均衡机制通常分为三类，解释如下。
- Per-flow 负载均衡。Per-flow 负载均衡尝试根据所谓的流来分配数据包。流通常由相应数据包的 5 元组标识，即 IP 地址、协议和端口。这样做是为了使属于同一连接的数据包尽可能按顺序传送到目的地。
- Per-packet 负载均衡。Per-packet 负载均衡将每个数据包单独分布在可用的链路中。通常，数据包随机分布或以循环方式分布。其具有在路由器内部需要较少工作量的优点，但另一方面通常会给连接带来巨大的抖动，尤其是在不同路由长度不相等的情况下。 Per-packet 负载均衡 通常会给 traceroute 带来最多的问题，因为它具有随机性。
- Per-destination 负载均衡。 Per-destination 负载均衡根据数据包的目的地分配数据包。它与经典路由基本相同，通常对网络几乎没有影响。 Traceroute 通常完全不受每个目的地负载平衡的影响。
3.2 MPLS（多协议标签交换）
RFC 3031 中描述的多协议标签交换或 MPLS 用于在大型网络中有效地路由数据包，例如互联网。通常，每个路由器都必须根据 IP 报头中包含的信息做出自己的路由决策。由于 IP 地址在 Internet 中分布得非常广，通常需要路由器拥有非常大的路由表。此外，由于 IP 标头中只有少数字段（即源地址和目标地址以及 TTL）实际用于路由，因此引入了大量不必要的开销。 MPLS 使用自己的标头，它封装了原始数据包。这样，只有第一个路由器必须检查 IP 报头并为新报头中的数据包分配转发等价类或 FEC。这指定了被认为与路由决策等效的目的地。由于大多数目的地实际上可以组合成大块，因此相应的表可能非常小。随后的路由器能够根据 MPLS 报头中更短且更容易处理的 FEC 做出路由决策。由于 TTL 值可以在 IP 和 MPLS 标头之间来回复制，因此 MPLS 路由器也能够遵守原始数据包中设置的 TTL 值。此外，RFC 4950 允许在 MPLS 上下文中生成和使用 ICMP 数据包。因此，MPLS 路由器可能会提供对跟踪路由的基本支持。
4 Traceroute面临的挑战
以下是对最常见的跟踪路由异常及其具体行为的描述。对于每个异常，都会显示一个示例消息流，以及相应的输出。
4.1 匿名路由
这是最基本的异常，traceroute 输出中缺少一个或多个跃点。当路由器受防火墙保护或以其他方式配置为不生成 ICMP TTL 超出错误时，通常会发生这种情况。下图显示了此异常的示例消息流以及相应的输出。下面突出显示的三个星号，表示未收到相应调查的回复，是此异常的关键标志。
4.2 目的地无回应
另一个情况的异常是跟踪路由结果中缺少目的地。在这种情况下，traceroute 只是继续扫描，直到它达到最大探测 TTL 值或被另一个约束中断。一个例子是在一定次数的不成功尝试后停止。这种异常的一个特殊副作用是，输出末尾可能缺少任意数量的跃点。丢失目的地的常见情况是受防火墙保护的目的地。下图显示了此异常的示例。输出再次包含不成功探测的典型三个星号，然后继续直到达到最大 TTL。
4.3 错误的RTT值
这种异常通常有两个原因：非对称数据包路径或 MPLS 路由。当往返目的地的各自路径不对称时，即数据包在往返目标的不同路径上路由，往返时间可能无法反映数据包到达目的地所需的实际时间.由此产生的往返行程随后显示出误导性的价值。实际路径实际上可能比往返时间指示的更短或更长，具体取决于情况。下图显示了这样的场景，输出中突出显示了相应的时间。如果返回路径从较长的路径跳到较短的路径，traceroute 测量的 RTT 甚至会变得更短，即输出将显示最后一个链接的 TTL 负增长。
类似的结果发生在 MPLS 链路上，其中响应数据包必须行进到 MPLS 路径的末端，直到它返回到探测的发送者。由于纯 MPLS 路由器只知道数据包的下一跳，它们不能立即发回 ICMP 错误。相反，他们必须使用原始数据包所在的路径。这样做的结果是，所有数据包都首先传输到最后一个 MPLS 跃点。因此，traceroute 中显示的 MPLS 路径中各跳的往返时间都大致反映了最后一个 MPLS 路由器的往返时间。下图显示了此异常的示例。此异常的特征标志是跟踪路由输出中多跳的往返时间几乎相等，如下突出显示。
4.4 链接缺失
此异常意味着 traceroute 输出缺少链接，这些链接存在于实际拓扑中。通常的原因是负载平衡，在这种情况下，当所有数据包都在一条路径上路由时。下图显示了此异常的示例。另一个链接应该出现在输出中突出显示的两行中。
4.5 错误的链接
在这种情况下，traceroute 探测出的跃点之间存在错误链接。它通常发生在负载平衡链路中，此时一些数据包通过一条路径路由，而另一些数据包在另一条路径上路由。下图中显示了一个示例。错误链接显示在输出中突出显示的两行中。这种异常实际上是现代网络的一个巨大问题，特别是因为对于不了解实际拓扑的用户来说，它并不明显。因此，它可能会导致人们对网络或要解决的问题得出错误的结论。
4.6 路由循环
这是更复杂的异常之一，其中某些跃点丢失，而其他跃点显示多次，即数据包似乎在循环或圆圈中传播。最常见的循环情况是负载平衡用于不等长的路径。另一个例子可能是 MPLS 链接，最后一个 MPLS 路由器的地址用于 ICMP 错误，例如当中间路由器缺少 IP 地址时。一个罕见的例子是，当 TTL 为零的数据包被转发到下一跳时，例如由有故障的路由器。循环通常仅发生在负载平衡链路上，其中长度差异大于 1。下午描述了一个示例消息流。下面突出显示的两行显示了被探测两次的跃点。然而，相应的输出也可能是合理的，以防存在实际的转发循环或循环。
4.7 网状路径
网状路径属于最复杂的异常，其中显示了一些额外的链接，而其他链接则丢失了。这种异常只会在为一跳发送多个探测时发生。它通常是由负载平衡引起的，当有些探测在一个路径上转发，有些在其他路径上转发时会出现这种情况。这将导致 traceroute 输出完全混乱，真实拓扑和traceroute探测结果分别如下图所示。
5 可能的解决方法
以下是针对上面呈现的各种异常的几种解决方案。当然，这些解决方案在大多数情况下只能限制上述异常的影响。
5.1 Paris Traceroute
Paris traceroute 的开发是为了纠正在经典 traceroute 中发现的大部分缺陷，尤其是在负载均衡网络方面。 Paris traceroute 的显著特征是，它试图主动影响每流负载平衡链路中的路由决策。它通过仔细设置发送的探测数据包中的标头字段来实现这一点，每个流的负载平衡都会考虑这些字段。
- 相关论文：Multipath tracing with Paris traceroute
- 相关工具：https://paris-traceroute.net/download/
5.2 UDP和TCP探测包
traceroute 的现代变体还支持发送 UDP 或 TCP 探测，而不是 ICMP 回显请求，如前所述。由于大多数路由器和防火墙会阻止 ICMP 回显请求，因此大多数现代跟踪路由实现实际上默认使用 UDP。 UDP 探测的另一个优点是，它们不需要 root 权限即可在 Linux 系统上发送探测。 TCP 探测通常仅在非常特殊的情况下使用，通常是为了绕过限制非常严格的防火墙或穿越 NAT 网关。反对 TCP 的主要原因是它试图创建一个随后将状态引入网络的连接。此外，侦听 TCP 的应用程序比 UDP 更有多。事实上，为了更容易穿越防火墙，大多数实现都默认使用 TCP 端口 80。要清除挂起的连接，则需要一个额外的 TCP RST 数据包。总而言之，通过使用 UDP 或 TCP 而不是 ICMP 回显请求，匿名路由或丢失的目的地异常可能会有所缓解。
5.3 AS 号查找
可以从数据库中查询 AS 编号，例如RIPE 数据库，用于 IP 地址识别网络运营商，以及检测网络边界。在网络出现故障的情况下，此信息随后可能会用于联系管理员。还有一种现代算法，它将 BGP 信息与来自多个数据库的信息相结合，以产生更准确的结果。
5.4 MPLS标签解码
解码 MPLS 标签，即 FEC，在扩展的 ICMP 错误数据包中返回，如 RFC 4950 中所定义。它使诊断 MPLS 相关问题变得更加容易，并且还允许更准确地解释 traceroute 输出。如果怀疑存在与 MPLS 相关的异常，例如导致错误的往返时间或 MPLS 路由导致的环路，这将特别有用。
5.5 Reverse traceroute
反向跟踪路由技术用于跟踪数据包从远程源到本地主机所采用的路径。通过检查数据包返回路径，可以诊断出额外的网络问题，并且可以简化对现有输出的解释。这对于与不对称路径相关的异常尤为重要。有一个提案实际上可以在没有目标系统交互的情况下实现这一点。但是，它需要使用记录路由或 RR IP 选项，记录数据包经过的跳数。这样做是为了记录每个数据包的返回路径。 RR 选项被发明为 traceroute 的替代方案，但由于它需要各个路由器的交互，因此通常不受支持并被放弃。它也只能在两个方向上记录 8 跳，这就是为什么该方法需要目标和本地主机之间的多个主机，即所谓的“有利位置”。因此，该方法对于没有必要资源的用户来说是不可行的。最后，有必要在发送的探测中伪造源 IP 地址以将响应重定向到所述主机，这被大多数路由器阻止。
6 参考文献
Jobst M E. Traceroute anomalies[J]. Network, 2012, 9.