问题描述
我目前正在对与特定LAN上所有系统的NTP（客户端v4.6.2）同步问题进行故障排除。它们位于我不拥有的网络上，也不了解网络体系结构，并与该LAN上的NTP参考服务器（我也不拥有）同步。我无法在这些计算机上运行活动命令。我必须请求其他人运行命令以对这些计算机进行远程处理，然后在约24小时后获取日志。我代替数据包捕获所做的工作是设置每小时ntpq -pn的cronjob来告诉我这些设备正在侦听什么（如果有）NTP服务器，抖动和范围。所有这些设备（其中有5个）的触及范围到处都是跳动，抖动的频率也非常高（尽管并非总是如此），有时甚至高达10000或更高。
我的主要问题是关于覆盖率指标以及它如何计算失败/成功的交易。我知道reach metric是最近8个NTP交易二进制状态的八进制值表示形式（ 0失败，1成功）。我似乎找不到任何地方可以准确描述失败的NTP事务的构成。显然，丢弃的NTP数据包将构成失败的事务，但是还有其他事情吗？是否会因为抖动过高或时间差超出紧急阈值而丢弃数据包而导致交易失败？谁能指出我实际上显示NTP失败事务是什么的文档？
我感觉到数据包捕获将使我立即清楚地知道这些失败的交易是否已丢弃数据包，但是由于这对我来说不可用，除了每小时cronjob输出{ {1}}以下是其中一些cronjobs的输出，其中已清除了IP / RefID信息。请注意，与重新启动（这些系统没有内部电池，并且在重新启动时失去时钟）相比，我们通常会看到NTP无法同步，并且LAN NTP服务器或其本地地址没有*。到目前为止，所有设备在无法同步时会显示完全相同的到达值，这表明这是某些常见网络设备存在的问题，导致它们无法与NTP参考或NTP参考服务器本身在此期间不响应次。为了进一步加强这一点，当这些设备重新启动时，它们总是在大致相同的时间（彼此之间不超过几秒钟）同步。
谁能指出我是什么构成了失败的NTP事务，或者除此以外，对到达/抖动值的含义有任何见识？
ntpq -pn解决方法
我怀疑这是否与任何人都相关，但它可能会节省很多时间投入到一个相当小众的话题上，这就是我在这只兔子的结尾发现的洞。
所以我最终不得不阅读 NTPv4 RFC5905 和 ntp.org source code 以找到答案。
每次 NTP 处理数据包时，都会根据 7 次测试对其进行评估，以决定是否接受或丢弃该数据包。这一切都发生在 ntpd.c 中的 process_packet 函数中如果数据包在 7 个测试中任何失败（或根本没有收到），那么就到达度量而言，NTP 事务被视为失败.
测试如下：
- 从 NTP 服务器收到的传输时间戳是否与从前一个数据包收到的相同传输时间戳匹配？
- 原始时间戳是否与同一对等方发送的最后一个时间戳匹配？这是为了确保不会无序接收数据包。
- 始发和接收时间戳都非零吗？
- 这个数据包的计算延迟是否在可接受的范围内？本质上，如果客户端对 NTP 请求的响应时间太长而无法从服务器接收到，则丢弃此数据包。
- 如果为 NTP 启用了身份验证，身份验证器是否存在并正确解密从该服务器收到的数据包？
- 参考 NTP 服务器当前是否与其参考 NTP 服务器同步？
- 这个参考NTP服务器的层值是否低于NTP客户端自己的层值？
- 单个数据包的根延迟和根色散是否低于既定界限？其中的一部分可以通过 /etc/ntp.conf 中的 TOS MAXDIST n 进行调整，以允许来自给定数据包的更高（或更低）根分散。
在我的特殊情况下，在捕获数据包后发现数据包未通过测试 6 和测试 8。有时从我的 NTP 客户端的参考 NTP 服务器接收的根分散值是几秒钟或更长时间。 NTPv4 中的默认 maxdist 设置允许大约 1.5 秒的计算时间：1/2root_delay + root_dispersion 此外，参考 NTP 服务器本身经常无法与其自己的参考服务器同步。
在撰写本文时，仍然不知道是什么导致了与参考服务器的同步失败，而且由于我没有管理它，我不得不开发一些解决方法。即添加 TOS MAXDIST 60 到我的 NTP 客户端。这将同步率提高到了约 90%，这对于我们的目的来说已经足够了。