理解NTP到达度量--什么构成了失败的NTP事务？

Question

目前，我正在解决NTP (针对客户端的4.6.2版本)与特定LAN上所有系统同步的问题。它们位于我不拥有的网络上，也不了解网络体系结构是什么样子，并且与局域网上的NTP参考服务器(我也不拥有)同步。我不能在这些机器上运行活动命令。我必须请求其他人运行一个命令来远程处理这些机器，然后在24小时后获得日志。我所做的代替数据包捕获的是设置一个每小时的ntpq -pn任务，告诉我这些设备正在监听什么(如果有的话) NTP服务器，抖动和到达是什么。所有这些设备的触角(有5台)都在弹跳，抖动也非常频繁(虽然不总是如此)，有时甚至高达10000或更高。

我的主要问题是reach度量以及它如何计算失败/成功的事务。我知道到达度规是最近8个NTP事务二进制状态的八进制值表示(0失败，1成功)。我似乎找不到任何地方能够准确地描述什么构成了失败的NTP事务。显然，丢弃的NTP数据包将构成失败的事务，但是还有其他的吗？因为抖动太大或时间差超出恐慌阈值而丢弃数据包是否构成失败的事务？有人能告诉我什么是NTP失败事务的文档吗？

我觉得包捕获会让我立即明白这些失败的事务是否是丢弃的数据包，但由于这些事务对我来说是不可用的，所以除了ntpq -pn每小时的cron作业输出以供参考之外，我真的没有什么可做的了，这些cron作业的输出在IP/RefID信息的下面。注意，在重新启动之后(这些系统没有内部电池，并且在重新启动时丢失了时钟)，我们经常会看到NTP无法同步，并且没有通过LAN NTP服务器或它的本地地址。到目前为止，所有设备在同步失败时都显示完全相同的到达值，这表明这是一些常见网络设备的问题，它们无法在这些时间内与NTP引用或NTP引用服务器本身进行对话。为了进一步加强这一点，当这些设备重新启动时，它们总是在大致相同的时间(在彼此之间的几秒钟内)同步。

谁能告诉我什么构成了一个失败的NTP事务，或者，如果没有，谁能深入了解reach/jitter值的含义呢？

Sep 19 23:05:01 ember4 user.notice  user:      remote           refid      st t when poll reach   delay   offset  jitter
Sep 19 23:05:01 ember4 user.notice  user: ==============================================================================
Sep 19 23:05:01 ember4 user.notice  user: *127.127.1.0     .LOCL.          14 l   14   64  377    0.000    0.000   0.031
Sep 19 23:05:01 ember4 user.notice  user:  LAN NTP       NTP REFERENCE IP  2 u   66   64  377    0.453  2159.21 544.980
--
Sep 20 00:05:01 ember4 user.notice  user:      remote           refid      st t when poll reach   delay   offset  jitter
Sep 20 00:05:01 ember4 user.notice  user: ==============================================================================
Sep 20 00:05:01 ember4 user.notice  user: *127.127.1.0     .LOCL.          14 l   30   64  377    0.000    0.000   0.031
Sep 20 00:05:01 ember4 user.notice  user: LAN NTP       NTP REFERENCE IP    2 u    6   64  377    0.482  1595.79 320.179
--
Jan  1 00:05:01 ember4 user.notice  user:      remote           refid      st t when poll reach   delay   offset  jitter
Jan  1 00:05:01 ember4 user.notice  user: ==============================================================================
Jan  1 00:05:01 ember4 user.notice  user:  127.127.1.0     .LOCL.          14 l    5   64   37    0.000    0.000   0.031
Jan  1 00:05:01 ember4 user.notice  user: LAN NTP       NTP REFERENCE IP    2 u   53   64   17    0.878  6538755 355.656
--
Jan  1 00:05:01 ember4 user.notice  user:      remote           refid      st t when poll reach   delay   offset  jitter
Jan  1 00:05:01 ember4 user.notice  user: ==============================================================================
Jan  1 00:05:01 ember4 user.notice  user:  127.127.1.0     .LOCL.          14 l    4   64   37    0.000    0.000   0.031
Jan  1 00:05:01 ember4 user.notice  user: LAN NTP       NTP REFERENCE IP    2 u   58   64   17    0.908  6538759 459.008
--
Sep 20 06:05:01 ember4 user.notice  user:      remote           refid      st t when poll reach   delay   offset  jitter
Sep 20 06:05:01 ember4 user.notice  user: ==============================================================================
Sep 20 06:05:01 ember4 user.notice  user:  127.127.1.0     .LOCL.          14 l    -   64    0    0.000    0.000   0.000
Sep 20 06:05:01 ember4 user.notice  user: *LAN NTP       NTP REFERENCE IP    2 u   33   64    1    0.634  160.235 123.523
--
Sep 20 07:05:01 ember4 user.notice  user:      remote           refid      st t when poll reach   delay   offset  jitter
Sep 20 07:05:01 ember4 user.notice  user: ==============================================================================
Sep 20 07:05:01 ember4 user.notice  user: *127.127.1.0     .LOCL.          14 l   51   64  377    0.000    0.000   0.031
Sep 20 07:05:01 ember4 user.notice  user: LAN NTP       NTP REFERENCE IP    2 u   34   64    1    0.532  3005.52 2389.98

Answer 1

我怀疑这将永远与任何人相关，但这可能会节省大量的时间投入到一个相当利基的话题上，这是我在这个兔子洞的最后发现的。

因此，我最终不得不阅读“NTPv4 RFC5905”和“ntp.org源代码”来找到答案。

每次由NTP处理数据包时，都会根据7个测试进行评估，以决定是否接受或放弃该数据包。这一切都发生在ntpd.c中的process_packet函数中，如果数据包没有通过7个测试中的任何一个(或者根本没有接收到)，那么就reach度量而言，NTP事务被认为是失败的。

试验情况如下：

1. 从NTP服务器接收的传输时间戳与从前一个数据包接收的相同的传输时间戳匹配吗？
2. 起始时间戳是否与同一对等方发送的最后一个时间戳匹配？这是为了确保不按顺序接收数据包。
3. 起始和接收时间戳都不是零的吗？
4. 此数据包的计算延迟是否在可接受的范围内？本质上，如果客户端对NTP请求的响应太长，无法从服务器接收到，则丢弃此数据包。
5. 如果为NTP启用了身份验证，身份验证器是否存在并正确解密从此服务器接收的数据包？
6. 引用NTP服务器当前是否与其引用NTP服务器同步？
7. 此引用NTP服务器的层值是否低于NTP客户端自己的层值？
8. 单个数据包的根延迟和根色散是否低于已建立的界限？其中一部分可以通过/etc/ntp.conf中的TOS MAXDIST n进行调整，以便允许来自给定数据包的更高(或更低)的根色散。

在我的特殊情况下，在数据包捕获之后，发现数据包同时失败了测试6和测试8。有时从我的NTP客户端的参考NTP服务器接收到的根分散值是几秒或更多。NTPv4中的默认maxdist设置允许计算1.5s:此外，引用NTP服务器本身经常无法与其自己的引用服务器同步。

在撰写本文时，还不清楚是什么导致了与引用服务器的同步失败，而且，由于我不管理它，我不得不开发一些解决方案。即向我的NTP客户端添加TOS MAXDIST 60。这将同步率提高到90%，这对于我们的目的来说是足够好的。