我只注意到我的一台Cisco4500交换机出现了错误：即使看起来function正常的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：//时间。是 ）有一个错误肯定低于1秒（我在看我的本地时钟的同时击中ENTER的准确性）
$ 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
#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
#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
#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.
sho ntp status输出中了解到时钟实际上完全不同步（与sho ntp asso提到的所有主机和参考时钟sho ntp asso ）？ 对于我来说，输出看起来完全像一个非常复杂的“我很高兴”。 编辑：受欢迎的需求， sho clock detail的输出
#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
#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
我有点不愿意发表这个答案，因为原来的原因还不清楚。 不过，这个问题似乎已经解决了 – 至less现在是这样。
根据htm11h的意见，我决定更新固件。 事实上，现在我正在运行一个新的固件，时钟似乎匹配正确的时间。
但这是否意味着新的固件是解决scheme？ 很不幸的是，不行。 在我加载新固件的第一次尝试中，我忘了更改configuration寄存器，它仍然是出厂默认值。 因此，我的第一次重新启动结束在路由器已经运行了近四年（即，从它的初始开机以来）相同的原始ROM映像。 然而，这足以让时钟进行一次巨大的调整，然后保持同步。 这表明单纯的重启可能会有所帮助。 反过来说，这意味着在较新的固件中显示的正确时间在未来几年仍然会偏离新的固件版本。 这将需要几天，直到我可以安全地分辨时钟是否每天损失约5秒钟…
目前，案件已经结案。
自从90年代中期以来，我在NTP Pool项目方面做了很多工作，并在这里运行了几台NTP Stratum-1 GPS Synced服务器。 正如其他人所说，你需要两台以上的服务器才能获得时间。 由于上面Ron Maupin所说的原因，我通常在这里使用4。 同样如上所述，您需要注意循环，并将其设置为服务器与对等设备。
时间漂移可能是由于IOS中的已知错误，在此IOS更新中修复了与ntp.drift无关的错误，因此无法正确删除或更新，从而导致漂移问题。 还有4年没有重新启动或更新肯定已经离开你在一个非常糟糕的地点安全明智的IOS安全更新出来相当频繁。
以下是在Cisco IOS上设置NTP的优秀posthttp://packetlife.net/blog/2011/mar/28/cisco-ios-clocks-and-ntp/
希望这是有帮助的。 请询问你是否有更多的问题或问题。
完全公开：我只是偶尔摆弄开关configuration，而我绝不是NTP专家。
也就是说，我曾经在RHEL 5.x系统上看到NTP守护进程（是的，我回去了，但是你确实说过你的交换机有一个4年前的图像） ，似乎认为它是完全同步的，但显然不是。 我们将使用ClusterSSH会话同时在所有系统上运行“date”，并且有时会显示系统之间的漂移多达5分钟。 如果我记得正确的话，我们似乎只能通过重新启动守护进程来解决问题，并且最终只是让cron每天晚上重新启动服务。
绝不是一个理想的解决scheme，但是你也许可以采用类似cron作业的方式连接到交换机并启动重启，或者以某种方式在交换机上“踢”NTP守护进程？
希望这可以帮助！