☰

编辑-1

tag-icon • tag-icon ntp
编辑-1

我们在其中一个系统上配置了一个 NTP 客户端。该客户端有一组可用的服务器，可以与其同步。

然而，我们选择的首选服务器是 IP 为 169.254.1.51 的内部主服务器。

ntp.conf 的内容如下：-

 

    # --- 客户端网络 -------
    # --- 用户设置开始 ---

    服务器 10.241.34.2 iburst

    服务器 10.241.34.3 iburst

    服务器 10.241.34.4 iburst
    限制 10.241.34.2 掩码 255.255.255.255 nomodify notrap noquery
    限制 10.241.34.3 掩码 255.255.255.255 nomodify notrap noquery
    限制 10.241.34.4 掩码 255.255.255.255 nomodify notrap noquery
    # --- 用户设置结束 ---

    # --- NTP 多播客户端 ---
    限制 169.254.0.0 掩码 255.255.0.0 nomodify notrap # 内部网络
    # --- 内部时间服务器开始-----
    server 169.254.1.51 burst iburst minpoll 4 maxpoll 6 prefer #内部主服务器

    # --- 一般配置 ---
    服务器 127.127.1.0 iburst minpoll 4 #本地时钟
    fudge 127.127.1.0 层 10
    修改步骤 0

以上是配置部分。然而，当我们在配置并重启系统后检查系统日志时，我们发现客户端正在与外部服务器同步，而不是与系统日志中的 ntpq 输出中捕获的首选服务器同步

    3 月 22 日 05:52:48 节点 ntpcheck：远程 refid st t 轮询到达延迟偏移抖动
    3 月 22 日 05:52:48 节点 ntpcheck： =====================================================================================
    3月22日 05:52:48 节点 ntpcheck：*10.241.34.2 10.240.33.1 4 u 2 64 1 0.192 -519.50 5.769
    3月22日 05:52:48 节点 ntpcheck：10.241.34.3 10.241.34.2 5 u 1 64 1 0.172 -523.79 8.912
    3月22日 05:52:48 节点 ntpcheck：10.241.34.4 10.241.34.2 5 u 2 64 1 0.207 -520.73 8.082
    3月22日 05:52:48 节点 ntpcheck：169.254.1.51 LOCAL(0) 11 u 1 16 1 0.113 -0.043 2.099
    3 月 22 日 05:52:48 节点 ntpcheck：127.127.1.0 .LOCL。10 l 14 16 1 0.000 0.000 0.001}

此外，以下消息不断涌入系统日志

    3 月 22 日 06:51:11 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:51:27 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:51:45 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:52:03 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:52:20 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:52:35 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:52:51 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:53:06 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:53:20 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:53:23 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:53:38 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:53:53 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:54:11 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:54:29 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:54:47 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:55:02 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:55:20 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:55:21 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:55:35 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:55:53 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:56:10 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:56:28 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:56:46 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:57:03 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:57:21 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:57:38 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:57:54 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:58:09 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:58:24 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:58:42 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:58:59 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:59:15 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 06:59:30 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 06:59:46 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4
    3 月 22 日 07:00:02 节点 ntpd[31292]: 已同步至 LOCAL(0)，层数 10
    3 月 22 日 07:00:17 节点 ntpd[31292]: 已同步至 10.241.34.2，层数 4

我们尝试检查 NTP 论坛，发现它使用以下参数来定义要同步的服务器（参考：-https://www.eecis.udel.edu/~mills/ntp/html/warp.html）：-

  • 第一级拒绝是基于偏移和延迟而发生的。
  • 然后，在拒绝池之后，幸存者将被传递给时钟聚类算法。
  • 聚类算法依靠抖动来决定。
  • 其余所有服务器均为可选幸存者，任意选择其中一个即可。
  • 现在，prefer 关键字开始发挥作用，所有可选的选项都会被检查，并且会选择一个。
  • 如果幸存者不存在，则根据迁移规则决定对等体。

然而在 ntpq 输出中，首选服务器具有更好的偏移和抖动，即使如此它也没有被选择。

在这种情况下，是否有可能确定拒绝首选服务器的依据。

编辑-1

我们进一步发现，尽管层数较高，但系统日志中仍提到选择了 169.254.1.51，如下所示：-

 

Mar 24 05:01:01 Node ntpq: ==============================================================================
Mar 24 05:01:01 Node ntpq: +10.241.34.2     10.240.33.1      4 u  693 1024  377    0.242  -251.08  10.473
Mar 24 05:01:01 Node ntpq: +10.241.34.3     10.241.34.2      5 u   46   64  377    6.675  -255.20   0.326
Mar 24 05:01:01 Node ntpq: +10.241.34.4     10.241.34.2      5 u  245 1024  377    0.312  -264.63   7.708
Mar 24 05:01:01 Node ntpq: *169.254.1.51          LOCAL(0)        11 u   12   64  377    0.143   80.034   2.248
Mar 24 05:01:01 Node ntpq:  LOCAL(0)        .LOCL.          10 l   10   16  377    0.000    0.000   0.001

答案1

这样看：你有四台服务器：

  1. 10.241.34.2
  2. 10.241.34.3
  3. 10.241.34.4
  4. 169.254.1.51

第二个和第三个从 #1 获取时间。但它们的低层还算可以，有 4 和 5。这是我在内部 NTP 服务器中期望的。它们报告的时间确实相当接近，与本地时钟的偏移量相似，并且它们的差异在抖动范围内。

此外，您还有 169.254.1.51，即第 11 层。层表示您与时间源（第 0 层）之间的距离。第 1 层与时间源相连，例如 GPS 或原子钟。第 2 层与第 1 层相连，依此类推。您有三个（实际上是一个，因为 #2 和 #3 引用 #1）服务器，它们会说，嘿，相信我，我距离时间源有四步之遥。它们在时间上达成一致。

然后你有一个，比这三个少了半秒，并且说这是十一距离可靠时钟还有几步之遥。当然，NTP 应该最信任较低层的 NTP 服务器。

此外，你把本地时钟篡改到第 10 层。实际上你是在说你信任本地时钟更多的而不是您首选的 NTP 服务器。这不会起作用。这里的设置完全是疯了。简而言之。NTP 是分层的，需要这样对待。

  1. 将 169.254.1.51 同步到外部池。池通常为 2-3 层，因此最终将为 3-4 层。这对于大多数用途来说已经足够了。
  2. 设置三个或更多 NTP 服务器，所有服务器都从其中一个池获取时间。您可以将它们相互对等，但不要让 #2&3 从 #1 获取时间。
  3. 让您的客户端使用您已设置的三个 NTP 服务器。
  4. 如果您无法拥有三台 NTP 服务器，请设置一台，或直接使用池。除非您拥有非常多（数千）的客户端，否则池将处理负载。
  5. 不要将本地时钟篡改到第 10 层 - 如果不同步，则不应信任。如果希望在一段时间内没有上游源可用时进行时间同步，请设置一服务器本地时钟到第十层。这将使其成为主如果没有可用的上游。
  6. 两个时间来源比一个更糟糕。如果你有一个，你就遵循它。如果你有两个，它们不一致，你就不知道该遵循哪一个。如果你有三个，其中两个同意，你知道该遵循哪一个。另一个选择是将其定义为 truechimer通过在服务器行中附加 true。

NTP 文档包含一些有关配置 NTP 的建议。您应该阅读它。

此外，使用 169.254.xx在网络中是一种奇怪的做法。我建议重新分配该网络的 IP，以使用健全的 RFC1918 空间。169.254.0.0/16 旨在作为自动链路本地网络，可能不应以这种方式使用。

相关内容