我可以在交换机中观察到哪些内容以查找延迟源？
注意：这与负载无关。所有链路带宽使用情况正常且不受影响，大多数链路都非常正常利用不足。另外-监视是报告延迟的设备的本地操作，因此此处没有WAN因素。
#1 楼
首先，延迟不直接与带宽相关。除了拥塞的链路之外，设备为什么会延迟数据包还有很多原因。您是否尝试了traceroute？如果您正在寻找L3边界作为可疑对象，这将向您显示跃点之间的等待时间。
您还可能会检查路径中是否有任何设备使用了大量的CPU。 / RAM。
评论
我同意Mierdin的观点，也建议MTR在这种情况下连续运行traceroute。 Wikipedia链接：en.m.wikipedia.org/wiki/MTR_（软件）
–布雷特·莱金斯（Brett Lykins）
2013年6月27日22:26
@Mierdin-感谢您的反馈，因此这里没有L3因素，traceroute最初显示的响应时间约为500毫秒，然后是260毫秒，然后是76毫秒到达设备-这些是针对每次尝试同一单跳而不是多次酒花。请参阅我对MikePennington的评论，以获取有关CPU的信息。
– A L
2013年6月28日15:57
#2 楼
如果这只是基于LAN，则可以执行一些操作以尝试找出导致此问题的原因：显示进程cpu历史记录命令：如果CPU使用率非常高，那么您需要查看导致此问题的进程，并可能用令人反感的进程打谷歌。常见的偏爱是将IP记帐保留在已经过度使用的设备上。使用“全部撤消调试”摆脱调试。您会惊讶于快速重启可以解决多少问题。
关闭中继端口-如果是L3交换机，我看到的另一个常见问题是使用此设备在VLAN之间进行路由的流量过多。如果可能，请暂时关闭某些中继端口，以查看这是否会减少延迟。
请注意，就延迟以及在由CPU处理时，您的ping优先级较低。最好再次检查您的QoS设置，并确保没有愚蠢的错误导致这种情况，这是一个好主意，这是不太可能的。
评论
很好的反馈，我已经检查了show debug，目前无法重启。
– A L
13年6月28日在16:05
#3 楼
我使用仙人掌来监视带宽，并使用openNMS来监视延迟。如果您正在监视链接到此交换机的所有设备，则可能会看到使用情况和延迟之间的必然关系。 （我知道您说这不是带宽问题，但您从未如此）我已经看到低端交换机在大量使用情况下会下垂，这会导致大量延迟。您是否有任何“笨拙”的设备为该交换机供电，即使该交换机没有通过太多流量，也可能是该信号的来源。同样，使用仙人掌，您可能可以轮询CPU使用率，并且在等待时间时可能会出现峰值。如上所述，MTR或neotrace对监视情况也很有用，您可能会看到延迟从何处开始，而这可能不是此开关本身。
#4 楼
如果在局域网上没有发生这种情况，则可以限制“ wan port”吞吐量，这将强制执行更好的TDM。尝试最大吞吐量的80％左右，看看是否有帮助。您可能需要一周时间，具体取决于终端的数量。评论
据我了解，OP在注释中已明确说明，这与负载无关。
–user36472
17年2月2日在13:20
评论
假设这是一台Cisco IOS交换机...请为具有较高ping时间的交换机发布show proc cpu历史记录。如果该CPU始终处于较高状态，或定期出现较高变化，请运行show proc cpu sort是仅对交换机控制平面的延迟，还是在ping交换机后面的内容时得到相同的延迟？
@MikePennington-imgur.com/a/gfX9q#0-这非常酷！看起来它的峰值一直都很高，尽管平均来说很低..
@Ytti-并非要将此内容发布在单独的行上。 cp <-> cp从分发到访问的响应实际上很低，或者至少是在我测试时。从访问级别端口到访问层交换机上的设备，我们看到了极高的延迟。
@ user1353，谢谢。您发布的imgur不够稳定，无法导致该交换机上CPU的ping时间持续增加