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

Мне кажется, что интервал смещения (разница между вашим системным временем и время хоста 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 как ЛОКАЛЬНЫЙ сервер равен 9, что заставляет локальный слой, рассчитанный на основе этого (9 + 1 = 10), конкурировать с локальным ЛОКАЛЬНЫМ сервером на уровне 10. Поскольку локальный сервер ЛОКАЛЬНЫЙ слой не имеет сетевых задержек или джиттера, он может выглядеть немного лучше для ntpd, чем удаленный.

Если вы хотите, чтобы эта конфигурация работала, установите «главный» ЛОКАЛЬНЫЙ сервер на уровень ниже 9. Не слишком низкий, если вы хотите, чтобы время прослеживалось до сервера уровня 1.

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

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

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

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

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

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

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

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

Внутреннее декодирование ntpd

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

Использование аргумента refid для fudge для установки уникального refid не сработало - он по-прежнему отображается как ЛОКАЛЬНЫЙ (0) у получателя.

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

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

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