У меня есть Linux-бокс, настроенный с двумя серверами NTP для синхронизации. Этот блок, на всякий случай, был крайне рассинхронизирован (61 секунда) перед принудительной синхронизацией. Следующие выходные данные происходят через 1 час после этой синхронизации. При проверке ntpq,
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
x192.168.[redacted] .MDM. 1 u 113 256 377 0.513 13.120 1.843
x192.168.[redacted] .MDM. 1 u 115 128 377 2.689 0.618 1.230
Оба настроены на фальцет!
ntpq> assoc
ind assID status conf reach auth condition last_event cnt
===========================================================
1 13191 91d4 yes yes none falsetick reachable 13
2 13192 91d4 yes yes none falsetick reachable 13
Что привело к тому, что алгоритм выбора времени установил оба значения как ложные, и как я могу это исправить?
ОБНОВИТЬ!
Я повторно запустил приведенные выше команды и получил новый статус:
ntpq> assoc
ind assID status conf reach auth condition last_event cnt
===========================================================
1 13191 91d4 yes yes none falsetick reachable 13
2 13192 96d4 yes yes none sys.peer reachable 13
ntpq> pe
remote refid st t when poll reach delay offset jitter
==============================================================================
x192.168.[red] .MDM. 1 u 241 256 377 0.513 13.120 1.396
*192.168.[red] .MDM. 1 u 114 256 377 2.671 0.567 0.710
Оба ваших вышестоящих сервера заявляют, что они являются серверами уровня 1. - то есть наивысший класс источника времени, который может говорить по протоколу NTP, тот, к которому напрямую подключен источник абсолютного времени (например, атомные часы или приемник GPS) - но их часы отличаются друг от друга (то есть ваше смещение от каждого сервера (насколько далеко ваши часы находятся от него, когда вы получаете его сигнал) намного больше, чем наблюдаемая задержка распространения (сколько времени требуется, чтобы получить сигнал времени от каждого сервера)).
Столкнувшись с двумя серверами, которые оба утверждают, что являются авторитетными, но говорят разное время, ntpd вполне резонно говорит, что не может сделать выбор между ними и будет считать их обоих шарлатанами.
Теперь, похоже, предоставлено самому себе, ntpd через час решил, что предпочитает одно другому, и согласился выполнить синхронизацию с ним. Молодец.
Основная проблема здесь в том, что апстримы между собой говорят что-то, что не может быть правдой.. Если вам нужны только тяжелые времена, перечислите только один из них в своем ntp.conf, и вы будете синхронизироваться с ним намного быстрее. Если вам нужно точное время, обратитесь к администраторам серверов и спросите их, почему их часы различаются и где каждый из них получает свой источник времени.
редактировать: если бы я угадал, я бы сказал, что обе из них ошибочны - я предполагаю, что они оба были настроены для обработки своих внутренних часов или какого-либо аналогичного недостаточно точного источника времени как stratum-0. Они также могли быть настроены на получение времени от интернет-серверов, но, поскольку им сказали, что к ним подключены абсолютно точные часы, они предпочитают это время и, как следствие, рекламируют их как страту-1.
Человек с одними часами знает, который час. Человек с двумя часами никогда не уверен.
Вам нужно добавить еще один сервер, чтобы ntpd мог разорвать связь между двумя часами. Из всего возможного количества ассоциаций серверов два тактовых сигнала - худшая установка. Не имеет значения, является ли третий сервер слоем 2 или слоем 3, вам просто нужно дать ntpd шанс определить, кто фальшивый.
PS
Вам не нужно редактировать адреса RFC1918. На самом деле, когда вы редактируете их вот так, отвечать становится сложнее. Было бы лучше, если бы вы переключили, какие октеты вы отредактировали: xxx.xxx.1.1 и xxx.xxx.1.2. По крайней мере, так легко сослаться на одно или другое. Но самое главное - 1918 адресов редактировать действительно не нужно.