我偶然发现我的一台 Cisco 4500 交换机的时钟出了问题:落后2分钟以上尽管 ntp 看似功能正常。在我看来,即使是一秒钟,对于所涉及的系统来说也不应该被视为可接受的。此外,如果我没有将其与简单的挂钟进行比较,我不会注意到诊断的差异。
一些细节
以下是我的部分主机(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 的系统是正确的?
- 我应该如何从 10.0.99.1 的输出中得知
sho ntp status
时钟实际上完全不同步(与全部)中提到的主机和参考时钟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
答案1
我不太愿意把这个作为答案发布出来,因为最初的原因仍然不清楚。不过,问题似乎已经解决了——至少目前如此。
根据以下人士的评论htm11h,我决定更新固件。事实上,现在我运行的是较新的固件,时钟似乎与正确的时间相匹配。
但这是否意味着新固件就是解决方案?不幸的是,不是。在我第一次尝试加载新固件时,我忘记更改配置寄存器,该寄存器仍处于出厂默认状态。因此,我的第一次重启最终回到了路由器运行了近四年的原始 ROM 映像(即自首次通电以来)。然而,这足以让时钟进行一次巨大的调整,然后保持同步。这表明仅仅重启可能会有所帮助 - 暂时。反过来,这意味着现在使用较新固件显示的正确时间在未来几年可能仍会偏离 ntp 时间。我需要几天时间才能安全地判断时钟是否每天慢了大约 5 秒......
目前,该案已经结案。
答案2
自 90 年代中期以来,我从事了相当多的 NTP Pool 项目工作,并在这里运行了多个 NTP Stratum-1 GPS 同步服务器。正如其他人所说,您需要 2 个以上的服务器来获取时间。我通常在这里使用 4 个,原因如上所述,Ron Maupin 已说明。此外,如所列,您需要注意循环并将事物设置为服务器与对等点。
时间漂移可能是由于 IOS 中一个已知错误造成的,该错误已在此次 IOS 更新中修复,处理 ntp.drift 未被正确删除或更新,因此导致漂移问题。此外,4 年没有重启或更新必定让你处于非常糟糕的安全境地,因为 IOS 安全更新发布得相当频繁。
这是一篇关于在 Cisco IOS 上设置 NTP 的优秀文章 http://packetlife.net/blog/2011/mar/28/cisco-ios-clocks-and-ntp/
希望这对您有帮助。如果您还有其他问题或疑问,请询问。
答案3
全面披露:我只是偶尔摆弄交换机配置,而且我绝不是 NTP 专家。
话虽如此,我曾经看到 RHEL 5.x 系统上的 NTP 守护进程(是的,我要回过头来,但您确实说过您的交换机有一个大约 4 年前的图像……)卡在“快乐”状态,它似乎认为它已经完全同步,但显然不是。我们将使用 ClusterSSH 会话在所有系统上同时运行“date”,有时会显示系统之间长达 5 分钟的漂移。如果我没记错的话,我们似乎只能通过重新启动守护进程来解决问题,最终只是让 cron 每晚重新启动服务……
这绝不是一个理想的解决方案,但您可以采用类似的方法,使用 cron 作业连接到交换机并启动重新启动,或者以某种方式“启动”交换机上的 NTP 守护程序?
希望这可以帮助!