隔离网络上的单个 NTP 服务器

隔离网络上的单个 NTP 服务器

我在一个隔离网络上有两台 Linux 机器(A 和 B)。它们必须时间同步。机器 A 断断续续地通电,并且必须遵守时间,因为它连接到权威时间源(GPS)。只有机器 A 通电,机器 B 才会通电,但它是嵌入式 Linux 设备,其电源状态会频繁更改。两台机器都无法访问其他系统。这是一个封闭的网络。

我知道这对于 NTP 来说是一个相当艰巨的任务,因为 NTP 通常需要与多个服务器建立联系。我无法让它在机器 B 上正常工作。机器 A 可以很好地与 GPS 同步,机器 B 可以联系到机器 A 甚至可以进行时间查询,但机器 A 不受信任(也许它自己不受信任?)。机器 A 运行一个小时后,情况突然改变,机器 B 可以正常工作。但是,当机器 A 发生故障(因此机器 B 也发生故障)时,机器 B 再次无法找到良好的时间同步。

以下是一些 ntpdate 信息。请注意,即使机器 A 的层数为 1,操作也会失败,最后输出相同的内容。

10.10.10.1:服务器掉线:层数太高
服务器 10.10.10.1,端口 123
阶层 16,精度 -19,飞跃 11,信任 000
refid [10.10.10.1],延迟 0.02614,分散 0.00000
已传输 4,在过滤器 4 中
参考时间:00000000.00000000 2036 年 2 月 7 日星期四 6:28:16.000
发起时间戳:d3a9bdc4.27ebb350 2012 年 7 月 12 日星期四 21:19:00.155
传输时间戳:bc17c803.b42dfffe 2000 年 1 月 1 日星期六 0:25:39.703
滤波器延迟:0.02625 0.02614 0.02618 0.02625
         0.00000 0.00000 0.00000 0.00000
滤波器偏移:39544160 39544160 39544160 39544160
         0.000000 0.000000 0.000000 0.000000
延迟0.02614,分散0.00000
偏移量 395441600.451568

 1 月 1 日 00:25:39 ntpdate[677]: 未找到适合同步的服务器

我猜机器 A 只是不相信自己能报时。在正常运行 51 分钟(可能更早,我不知道)并将其时钟与 GPS 同步后,机器 A 开始正确报时,机器 B 也开始报时。我需要这种情况更早发生。比如,如果可能的话,在几秒钟内。

通过以下配置(以及大量的等待),它最终成功。

机器A ntp.conf:

服务器 127.127.28.0 优先 true minpoll 4 maxpoll 4
fudge 127.127.28.0 层 1 时间1 0.420 refid GPS

机器Bntp.conf:

服务器 10.10.10.1 优先使用 true minpoll 4 maxpoll 4

ntpq -c 在机器 B 上进行对等操作,但未修复好时间:

     远程重新识别 st t 轮询到达延迟偏移抖动
==============================================================================
 10.10.10.1 .步骤. 16 u 9 16 0 0.000 0.000 0.000

ntp1 -c 在机器 B 上对等体进行了良好的时间修复:

     远程重新识别 st t 轮询到达延迟偏移抖动
==============================================================================
*10.10.10.1 SHM(0) 2 u 7 16 17 0.669 2.597 1.808

那么,现在的问题是:如何让机器 A 快速信任自己?

在机器 B 确定机器 A 足够好用之前和之后,机器 A 的一些调试输出。

前..

~# ntpq-c rv
associd=0 状态=c418 leap_alarm,sync_uhf_radio,1 事件,no_sys_peer,
版本=“ntpd[电子邮件保护]2012 年 2 月 24 日星期五 15:01:45 UTC (1)",
处理器=“armv7l”,系统=“Linux/2.6.35.14”,leap=11,层=2,
精度=-19,根延迟=0.000,根显示=44.537,refid=SHM(0),
reftime=d3ab0053.43b44780 2012 年 7 月 13 日星期五 20:15:15.264,
时钟 = d3ab0062.e7e03154 2012 年 7 月 13 日星期五 20:15:30.905,peer=34819,tc=4,
mintc=3,偏移量=0.000,频率=0.000,sys_jitter=3.853,
clk_jitter=36.492,clk_wander=0.000

后...

~# ntpq-c rv
associd=0 状态=0415 leap_none,sync_uhf_radio,1 事件,clock_sync,
版本=“ntpd[电子邮件保护]2012 年 2 月 24 日星期五 15:01:45 UTC (1)",
处理器=“armv7l”,系统=“Linux/2.6.35.14”,leap=00,层=2,
精度=-19,根延迟=0.000,根显示=41.278,refid=SHM(0),
reftime=d3ab0063.43b37856 2012 年 7 月 13 日星期五 20:15:31.264,
时钟=d3ab006d.9ee53ec2 2012 年 7 月 13 日星期五 20:15:41.620,peer=34819,tc=4,
mintc=3,偏移量=0.000,频率=43.896,sys_jitter=0.762,
clk_jitter=36.953,clk_wander=0.000

答案1

NTP 应该可以正常工作。查看一些启动时快速同步的选项。查看系统 B 的burst和选项。查看GPS 时钟源的选项。 ibursttrue

考虑在两个系统上使用硬件时钟作为备份时间源。设置更高层的系统 B。类似下面的操作应该有效:

server  127.127.1.0
fudge   127.127.1.0 stratum 8

观察输出以ntpq -c peers查看何时获得可信时钟源。通常ntp需要从可信时间源获得一定数量的响应,然后才会信任它。这由每行的第一个字符表示。

虽然 NTP 喜欢更多来源,但一个层次级别内的任何奇数个时间源都应该可以正常工作。由于您只有两台服务器和一个 GPS 时钟,因此来源的优先级(层次)应该从 GPS、服务器 A 上的时钟、服务器 B 上的时钟开始增加。将每个层次之间的层次增加三到四个级别将确保优先级得到尊重。

编辑:如果服务器 A 上有 busybox NTP 服务器,则可能需要安装完整的 ntp 服务器包。了解服务器 A 上发生的事情对解决您的问题大有帮助。在服务器 B 信任它之前,您至少需要一个受信任的时间源。如果ntpq -c peers不行,那么您可以尝试ntpdc peers。这两个命令都允许您查询其他主机。peerstats日志也可能有用。

在服务器 B 上使用 ntpclient 按照文档说明进行操作busybox ntp 使用方法记录正在发生的事情

如果服务器停机时间不长,时钟应该相当接近正确时间。如果您需要同步两个系统,那就足够了。GPS 最终会使时间与现实世界同步。

'ntpd -q' 同步速度快,但会退出(ntpdate 行为)。它后面需要跟一个ntpd不带 quit 选项的命令才能持续同步。

编辑 2:我检查了我的服务器,发现其中一个服务器关闭了一秒钟。在修复此问题时,我调整了设置。iburst非常快速地获得服务器信任。 true确保如果没有多个其他受信任源,则时钟驱动程序是受信任的。时钟花了一分钟多一点的时间才在本地获得信任并可以远程获得信任。

测试时,您应该能够ntpd在同步后重新启动该过程并测试设置的工作速度。在上述情况下,可能需要重新启动服务器 B 以测试其同步速度。在监控ntpd更改时,我使用如下一行:

while ntpq -c peers localhost; do sleep 10; done

主机名和睡眠时间根据需要进行调整。在某些情况下,我会ntpq在循环中链接两个或多个命令行。这样做时,我会使用 echo 和/或 date 命令来指示数据集发生更改的位置。

相关内容