NTP 因“peer_dist”拒绝上游

NTP 因“peer_dist”拒绝上游

目前 NTP 拒绝其上游,并且漂移相当严重(到目前为止偏移了 15 秒并且还在增长)。使用ntpqflash 代码检查原因时,结果如下flash=400 peer_dist

检查 NTP 文档,如果往返时间超过 1.5 秒,则对等端被标记为远距离。但是使用 tcpdump,我可以看到数据包离开和回复返回(以毫秒为单位):

09:06:36.304204 IP 10.127.255.230.ntp > 10.127.255.213.ntp: NTPv4, Client, length 68
09:06:36.304371 IP 10.127.255.213.ntp > 10.127.255.230.ntp: NTPv4, Server, length 68

此处的一般架构是此子网中的 1 个 ntp 服务器(从集群外部的上游获取时间),为子网中的节点提供时间。服务器同步并正常提供时间,但子网中的所有节点都报告为unsynchronised

简单地重新启动 ntpd 不会产生任何效果,因为对等端仍然被拒绝。但是,在更改ntp.conf 中的maxdist使用后,它就会同步 ( )。tos maxdist 5000flash=00 ok

为什么当我看到(使用 ntpq/tcpdump)请求在几毫秒内完成时,ntp 会认为距离大于 1.5 秒?除了在maxdist这里有意义的之外,还有其他一些我可以调整的内部 NTP 参数吗?是否还有其他可以进行调试以诊断此问题?

这只是发生这种情况的集群的一个例子,但我在其他地方也看到了同样的症状。

作为参考,以下是(讽刺的)ntp文档为了maxdist

maxdist maxdistance
Specify the synchronization distance threshold used by the clock selection algorithm. The default is 1.5 s. This determines both the minimum number of packets to set the system clock and the maximum roundtrip delay. It can be decreased to improve reliability or increased to synchronize clocks on the Moon or planets.

答案1

如果 ntpd 正在报告上游对等体的 peer_dist 代码,则意味着对等体报告的根色散和对等体关联中测量的色散之间已超过 1.5 秒的阈值。

鉴于您的请求在几毫秒内完成,问题很可能出在上游层。要确认或否认这一点,您需要分析数据包捕获。您是否也控制上游?

这里可能值得一提的是,您在子网中设计了 1 个 NTP 服务器,并与上游的 1 个 NTP 服务器相关联,这意味着您正在使选择和聚类算法无效,这将导致客户端的时间不太准确。每个 NTP 层应有 4-10 个源以实现最大精度。

相关内容