在典型的 IP 基础设施中无法跟踪数据包的路由。它有一个实验性的扩展，但从未广泛实施。

那么traceroute实际上是做什么的，它会发送增加TTL的探针并寻找超时消息。

因此，在每个数据包负载平衡的基础结构中，traceroute 将能够告诉您它找到的每个路由器沿路径有多远，但它无法判断它是否在跃点“n”和路由器上找到了路由器它发现在“n+1”跳处的路径相同或不同。

每个数据包的负载平衡很少使用，大多数负载平衡是基于“流”完成的，因为在流中重新排序数据包通常会导致性能下降。流的特点是一些头部字段的组合，通常是源/目标 IP 和源/目标端口。

在按流负载平衡的环境中，可以获得有用的跟踪路由，但您必须小心使用的跟踪路由实现。为了获得自洽的跟踪，traceroute 实现必须确保相关的报头字段保持一致，以便所有数据包都被视为同一流的一部分。

我记得一个演示文稿（认为这是一个 uknof 视频），其中提到了一个 traceroute 监控工具，该工具能够跨多个跟踪跟踪一致的源端口并报告哪些路径有问题。看起来视频是https://www.youtube.com/watch?v=jqaiXtBF4ug，工具是“fbtracert”

使用负载平衡干线，硬件需要保持流有序 - 高带宽流中的无序接收通常会导致高性能损失。因此，基本上，负载平衡适用于流，而不是逐个数据包。

Traceroute 使用自己的“流”（ICMP 或某些 UDP 端口），它可能遵循或不遵循与您正在分析的流相同的路径，因此它可能会向您显示完全不同的路由。

由于traceroute实用程序通常是如何工作的（通过发送一系列具有不断增加的 TTL 的 ping 数据包，然后监视响应数据包），您会发现该实用程序可能不会像每个连续的数据包一样为您提供非常可靠的信息发送的traceroute可能在真正的“按数据包”负载平衡网络中采用不同的路径通过网络（请注意，这些很少见）。

如果您确实需要一个实用程序来跟踪单个数据包通过网络的路由，您可以尝试RECORD_ROUTE使用ECHO_REQUEST. 记录RECORD_ROUTE标志请求任何中间路由主机将它们的“跃点”添加到 IP 标头中的路由。

注意：此路由记录的 ​​IP 标头空间有限，因此只会记录大约 9 跳。 另请注意，并非所有路由主机都可能在回显请求上支持此标志，但如果使用是在您的内部网络上（有限数量的跃点）并且您的设备确实记录了跃点（您会知道）。然后它可以成为一个有用的工具。

检查ping您选择的平台/操作系统的手册页，但在我的 Mac（和大多数 Linux 发行版）上，它就像这样简单：

ping -R -c 1 <dest-ip-address>