尽管有 ntp，为什么我的一个开关关闭了两分钟？

Question

我只是偶然地注意到，我的一台 Cisco 4500 交换机的时钟出错了：尽管 ntp 看似正常，但它还是落后了 2 分钟以上。在我看来，对于所涉及的系统来说，即使是一秒钟也不应该被认为是可以接受的。此外，如果我没有将它与简单的挂钟进行比较，我就不会注意到与诊断的区别。

一些细节

这是我的一些主机（10.0.99.1、10.0.99.2、10.0.1.119、10.0.99.241）的 ntp 信息，它们部分地相互引用以进行后备，但主要最终都应该通过与 10.0.0.1 同步，这再次拉动时间从外面。所以时间差异不可能是由不同的原始时间源造成的。由于观察结果使我有些偏执，因此“具有正确的时间”的方式如下show clock：（或date）产生与我的挂钟和本地系统时钟（根据http://time.is很好）匹配的输出肯定低于 1 秒的错误（我在观看本地时钟时按 ENTER 的准确性）

10.0.1.119 (Ubuntu) 时间正确

$ ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+10.0.99.1       10.0.0.1         3 u  855 1024  377    0.904   -2.658   0.113
*10.0.0.1        130.149.17.8     2 u  266 1024  377    0.253    0.909   0.127

10.0.99.241 (Cisco 2960) 有正确的时间

#sho ntp associations 

  address         ref clock       st   when   poll reach  delay  offset   disp
*~10.0.99.1       10.0.0.1         3     28     64   377  1.462  85.288 19.758
+~10.0.99.2       10.0.1.119       4     29     64   377  1.297  83.515  5.369
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

10.0.99.2 (Cico 4500) 时间正确

#sho ntp associations 

  address         ref clock       st   when   poll reach  delay  offset   disp
+~10.0.99.1       10.0.0.1         3      6   1024   111  1.148  -1.618 42.875
*~10.0.1.119      10.0.0.1         3     31   1024   377  0.043   1.687  1.064
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

10.0.99.1 (Cisco 4500) 落后大约 2 分 6 秒

#sho ntp associations 

  address         ref clock       st   when   poll reach  delay  offset   disp
*~10.0.0.1        130.149.17.8     2    274   1024   377 15.625   3.681 30.403
+~10.0.99.2       10.0.1.119       4    415   1024   376 15.625   0.855 33.276
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

#sho ntp status 
Clock is synchronized, stratum 3, reference is 10.0.0.1      
nominal freq is 250.0000 Hz, actual freq is 249.9988 Hz, precision is 2**6
reference time is DAD8B428.54C6BAEA (20:36:24.331 MESZ Sat May 7 2016)
clock offset is 3.6818 msec, root delay is 32.80 msec
root dispersion is 71.74 msec, peer dispersion is 30.40 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000004720 s/s
system poll interval is 1024, last update was 683 sec ago.

问题

1. 为什么 10.0.99.1 离我们这么远？
2. 为什么同步到 10.0.99.1 的系统是正确的？
3. 我应该如何从sho ntp status10.0.99.1的输出中了解到时钟实际上完全不同步（与 中提到的所有主机和参考时钟相比sho ntp asso）？对我来说，输出看起来完全像是一个非常精心设计的“我很高兴”。

---

编辑：根据大众需求，输出sho clock detail

10.0.99.1

#sho clock detail 
13:06:38.605 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016

10.0.99.2

#sho clock detail 
13:10:54.083 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016

Answer 1

我有点不愿意将其作为答案发布，因为最初的原因仍不清楚。尽管如此，问题似乎已经解决了——至少目前是这样。

根据htm11h的评论，我决定更新固件。事实上，现在我正在使用较新的固件运行，时钟似乎与正确的时间相匹配。

但这是否意味着新固件就是解决方案？很不幸的是，不行。在我第一次尝试加载新固件时，我忘记更改配置寄存器，该寄存器仍处于出厂默认状态。因此，我的第一次重新启动最终会出现在路由器运行了近四年（即自首次开机以来）的相同原始 ROM 映像中。然而，这足以让时钟进行一次巨大的调整，然后保持同步。这表明仅仅重新启动可能会有所帮助——暂时的。反过来，这意味着新固件显示的当前正确时间在未来几年可能仍会偏离 ntp 时间。我需要几天的时间才能确定时钟是否每天慢了 5 秒......

目前，此案已结案。