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

linux – 隔离网络上的单个NTP服务器,第1张

概述我在隔离网络上有两台 Linux机器(A和B).它们必须是时间同步的.机器A间歇供电,必须服务时间,因为它连接到权威时间源(GPS).机器B仅在机器A通电时供电,但它是嵌入式Linux设备,其电源状态将经常变化.这两台机器都无法访问其他系统.这是一个封闭的网络. 据我所知,这对NTP来说是一个很高的订单,因为NTP通常希望与多台服务器联系.我在机器B上正常工作时遇到了麻烦.机器A与GPS同步很好, 我在隔离网络上有两台 Linux机器(A和B).它们必须是时间同步的.机器A间歇供电,必须服务时间,因为它连接到权威时间源(GPS).机器B仅在机器A通电时供电,但它是嵌入式linux设备,其电源状态将经常变化.这两台机器都无法访问其他系统.这是一个封闭的网络.

据我所知,这对NTP来说是一个很高的订单,因为NTP通常希望与多台服务器联系.我在机器B上正常工作时遇到了麻烦.机器A与GPS同步很好,机器B可以到达机器A甚至做时间查询,但机器A不受信任(可能是它本身?).机器A运行一小时后,突然发生变化,机器B工作.然而,当机器A停机(因此机器B)时,机器B再次无法找到良好的时间同步.

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

10.10.10.1: Server dropped: strata too highserver 10.10.10.1,port 123stratum 16,precision -19,leap 11,trust 000refID [10.10.10.1],delay 0.02614,dispersion 0.00000transmitted 4,in filter 4reference time:    00000000.00000000  Thu,Feb  7 2036  6:28:16.000originate timestamp: d3a9bdc4.27ebb350  Thu,Jul 12 2012 21:19:00.155transmit timestamp:  bc17c803.b42dfffe  Sat,Jan  1 2000  0:25:39.703filter delay:  0.02625  0.02614  0.02618  0.02625          0.00000  0.00000  0.00000  0.00000 filter offset: 39544160 39544160 39544160 39544160         0.000000 0.000000 0.000000 0.000000delay 0.02614,dispersion 0.00000offset 395441600.451568 1 Jan 00:25:39 ntpdate[677]: no server suitable for synchronization found

我的猜测是机器A只是不相信自己的服务时间.经过51分钟(可能早先发生,我不知道)的正常运行时间和时钟同步到GPS,机器A开始正常服务时间,机器B捡起它.我需要提前做到这一点.比如,如果可能,在几秒钟内.

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

机器A ntp.conf:

server 127.127.28.0 prefer true minpoll 4 maxpoll 4fudge 127.127.28.0 stratum 1 time1 0.420 refID GPS 

机器B ntp.conf:

server 10.10.10.1 prefer true minpoll 4 maxpoll 4

机器B上的ntpq -c peer没有很好的时间修复:

     remote           refID      st t when poll reach   delay   offset  jitter============================================================================== 10.10.10.1   .STEP.          16 u    9   16    0    0.000    0.000   0.000

机器B上的ntp1 -c对等机具有良好的时间修复:

     remote           refID      st t when poll reach   delay   offset  jitter==============================================================================*10.10.10.1   SHM(0)           2 u    7   16   17    0.669    2.597   1.808

所以,现在问题变成了:我如何快速地使机器A信任?

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

之前..

~ # ntpq -c rvassocID=0 status=c418 leap_alarm,sync_uhf_radio,1 event,no_sys_peer,version="ntpd 4.2.6p4@1.2324 Fri Feb 24 15:01:45 UTC 2012 (1)",processor="armv7l",system="linux/2.6.35.14",leap=11,stratum=2,precision=-19,rootdelay=0.000,rootdisp=44.537,refID=SHM(0),reftime=d3ab0053.43b44780  Fri,Jul 13 2012 20:15:15.264,clock=d3ab0062.e7e03154  Fri,Jul 13 2012 20:15:30.905,peer=34819,tc=4,mintc=3,offset=0.000,frequency=0.000,sys_jitter=3.853,clk_jitter=36.492,clk_wander=0.000

后…

~ # ntpq -c rvassocID=0 status=0415 leap_none,clock_sync,leap=00,rootdisp=41.278,reftime=d3ab0063.43b37856  Fri,Jul 13 2012 20:15:31.264,clock=d3ab006d.9ee53ec2  Fri,Jul 13 2012 20:15:41.620,frequency=43.896,sys_jitter=0.762,clk_jitter=36.953,clk_wander=0.000
解决方法 NTP应该可以正常工作.查看启动时快速同步的一些选项.查看系统B的突发和iburst选项.查看GPS时钟源的真实选项.

考虑在两个系统上使用硬件时钟作为备用时间源.设置更高的层次系统B.以下内容应该有效:

server  127.127.1.0fudge   127.127.1.0 stratum 8

观察ntpq -c peer的输出以查看何时获得可信时钟源.通常,ntp在信任它之前需要来自可信时间源的大量响应.这由每行的第一个字符表示.

虽然NTP喜欢更多来源,但是在一个层次中任何奇数个时间源都应该运行良好.由于您只有两台服务器和一个GPS时钟,因此源的优先级(层数)应该从GPS,服务器A上的时钟,服务器B上的时钟增加.将每个层之间的层数增加三层或四层将确保优先级得到尊重.

编辑:如果您在服务器A上有busyBox NTP服务器,则可能值得安装完整的ntp服务器软件包.了解服务器A的情况应该可以解决您的问题.在服务器B应该信任它之前,您将需要至少一个受信任的时间源.如果ntpq -c peers不起作用,那么你可以试试ntpdc peer.这两个命令都允许您查询其他主机. peerstats日志也很有用.

在服务器B上使用ntpclIEnt记录busybox ntp howto来记录它上面发生的事情

如果服务器没有长时间停机,时钟应该合理地接近正确的时间.如果您需要同步这两个系统,那就足够了. GPS将最终使时间与现实世界同步.

‘ntpd -q’快速同步,但退出(ntpdate行为).它需要后跟一个没有quit选项的ntpd命令才能进行连续同步.

EDIT2:我检查了我的服务器,发现其中一台服务器关闭了一秒钟.在修复此问题时,我使用了设置. iburst非常快速地获得服务器信任.如果没有多个其他可信来源,则确保时钟驱动程序受信任.时钟花了不到一分钟才被本地信任,可以远程信任.

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

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

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

总结

以上是内存溢出为你收集整理的linux – 隔离网络上的单个NTP服务器全部内容,希望文章能够帮你解决linux – 隔离网络上的单个NTP服务器所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/1040991.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-24
下一篇 2022-05-24

发表评论

登录后才能评论

评论列表(0条)

保存