☰

请解释一下此跟踪路由

tag-icon • tag-icon networking router switch meraki
请解释一下此跟踪路由

什么可能导致中间两个 RTT 超时。这种情况每次都会发生。用户报告远程站点的网络访问速度很慢。我们已经联系了 Meraki，他们没有发现任何问题。我们已经更换了电缆。我们已经联系了 ELAN 的 ISP（没有问题）。我们已经重新启动了堆栈。这些跟踪路由是在网络上没有用户的情况下执行的。通常办公室里大约有 15 个用户。

主机1 Windows 10

Host2 服务器 2019

第 3 层交换机 Meraki MS250-48FP 当前固件

Host1 的 IP 是 10.10.1.80，直接插入到 switch2

Host2 的 IP 是 10.0.0.20，直接插入到 switch1

ELAN 连接 172.16.255.2 直接插入交换机 2 (10.10.1.1)

ELAN 连接 172.16.255.1 直接插入交换机 1 (10.0.0.1)

10.10.1.1 switch2 路由 10.0.0.0/24 下一跳 172.16.255.1

10.0.0.1 switch1 路由 10.10.0.0/16 下一跳 172.16.255.2

主机 1 (10.10.1.80) <--Cat5--> (10.10.1.1) 交换机 2 (172.16.255.2) <--ELAN--> (172.16.255.1) 交换机 1 (10.0.0.1) <--Cat5--> 主机 2 (10.0.0.20)

From 10.10.1.80

tracert 10.0.0.20

Tracing route to 10.0.0.20 over a maximum of 30 hops:

  1     1 ms     *        1 ms  10.10.1.1
  2    26 ms     *       26 ms  172.16.255.1
  3    27 ms    26 ms    26 ms  10.0.0.20

Trace complete.

From 10.0.0.20

tracert 10.10.1.80

Tracing route to 10.10.1.80 over a maximum of 30 hops

  1    <1 ms     *       <1 ms  10.0.0.1
  2    27 ms     *       27 ms  172.16.255.2
  3    27 ms    27 ms    27 ms  10.10.1.80

Trace complete.

答案1

什么可能导致中间两个 RTT 超时。

最可能的原因包括：

  • 这些跳数限制了 ICMP超出时间消息
  • 数据包在到达跳跃点的过程中丢失（当后续跳跃没有问题时，这种情况不太可能发生）
  • ICMP 消息在返回途中丢失（这种情况不太可能发生，但在任何地方发生 ICMP 抑制时都有可能发生）

简而言之，traceroute这并不是一个诊断数据包丢失的好工具。

更好的替代方案是：

  • 检查中间交换机是否因链路问题（接口统计信息中的接收失败）、拥塞（接口统计信息中的帧丢失）或 STP 重新收敛（事件日志）而导致帧丢失。当任何地方发生严重帧丢失时，触发 SNMP 陷阱通常是一个好主意。
  • 检查中间路由器是否有数据包丢失（类似上面）。
  • 使用 Netflow 或 sFlow 检查整体流量和单个流量。

用户报告远程站点的网络访问速度很慢。

当中间有另一个网络（你无法控制）时，事情会变得有点困难。你可以尝试使用pathping或traceroute 外部VPN 隧道（ISP 切换之间），或者您可以随隧道一起运行诊断流（通常不需要使用高带宽）。UDP 是一个不错的选择，因为它不会通过重新传输来隐藏任何损失。测试通过由于隧道只有一跳，因此隐藏了大量信息。

如果两个网站使用同一个 ISP，您可以收集一些数据并联系支持人员。如果您使用不同的 ISP，就很难指责对方。

相关内容