首先，延迟与带宽没有直接关系。设备延迟数据包而不是拥塞链路的原因有很多。

您是否尝试过跟踪路由？如果您正在寻找 L3 边界作为可疑对象，这将显示跃点之间的延迟。

您还可以检查路径中是否有任何设备占用了大量 CPU/RAM。

如果这只是基于 LAN，您可以做一些事情来开始尝试找出导致这种情况的原因：

• Show process cpu history命令：如果 CPU 使用率非常高，那么您需要查看是哪个进程导致了这种情况，并且可能会用违规进程打谷歌。

• show debug command：我发现的一个常见原因是人们在交换机上运行调试命令。一个常见的最爱是 IP 会计留在已经过度使用的设备上。使用“undebug all”来摆脱调试。

• 重新启动它：可能不可能在白天，但使用“重新加载”命令在晚上或周末计时。您会惊讶于快速重启可以解决多少问题。

• 关闭中继端口- 如果它是 L3 交换机，我看到的另一个常见问题是使用此设备在 VLAN 之间进行路由的流量过多。如果可能，暂时关闭一些中继端口，看看这是否会减少延迟。

很高兴知道您的 ping 是低优先级的，在延迟方面以及在由 CPU 处理时也是如此。仔细检查您的 QoS 设置并确保没有导致这种情况的愚蠢错误也可能是一个好主意，尽管这种情况不太可能发生。

我使用 cacti 来监控带宽，并使用 openNMS 来监控延迟。如果您正在监控链接到此交换机的所有设备，您可能会看到使用情况和延迟之间的推论。（我知道你说这不是带宽问题，但你现在从来没有）我看到低端交换机在大量使用下下降，这会导致很多延迟。您是否有任何“哑巴”设备为该交换机供电，即使该交换机没有通过太多流量，这些设备也可能是下垂的来源。同样使用 cacti，您可以轮询 CPU 使用率，并且您可能会在延迟时看到峰值。

如上所述，MTR 或 Neotrace 也可用于密切关注情况，您可能会看到延迟开始的位置，这可能不是此开关本身。

如果 LAN 上没有发生这种情况，您可以限制“WAN 端口”吞吐量，这将强制使用更好的 TDM。在最大吞吐量的 80% 左右尝试一些东西，看看它是否有帮助。您可能需要根据终端数量进行调整。