Предпочтительный сервер NTP был отклонен несмотря на то, что лучше сместил и дрожание
Нам настроили клиента 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
Вышеупомянутое для части конфигурации. Однако, когда мы проверяем системный журнал после конфигурации и системы перезапуска, Мы нашли, что клиент синхронизируется с внешним сервером вместо, предпочитают сервер, как получено в выводе ntpq в системном журнале
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}
Далее ниже сообщения сообщения непрерывно лавинно рассылал в системном журнале
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 предпочесть сервер лучше сместил и дрожание, даже затем это не выбрано.
Это возможный определить, что на том, какое основание это отклоняет предпочтенный сервер в этом случае.
РЕДАКТИРОВАНИЕ-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 ответ
Посмотрите на это так: у вас есть четыре сервера:
- 10.241.34.2
- 10.241.34.3
- 10.241.34.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 является иерархическим и должен рассматриваться как таковой.
- Синхронизируйте 169.254.1.51 с внешним пулом. Бассейны, как правило, страты 2-3, так что в конечном итоге это будет слой 3-4. Это достаточно хорошо для большинства целей.
- Настройте три или более сервера NTP, каждый из которых получает время от одного из пулов. Вы можете сравнивать их друг с другом, но не заставляйте # 2 и 3 получать время от # 1.
- Заставьте своих клиентов использовать три настроенных вами NTP-сервера.
- Если у вас не может быть трех серверов NTP, настройте один или используйте пулы напрямую. Пулы справятся с нагрузкой, если у вас не будет очень много (думаю, тысяч) клиентов.
- Не выдумывайте локальные часы для страты 10 - если они не синхронизированы, им нельзя доверять. Если вы хотите синхронизировать время, когда в течение некоторого промежутка времени нет источника в восходящем направлении, установите один локальных часов серверов на уровень десять. Это сделает его мастером , если нет восходящих каналов. 1115 Два источника времени хуже, чем один. Если он у вас есть, следуйте ему. Если у вас есть два, и они не согласны, вы не знаете, какой следовать. Если у вас есть три, и двое согласны, вы знаете, какой следовать. Еще одна альтернатива - определить его как truechimer , добавив в строку сервера значение true.
Документация NTP содержит некоторые рекомендации по настройке NTP. Вы, вероятно, должны прочитать это.
Кроме того, использование 169.254.x.x в сети - странная практика . Я бы порекомендовал повторно IP-сеть, чтобы использовать нормальное пространство RFC1918 . 169.254.0.0/16 задуман как автоматическая локальная сеть связи и, вероятно, не должен использоваться таким образом.