Предпочтительный NTP-сервер был отклонен, несмотря на лучшее смещение и дрожание

Question 1

У нас есть клиент NTP, настроенный в одной из наших систем. Клиент имеет набор серверов, с которыми он может синхронизироваться.

Однако предпочтительный сервер, который мы выбрали, является нашим внутренним главным сервером с IP 169.254.1.51.

Содержимое Ниже перечислены ntp.conf: -

# --- CLIENT NETWORK ------- # --- USER SETTINGS BEGIN --- server 10.241.34.2 iburst server 10.241.34.3 iburst server 10.241.34.4 iburst restrict 10.241.34.2 mask 255.255.255.255 nomodify notrap noquery restrict 10.241.34.3 mask 255.255.255.255 nomodify notrap noquery restrict 10.241.34.4 mask 255.255.255.255 nomodify notrap noquery # --- USER SETTINGS END --- # --- NTP MULTICASTCLIENT --- restrict 169.254.0.0 mask 255.255.0.0 nomodify notrap # internal network # --- INTERNAL TIMESERVERS BEGIN----- server 169.254.1.51 burst iburst minpoll 4 maxpoll 6 prefer #Internal master Server # --- GENERAL CONFIGURATION --- server 127.127.1.0 iburst minpoll 4 # local clock fudge 127.127.1.0 stratum 10 tinker step 0

Вышеуказанное относится к части конфигурации. Однако, когда мы проверяем syslog после конфигурации и перезапуска системы, мы обнаружили, что клиент синхронизируется с внешним сервером, а не предпочитает сервер, как показано в выводе ntpq в syslog

Mar 22 05:52:48 Node ntpcheck: remote refid st t when poll reach delay offset jitter Mar 22 05:52:48 Node ntpcheck: ============================================================================== Mar 22 05:52:48 Node ntpcheck: *10.241.34.2 10.240.33.1 4 u 2 64 1 0.192 -519.50 5.769 Mar 22 05:52:48 Node ntpcheck: 10.241.34.3 10.241.34.2 5 u 1 64 1 0.172 -523.79 8.912 Mar 22 05:52:48 Node ntpcheck: 10.241.34.4 10.241.34.2 5 u 2 64 1 0.207 -520.73 8.082 Mar 22 05:52:48 Node ntpcheck: 169.254.1.51 LOCAL(0) 11 u 1 16 1 0.113 -0.043 2.099 Mar 22 05:52:48 Node ntpcheck: 127.127.1.0 .LOCL. 10 l 14 16 1 0.000 0.000 0.001}

Далее сообщение ниже постоянно заливается в syslog

Mar 22 06:51:11 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:51:27 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:51:45 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:52:03 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:52:20 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:52:35 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:52:51 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:53:06 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:53:20 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:53:23 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:53:38 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:53:53 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:54:11 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:54:29 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:54:47 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:55:02 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:55:20 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:55:21 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:55:35 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:55:53 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:56:10 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:56:28 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:56:46 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:57:03 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:57:21 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:57:38 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:57:54 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:58:09 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:58:24 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:58:42 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:58:59 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:59:15 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 06:59:30 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 06:59:46 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4 Mar 22 07:00:02 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10 Mar 22 07:00:17 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4

Мы попытались проверить на форумах NTP и определили, что он использует параметр ниже, определяя, что сервер предпочитает синхронизацию (Ссылка: - https://www.eecis.udel.edu /~mills/ntp/html/warp.html): -

Первый уровень отклонения происходит на основе смещения и задержки. Затем, после отклонения пула, оставшиеся в живых передаются алгоритму кластеризации часов. Алгоритм кластеризации зависит от дрожания. Оставшиеся все серверы являются выбираемыми оставшимися в живых, любой из них можно выбрать. Теперь роль предпочтительного ключевого слова вступает в игру, и все выбираемые проверяются и предпочитают выбирать. Если оставшегося в живых нет, то правило миграции определяет партнера.

Однако в выходе ntpq предпочтительный сервер имеет лучшее смещение и дрожание, даже тогда он не выбран.

Можно ли определить, на каком основании он отклоняет предпочтительный сервер в этот случай.

EDIT -1

Далее мы нашли syslog для обозначения выбора 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

Question 2

Посмотрите на это: у вас есть четыре сервера:

10.241.34.2 10.241.34.3 10.241.34.4 169.254.1.51

Номер два и три получают свое время от # 1. Но они являются OK-ish low stratum, с 4 и 5. Это то, чего я ожидал бы на внутреннем сервере NTP. Они сообщают о довольно близких временах, с аналогичными смещениями к вашим местным часам, и их различия находятся в пределах дрожания.

Кроме того, у вас есть 169.254.1.51, который является стратой 11. Страт говорит что-то о том, как далеко удалены из источника времени (stratum 0). Страт 1 соединен с источником времени, например. GPS или атомные часы. Stratum 2 соединен со стратой 1 и т. Д. У вас есть три (на самом деле один, потому что # 2 и # 3 ссылаются на # 1) серверы, которые говорят, эй, поверь мне, я в четырех шагах от источника времени. Они соглашаются на время.

Тогда у вас есть один, это половина секунды от этих трех, и говорит, что одиннадцать шагов удалены из надежных часов. Конечно, NTP должен доверять более низким уровням NTP-серверов.

Кроме того, вы подталкиваете локальные часы к stratum 10. Фактически вы говорите, что доверяете локальным часам eleven , чем ваш предпочтительный сервер NTP. Это не будет работать. Настройка здесь абсолютно безумная. Вкратце. NTP является иерархическим и должен рассматриваться как таковой.

10.241.34.2 Настройте три или более NTP-сервера, все время получения от одного из пулов. Вы можете сверять их друг с другом, но не делать # 2 и 3 получать время от # 1. 10.241.34.3 Если у вас нет трех серверов NTP, настройте их или используйте пулы напрямую. Пулы будут обрабатывать нагрузку, если у вас не будет много (думаю, тысяч) клиентов. 10.241.34.4 Два источника времени хуже одного. Если он у вас есть, вы следуете за ним. Если у вас двое, и они не согласны, вы не знаете, за кем следовать. Если у вас есть три, и два согласны, вы знаете, за кем следовать. Еще одна альтернатива - определить его как truechimer, добавив строку сервера с true.

Документация NTP содержит некоторые рекомендации по настройке NTP. Вы должны, вероятно, прочитать его.

Кроме того, используя 169.254.x.x Документацию NTP . Я бы рекомендовал повторно использовать эту сеть для использования разумного RFC1918-пространства. 169.254.0.0/16 предназначен как автоматическая локальная сеть связи и, вероятно, не должен использоваться таким образом.

Question 3

Question 4

Посмотрите на это: у вас есть четыре сервера:

10.241.34.2 10.241.34.3 10.241.34.4 169.254.1.51

Номер два и три получают свое время от # 1. Но они являются OK-ish low stratum, с 4 и 5. Это то, чего я ожидал бы на внутреннем сервере NTP. Они сообщают о довольно близких временах, с аналогичными смещениями к вашим местным часам, и их различия находятся в пределах дрожания.

Кроме того, у вас есть 169.254.1.51, который является стратой 11. Страт говорит что-то о том, как далеко удалены из источника времени (stratum 0). Страт 1 соединен с источником времени, например. GPS или атомные часы. Stratum 2 соединен со стратой 1 и т. Д. У вас есть три (на самом деле один, потому что # 2 и # 3 ссылаются на # 1) серверы, которые говорят, эй, поверь мне, я в четырех шагах от источника времени. Они соглашаются на время.

Тогда у вас есть один, это половина секунды от этих трех, и говорит, что одиннадцать шагов удалены из надежных часов. Конечно, NTP должен доверять более низким уровням NTP-серверов.

Кроме того, вы подталкиваете локальные часы к stratum 10. Фактически вы говорите, что доверяете локальным часам eleven , чем ваш предпочтительный сервер NTP. Это не будет работать. Настройка здесь абсолютно безумная. Вкратце. NTP является иерархическим и должен рассматриваться как таковой.

10.241.34.2 Настройте три или более NTP-сервера, все время получения от одного из пулов. Вы можете сверять их друг с другом, но не делать # 2 и 3 получать время от # 1. 10.241.34.3 Если у вас нет трех серверов NTP, настройте их или используйте пулы напрямую. Пулы будут обрабатывать нагрузку, если у вас не будет много (думаю, тысяч) клиентов. 10.241.34.4 Два источника времени хуже одного. Если он у вас есть, вы следуете за ним. Если у вас двое, и они не согласны, вы не знаете, за кем следовать. Если у вас есть три, и два согласны, вы знаете, за кем следовать. Еще одна альтернатива - определить его как truechimer, добавив строку сервера с true.

Документация NTP содержит некоторые рекомендации по настройке NTP. Вы должны, вероятно, прочитать его.

Кроме того, используя 169.254.x.x Документацию NTP . Я бы рекомендовал повторно использовать эту сеть для использования разумного RFC1918-пространства. 169.254.0.0/16 предназначен как автоматическая локальная сеть связи и, вероятно, не должен использоваться таким образом.

vidarlo · Answer 1 · 17 July 2018 в 17:34

Посмотрите на это: у вас есть четыре сервера:

10.241.34.2 10.241.34.3 10.241.34.4 169.254.1.51

Номер два и три получают свое время от # 1. Но они являются OK-ish low stratum, с 4 и 5. Это то, чего я ожидал бы на внутреннем сервере NTP. Они сообщают о довольно близких временах, с аналогичными смещениями к вашим местным часам, и их различия находятся в пределах дрожания.

Кроме того, у вас есть 169.254.1.51, который является стратой 11. Страт говорит что-то о том, как далеко удалены из источника времени (stratum 0). Страт 1 соединен с источником времени, например. GPS или атомные часы. Stratum 2 соединен со стратой 1 и т. Д. У вас есть три (на самом деле один, потому что # 2 и # 3 ссылаются на # 1) серверы, которые говорят, эй, поверь мне, я в четырех шагах от источника времени. Они соглашаются на время.

Тогда у вас есть один, это половина секунды от этих трех, и говорит, что одиннадцать шагов удалены из надежных часов. Конечно, NTP должен доверять более низким уровням NTP-серверов.

Кроме того, вы подталкиваете локальные часы к stratum 10. Фактически вы говорите, что доверяете локальным часам eleven , чем ваш предпочтительный сервер NTP. Это не будет работать. Настройка здесь абсолютно безумная. Вкратце. NTP является иерархическим и должен рассматриваться как таковой.

10.241.34.2 Настройте три или более NTP-сервера, все время получения от одного из пулов. Вы можете сверять их друг с другом, но не делать # 2 и 3 получать время от # 1. 10.241.34.3 Если у вас нет трех серверов NTP, настройте их или используйте пулы напрямую. Пулы будут обрабатывать нагрузку, если у вас не будет много (думаю, тысяч) клиентов. 10.241.34.4 Два источника времени хуже одного. Если он у вас есть, вы следуете за ним. Если у вас двое, и они не согласны, вы не знаете, за кем следовать. Если у вас есть три, и два согласны, вы знаете, за кем следовать. Еще одна альтернатива - определить его как truechimer, добавив строку сервера с true.

Документация NTP содержит некоторые рекомендации по настройке NTP. Вы должны, вероятно, прочитать его.

Кроме того, используя 169.254.x.x Документацию NTP . Я бы рекомендовал повторно использовать эту сеть для использования разумного RFC1918-пространства. 169.254.0.0/16 предназначен как автоматическая локальная сеть связи и, вероятно, не должен использоваться таким образом.

vidarlo · Answer 2 · 23 July 2018 в 18:25

Посмотрите на это: у вас есть четыре сервера:

10.241.34.2 10.241.34.3 10.241.34.4 169.254.1.51

Номер два и три получают свое время от # 1. Но они являются OK-ish low stratum, с 4 и 5. Это то, чего я ожидал бы на внутреннем сервере NTP. Они сообщают о довольно близких временах, с аналогичными смещениями к вашим местным часам, и их различия находятся в пределах дрожания.

Кроме того, у вас есть 169.254.1.51, который является стратой 11. Страт говорит что-то о том, как далеко удалены из источника времени (stratum 0). Страт 1 соединен с источником времени, например. GPS или атомные часы. Stratum 2 соединен со стратой 1 и т. Д. У вас есть три (на самом деле один, потому что # 2 и # 3 ссылаются на # 1) серверы, которые говорят, эй, поверь мне, я в четырех шагах от источника времени. Они соглашаются на время.

Тогда у вас есть один, это половина секунды от этих трех, и говорит, что одиннадцать шагов удалены из надежных часов. Конечно, NTP должен доверять более низким уровням NTP-серверов.

Кроме того, вы подталкиваете локальные часы к stratum 10. Фактически вы говорите, что доверяете локальным часам eleven , чем ваш предпочтительный сервер NTP. Это не будет работать. Настройка здесь абсолютно безумная. Вкратце. NTP является иерархическим и должен рассматриваться как таковой.

10.241.34.2 Настройте три или более NTP-сервера, все время получения от одного из пулов. Вы можете сверять их друг с другом, но не делать # 2 и 3 получать время от # 1. 10.241.34.3 Если у вас нет трех серверов NTP, настройте их или используйте пулы напрямую. Пулы будут обрабатывать нагрузку, если у вас не будет много (думаю, тысяч) клиентов. 10.241.34.4 Два источника времени хуже одного. Если он у вас есть, вы следуете за ним. Если у вас двое, и они не согласны, вы не знаете, за кем следовать. Если у вас есть три, и два согласны, вы знаете, за кем следовать. Еще одна альтернатива - определить его как truechimer, добавив строку сервера с true.

Документация NTP содержит некоторые рекомендации по настройке NTP. Вы должны, вероятно, прочитать его.

Кроме того, используя 169.254.x.x Документацию NTP . Я бы рекомендовал повторно использовать эту сеть для использования разумного RFC1918-пространства. 169.254.0.0/16 предназначен как автоматическая локальная сеть связи и, вероятно, не должен использоваться таким образом.

Привет @vidarlo, Большое вам спасибо за ответ. Я хотел бы предоставить вам дополнительную информацию. — ananTgarg, 4 April 2018 в 08:12
В нашей системе у нас есть главный сервер 169.254.1.51, а ведомый сервер 169.254.1.52, SO в соответствии с ведомым дизайнером всегда следует за мастером, как он предпочитает. И идея состоит в том, чтобы позволить мастер-синхронизации с внешним сервером NTP и подчиненной синхронизацией с ведущим. Теперь возникла проблема, когда главный сервер потерял связь с сервером NTP. Теперь мастер-синхронизация со своим локальным (stratum 10) и подчиненная синхронизация с удаленным сервером (stratum 4). Это хорошо, как указано выше, но теперь вопрос, который ставит этот анализ в мало сомнений, что через 2 дня подчиненный снова синхронизируется с Мастером, несмотря на то, что мастер имеет более высокий уровень 11. — ananTgarg, 4 April 2018 в 08:20
Поскольку этот комментарий нельзя добавить в журнал, я добавляю журналы в EDIT1 вопроса. — ananTgarg, 4 April 2018 в 08:25
Я бы сказал, начните с вашей установки, и прочитайте предложения в документации NTP, и, например, этот совет от Redhat . — vidarlo, 4 April 2018 в 08:25

Предпочтительный NTP-сервер был отклонен, несмотря на лучшее смещение и дрожание

EDIT -1

2 ответа

Другие вопросы по тегам:

Похожие вопросы: