路由器的exception行为

如果您正在ping路由器本身，那么您正在与IOSpipe理平面进行交互。 所以操作系统需要被唤醒并响应你的ICMP查询。 如果您有两个不同的平台（1700和1905），可能具有不同的版本和function集以及不同的configuration以保持繁忙，您应该期望获得不同的结果。 转发服务器之间的stream量，使用路由器转发平面，可能会得到硬件的帮助，将变化不大。

所有人都说，你为什么还要在这几毫秒内感兴趣？ 难道你没有更重要的事情要担心;-)

尝试使用ping来查找networking中的延迟发生在什么情况下最多是棘手的。 最糟糕的是，不可能的。 在最好的情况下，你只需要考虑路由器响应ping的事实与路由器从一个接口向另一个接口发送ping数据包的速度完全无关（大多数路由器以接近最低优先级的方式响应ping，所以ping响应时间往往会有很大的变化，通常远远高于转发时引入的延迟）。

你所看到的0.7毫秒可能可以解释为1905年有更多的空间CPU周期比1700年。

使用traceroute（或类似的）查找连接通过networking的path可能是有用的，然后检查中间跳跃的stream量级别。 但是，这只会揭示路由点引入的延迟。 交换机和路由器可能会减速。 总体来说，3毫秒可能不是一个太大的问题，如果是的话，可能还有其他方法来减轻这个问题。 在过去，当FE / BE延迟增加了几毫秒时，我发现（某些）OLTP应用程序变得缓慢，但是确保它们可以有多个未完成的查询处理了很多事情（并行查询而不是严格的序列化）。 我想说更常见的是不同的延迟通常比常量（尽pipe可能更高）的延迟导致更多的问题。

除了诊断一般连接以外，不要使用ping到Cisco路由器接口。 对ICMP消息的响应是（并且一直是）框的最低优先级。 从最小的路由器到最大的路由器都是如此，并被叫出来。 Ping通 – 路由器到其他东西（即某种主机）。 这不仅是思科路由器，而且还有其他很多。

唯一的例外是使用SLA监视，SLA监视是一组运行在更高优先级的function来衡量给定链接的延迟。 虽然这是一个非常不同的动物ping ping路由器接口。