了解 NTP 到达指标——什么构成了失败的 NTP 交易？
Understanding NTP Reach Metric -- What constitutes a failed NTP transaction?
我目前正在对特定 LAN 上所有系统的 NTP（客户端 v4.6.2）同步问题进行故障排除。它们位于我不拥有的网络上，也无法查看网络架构的外观，并与该 LAN 上的 NTP 参考服务器（我也不拥有）同步。我无法在这些机器上 运行 激活命令。我必须请求其他人 运行 一个命令来远程对这些机器执行某些操作，然后在大约 24 小时后获取日志。我所做的代替数据包捕获的是设置一个 ntpq -pn 的每小时 cronjob 来告诉我这些设备正在监听的（如果有的话）NTP 服务器，抖动和范围是多少。所有这些设备（其中有 5 个）上的 reach 到处都是跳动，抖动也非常频繁（尽管并非总是如此），有时甚至高达 10000 或更多。
我的主要问题是关于覆盖率指标及其计算 failed/successful 交易的方式。 我知道 reach metric 是最后 8 个 NTP 事务二进制状态（0 失败，1 成功）。我似乎找不到任何地方可以准确描述什么构成了失败的 NTP 事务。显然丢弃的 NTP 数据包将构成失败的交易，但还有其他吗？由于抖动太高或时间差超出恐慌阈值而丢弃数据包会构成失败的交易吗？谁能指出 实际上 显示 NTP 失败交易是什么的文档？
我觉得数据包捕获会让我立即明白这些失败的交易是否被丢弃的数据包，但由于我无法获得，所以除了每小时的 cronjob 输出外，我真的没有太多可做的了ntpq -pn 作为参考，其中一些 cronjobs 的输出在下方，其中 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
我怀疑这对任何人都没有意义，但它可能会节省 很多 的时间投入到一个相当小众的话题上，这是我发现的这个兔子洞的尽头。
所以我不得不通读 NTPv4 RFC5905 and the ntp.org source code 来找到答案。
NTP 每次处理一个数据包时，都会根据 7 次测试对其进行评估，以决定是接受还是丢弃该数据包。这一切都发生在 ntpd.c 中的 process_packet 函数中 如果数据包在 7 次测试中失败 any （或根本未收到），则认为 NTP 事务就达到指标而言是失败的。
测试如下：
- 从 NTP 服务器收到的传输时间戳是否与从前一个数据包收到的传输时间戳匹配？
- 原始时间戳是否与同一对等方发送的最后一个时间戳匹配？这是为了确保不会乱序接收数据包。
- 发起时间戳和接收时间戳是否都非零？
- 这个数据包的计算延迟是否在可接受的范围内？本质上，如果客户端对 NTP 请求的响应时间太长而无法从服务器接收到，则丢弃此数据包。
- 如果为 NTP 启用了身份验证，身份验证器是否存在并正确解密从该服务器收到的数据包？
- 参考NTP服务器当前是否与它的参考NTP服务器同步？
- 这个参考NTP服务器的层值是否低于NTP客户端自己的层值？
- 单个数据包的根延迟和根扩散是否低于既定界限？其中一部分可以使用 /etc/ntp.conf 中的 TOS MAXDIST n 进行调整，以允许给定数据包的根分散度更高（或更低）。
在我的特殊情况下，在捕获数据包后发现数据包未能通过测试 6 和测试 8。有时从我的 NTP 客户端的参考 NTP 服务器接收到的根分散值是几秒或更长时间。 NTPv4 中的默认 maxdist 设置允许 ~1.5s 用于计算：1/2root_delay + root_dispersion 此外，参考 NTP 服务器本身经常无法与其自己的参考服务器同步。
在撰写本文时，仍然不知道是什么原因导致与参考服务器的同步失败，并且由于我不管理它，所以我不得不制定一些解决方法。即向我的 NTP 客户端添加 TOS MAXDIST 60。这将同步率提高到 ~90%，这足以满足我们的目的。
我目前正在对特定 LAN 上所有系统的 NTP（客户端 v4.6.2）同步问题进行故障排除。它们位于我不拥有的网络上，也无法查看网络架构的外观，并与该 LAN 上的 NTP 参考服务器（我也不拥有）同步。我无法在这些机器上 运行 激活命令。我必须请求其他人 运行 一个命令来远程对这些机器执行某些操作，然后在大约 24 小时后获取日志。我所做的代替数据包捕获的是设置一个 ntpq -pn 的每小时 cronjob 来告诉我这些设备正在监听的（如果有的话）NTP 服务器，抖动和范围是多少。所有这些设备（其中有 5 个）上的 reach 到处都是跳动，抖动也非常频繁（尽管并非总是如此），有时甚至高达 10000 或更多。
我的主要问题是关于覆盖率指标及其计算 failed/successful 交易的方式。 我知道 reach metric 是最后 8 个 NTP 事务二进制状态（0 失败，1 成功）。我似乎找不到任何地方可以准确描述什么构成了失败的 NTP 事务。显然丢弃的 NTP 数据包将构成失败的交易，但还有其他吗？由于抖动太高或时间差超出恐慌阈值而丢弃数据包会构成失败的交易吗？谁能指出 实际上 显示 NTP 失败交易是什么的文档？
我觉得数据包捕获会让我立即明白这些失败的交易是否被丢弃的数据包，但由于我无法获得，所以除了每小时的 cronjob 输出外，我真的没有太多可做的了ntpq -pn 作为参考，其中一些 cronjobs 的输出在下方，其中 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
我怀疑这对任何人都没有意义，但它可能会节省 很多 的时间投入到一个相当小众的话题上，这是我发现的这个兔子洞的尽头。
所以我不得不通读 NTPv4 RFC5905 and the ntp.org source code 来找到答案。
NTP 每次处理一个数据包时，都会根据 7 次测试对其进行评估，以决定是接受还是丢弃该数据包。这一切都发生在 ntpd.c 中的 process_packet 函数中 如果数据包在 7 次测试中失败 any （或根本未收到），则认为 NTP 事务就达到指标而言是失败的。
测试如下：
- 从 NTP 服务器收到的传输时间戳是否与从前一个数据包收到的传输时间戳匹配？
- 原始时间戳是否与同一对等方发送的最后一个时间戳匹配？这是为了确保不会乱序接收数据包。
- 发起时间戳和接收时间戳是否都非零？
- 这个数据包的计算延迟是否在可接受的范围内？本质上，如果客户端对 NTP 请求的响应时间太长而无法从服务器接收到，则丢弃此数据包。
- 如果为 NTP 启用了身份验证，身份验证器是否存在并正确解密从该服务器收到的数据包？
- 参考NTP服务器当前是否与它的参考NTP服务器同步？
- 这个参考NTP服务器的层值是否低于NTP客户端自己的层值？
- 单个数据包的根延迟和根扩散是否低于既定界限？其中一部分可以使用 /etc/ntp.conf 中的 TOS MAXDIST n 进行调整，以允许给定数据包的根分散度更高（或更低）。
在我的特殊情况下，在捕获数据包后发现数据包未能通过测试 6 和测试 8。有时从我的 NTP 客户端的参考 NTP 服务器接收到的根分散值是几秒或更长时间。 NTPv4 中的默认 maxdist 设置允许 ~1.5s 用于计算：1/2root_delay + root_dispersion 此外，参考 NTP 服务器本身经常无法与其自己的参考服务器同步。
在撰写本文时，仍然不知道是什么原因导致与参考服务器的同步失败，并且由于我不管理它，所以我不得不制定一些解决方法。即向我的 NTP 客户端添加 TOS MAXDIST 60。这将同步率提高到 ~90%，这足以满足我们的目的。