Почему NTP синхронизируется с ЛОКАЛЬНЫМ, а не с удаленным сервером?

Итак, я пытаюсь отладить мою текущую настройку NTP, и обнаружил, что смещение от моего единственного настроенного сервера составляет более 3 секунд, а не регулировка. Звездочка на LOCAL (0) в выводе ntpq, похоже, указывает на то, что система успешно синхронизируется с собой, а не с сервером 10.130.33.201 (который является еще одним linux-боксом в нашей системе, с которым мы хотим, чтобы все синхронизировалось).

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.130.33.201   LOCAL(0)         9 u   49   64  377    0.242  -3742.2   1.049
*LOCAL(0)        .LOCL.          10 l    2   64  377    0.000    0.000   0.001

И это мой файл ntp.conf. Написано кем-то другим, поэтому я не уверен на 100%, что все правильно.

server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift

restrict -4 default  nomodify nopeer notrap
restrict -6 default  ignore

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

Я читал о взрывах, iburst и minpoll / maxpoll, поэтому я понимаю, что они могут и не понадобиться, но я не думаю, что это как-то связано с моей текущей проблемой.

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

РЕДАКТИРОВАТЬ -

Итак, похоже, что это дубликат этого вопроса , но я не чувствую, что у автора есть достаточный ответ, поэтому я все же хотел бы знать, почему местное время предпочитается серверу. Кроме того, согласно одному из ответов ниже, я попытался использовать preferключевое слово в строке сервера конфигурации и перезапустить, но это, похоже, не дало эффекта.

Если я уберу все «локальные» строки в конфигурации, поскольку ответ на другой вопрос подсказывает, что произойдет, если сервер недоступен? NTP умирает или он просто продолжает пытаться?

ВАЖНОЕ РЕДАКТИРОВАНИЕ -

Хорошо, обычно 10.130.33.201 («сервер») не имеет доступа к Интернету и не имеет источника времени GPS для использования. Важным моментом является то, что все устройства в системе имеют одинаковое время с сервером, независимо от того, насколько корректным является это время.

Итак, просто чтобы посмотреть, что произойдет, я добавил один из серверов пулов NTP в конфигурационный файл сервера, чтобы он получал время оттуда, а не от локального. Теперь он правильно получает время с сервера времени NTP.

После этого клиенты теперь синхронизируются с сервером, а не предпочитают LOCAL (0).

 ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.130.33.201   38.229.71.1      3 u   58   64  377    0.216  715621.   1.001
 LOCAL(0)        .LOCL.          10 l   18   64  377    0.000    0.000   0.001

НОВЫЙ ВОПРОС - Когда мой сервер использует локальный (оригинальный пример, который был дан), кажется, что клиенты говорят: «О, 10.130.33.201 использует LOCAL (0). Хм, у меня также есть LOCAL (0) сервер - - Я просто буду использовать это напрямую, а не получать ту же информацию через 10.130.33.201 ".

Это тот случай? Они пытаются перейти "прямо к источнику", который неверно ЛОКАЛЬНЫЙ (0)? Мне нужен мой сервер, чтобы получать время от LOCAL (0), и мне нужны клиенты, чтобы получать время с сервера. Сейчас удаление «локального» сервера из файлов конфигурации клиента - единственный вариант, но я хотел бы понять, почему это происходит, и, если это вообще возможно, избегать изменения их конфигураций (изменение конфигурации будет большой работой из-за наше окружение...).

Кроме того, это выглядит как еще один дубликат без хорошего ответа.

Если настроен только один NTP-сервер, алгоритм не совсем уверен, кому доверять. Несмотря на то, что страта ниже с удаленным хостом, я уверен, что алгоритм считает, что местное время более надежно.

Попробуйте использовать preferключевое слово в своем serverзаявлении, чтобы установить его в качестве источника предпочтительного времени.

РЕДАКТИРОВАТЬ -

Итак, похоже, что это дубликат этого вопроса, но я не чувствую, что у автора есть достаточный ответ, поэтому я все же хотел бы знать, почему местное время предпочитается серверу.

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

Если я уберу все «локальные» строки в конфигурации, поскольку ответ на другой вопрос подсказывает, что произойдет, если сервер недоступен? NTP умирает или он просто продолжает пытаться?

Демон NTP не умирает и не останавливается, но завершает синхронизацию после того, как ему не удается достичь удаленного сервера. Вот почему лучшие практики предложат минимум три удаленных сервера и не использовать LCL, если вы не отключены от сети. Предлагаются три сервера, потому что, когда есть только два, и они не согласны, какой он выберет? Третий сервер должен помочь алгоритму устранить фиктивный сервер.

Наконец, я просто заметил, что вы не определяете driftfile. Это может помочь?

Мне кажется, что интервал смещения (разница между вашим системным временем и временем хоста NTP) слишком сильно отличается для NTP, чтобы правильно установить его.

Мое предложение,

 1. Stop the NTP service
 2. As root ntpdate -bs 10.130.33.201 to reset your time to something close
 3. Start the NTP service

У вас не должно быть проблем после этого.

Уровень 10.130.33.201 в качестве LOCAL-сервера равен 9, что делает локальный уровень, рассчитанный из этого (9 + 1 = 10), конкурирующим с локальным LOCAL-сервером на уровне 10. Поскольку локальный LOCAL-уровень не имеет сетевых задержек или дрожания, он может выглядеть немного лучше для ntpd, чем удаленный.

Если вы хотите, чтобы эта конфигурация работала, установите для основного сервера LOCAL уровень ниже 9. Не слишком низкий, если вы хотите, чтобы время, прослеживаемое до уровня 1, было предпочтительным.

Я знаю, что это старо, но я думаю, что вы правы. Никто не показывает способ отладки проблем с ntpd. Оказывается, это выполнимо.

Я думаю, что вы были на правильном пути, когда вы подозревали, что использование LOCAL (0) локально и на вышестоящем сервере может быть проблемой.

Это определенно было на острове времени из 4 серверов, с которым у меня была похожая проблема. Все они были настроены быть равными друг другу, так что, возможно, это была другая проблема для вас.

Однако, во-первых, есть лучший способ обработки островов времени, называемый бесхозным режимом, который поддерживается версиями ntpd последних нескольких лет:

Сиротский режим на doc.ntp.org

Первоначально все 4 сервера имели одинаковый уровень 10 и предпочитали свои локальные часы. Я исправил это, и все же они предпочли свои локальные часы (хотя слой действительно важен).

Я использовал команду ntpq pe (peer), as, rv, чтобы понять, что происходит. Вам нужно использовать rv (readvar) в номере ассоциации для сервера, чтобы вывести информацию. pe и as, похоже, отсортированы по одному и тому же индексу, так что вы можете получить таким же образом число. as имеет поле с именем condition, которое может показывать отклонение значения, если оно не нравится серверу.

В выводе rv есть поле, называемое flash. Если все хорошо, это будет ноль. Если нет, то это битовая маска (отображается в шестнадцатеричном формате) проблем. Их можно посмотреть здесь:

ntpd внутренние декодеры

У меня была проблема 0800 peer_loop. Оказалось, что ремонт часов важен. При просмотре LOCAL (0) как на локальных часах, так и на удаленном сервере, ntpd подумал, что есть цикл. Дэвид Миллс подтверждает, что в сообщениях на comp.protocols.time 'Как избежать зацикливания в NTP' (я достиг своего лимита в 2 ссылки, извините!)

Использование аргумента refid для fudge для установки уникального refid не сработало - оно все равно отображается как LOCAL (0) у получателя.

То, что действительно работало, использовало уникальные номера экземпляров для локального драйвера. 127.127.1. [0-3]. Используйте один и тот же идентификатор как на сервере, так и на линии выдумки. Когда я делал это, серверы обычно синхронизировались с сервером самого низкого уровня, который обычно использовал свои локальные часы. Однако иногда он пытался использовать один из других серверов, который использовал его в качестве источника. Однако времена были синхронизированы и, похоже, остались такими.

Возможно, слишком поздно, чтобы помочь, но я предлагаю это, чтобы показать, что NTP поддается логике и устранению неполадок. Я потратил часы, пытаясь найти ответ методом проб и ошибок, а потом нашел документы.

Используйте iburst, чтобы заставить сервер отправлять запрос NTP нужному NTS даже в случае сбоя одного запроса.