尽管使用了ntp，我的交换机之一怎么会关闭两分钟？

我只是偶然地发现我的一台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.

问题

10.0.99.1距离现在有多远？
同步到10.0.99.1的系统如何正确？
如何从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

cisco ntp time-synchronization

— 哈根·冯·埃岑
source

我无法发现任何系统，其中已将IP地址配置为每个设备使用的ntp服务器。我发现一个循环以及一对互相使用作为ntp服务器的循环。我相信在那种情况下，您应该将它们指定为ntp对等点而不是服务器。尽管我必须承认，我不知道将其指定为对等服务器还是服务器到底有什么区别。另外，我也不认为让所有内容通过单个主机（10.0.0.1）同步是一个好主意。但是我认为我的任何观察都不能直接解释您当前问题的原因。

— 卡巴斯德（Kasperd）

ntp配置的一个明显问题是，每个主机配置的时间源数量都可能最差。“有一只手表的人知道现在几点了，永远不确定有两只手表的人...”其他任何一个数字都比两个好，四个可能是最好的选择，如果一个不可用并且仍然离开，它可以提供缓冲。三个来源。

— dfc

您的整个NTP配置都需要重新考虑。您需要使用层次级别。正如@kasperd指出的那样，您可能会遇到循环问题。您只应同步到较低层级别的服务器，并且可以对等层级别的服务器进行对等，但不能彼此用作服务器。对等设备仍然需要一台或多台较低层级的服务器作为权威源，但是会尝试使其自身与其他对等设备对齐。不要将繁忙的设备（例如核心交换机）用作NTP服务器。

— 罗恩·莫平

一件很奇怪的事情正在发生。所有的ntp输出都相当正常，并显示出良好的同步性。但是，您从设备获取时间的命令所花费的时间还很遥远。这表明由于某种原因，关闭时间的设备未设置其ntp子系统的系统时钟。

— David Schwartz

听起来您确实发现了一个错误，并且前进的唯一方法可能是重新启动它，并希望它消失或与Cisco联系。

— 德罗伯特

Answers:

我有点不愿意将其发布为答案，因为最初的原因尚不清楚。不过，这个问题似乎已经解决了-至少目前是这样。

根据htm11h的评论，我决定更新固件。确实，既然我使用的是较新的固件，时钟似乎与正确的时间匹配。

但这是否意味着新固件才是解决方案？很不幸的是，不行。在我第一次尝试加载新固件时，我忘记更改配置寄存器，该寄存器仍为出厂默认设置。因此，我的第一次重新引导最终以路由器运行了将近四年（即自首次开机以来）相同的原始ROM映像结束。但是，这足以使时钟进行一次大的调整，然后保持同步。这表明仅重新启动可能会有所帮助-暂时。反过来，这意味着在以后的几年中，使用较新固件显示的现在正确的时间可能仍会偏离ntp时间。几天之后，我才能确定时钟是否每天丢失约5秒钟...

目前，此案已经结案。

— 哈根·冯·埃岑
source

自90年代中期以来，我已经为NTP Pool项目做了大量工作，并在此处运行多台NTP Stratum-1 GPS Synced服务器。正如其他人所说，您需要2台以上的服务器来获取时间。由于上面Ron Maupin所述的原因，我通常在这里使用4。同样如上所列，您需要查找循环并将其设置为服务器与对等服务器。

时间漂移可能是由于在此IOS更新中修复的，解决ntp.drift无法正确删除或更新的IOS中的一个已知错误所致，因此出现了漂移问题。此外，由于IOS安全更新发布得相当频繁，因此4年没有重新启动或更新也必须使您处于一个非常糟糕的安全点。

这是在Cisco IOS上设置NTP的出色文章 http://packetlife.net/blog/2011/mar/28/cisco-ios-clocks-and-ntp/

希望这会有所帮助。请询问您是否还有其他问题。

— 乔治·卡西卡
source

全面披露：我只是偶尔摆弄开关配置，我也不是NTP专家。

就是说，我曾经在RHEL 5.x系统上看到过NTP守护进程（是的，我回过头来，但是您确实说过您的交换机具有大约4年的历史……）被卡在“快乐”状态，它似乎认为它完全同步，但显然不是。我们将使用ClusterSSH会话在所有系统上同时运行“日期”，有时在系统之间可能会出现多达5分钟的漂移。如果我没记错的话，我们似乎只能通过重新启动守护程序来解决问题，最终只是让cron每晚每晚重新启动服务...

绝不是理想的解决方案，但是您可以通过cron作业采用类似的方法来连接到交换机并启动重新引导，或者以某种方式“踢”交换机上的NTP守护程序？

希望这可以帮助！

— 担
source