Назад | Перейти на главную страницу

Синхронизация NTP остается недосягаемой

Обычно, когда машина полностью теряет соединение, ntpd пропускает пару опросов и помечает все источники как неисправные. Что кажется вполне логичным. Но я встречал ситуацию, когда сервер остается отмеченным как текущий источник времени, а его охват равен 0.

Сервер развернут в той же подсети, что и целевая машина, обеспечивая очень малую задержку, смещение и джиттер. Ситуация была смоделирована путем физического отключения соединения: просто отсоединив шнур от клиентской машины. Я пытался воссоздать это, но с тех пор одна и та же машина всегда красиво теряет статус синхронизации после 5-6 неудачных опросов.

Реальный вопрос: что именно определяет статус синхронизации при потере соединения?

В RFC-1305 есть четкое объяснение регистра охвата:

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

Однако RFC-1305 устарел на RFC-5905, что не так уж важно:

Затем 8-битный сдвиговый регистр p.reach в процессе опроса, описанном в разделе 13, используется для определения доступности сервера и наличия свежих данных. При отправке пакета регистр сдвигается влево на один бит, а крайний правый бит устанавливается в ноль. Когда поступают действительные пакеты, крайний правый бит устанавливается в единицу. Если регистр содержит ненулевые биты, сервер считается доступным; в противном случае он недоступен.

В разделе 13 не упоминается четкая процедура. Но все же похоже, что недоступный одноранговый узел в какой-то момент должен потерять свой статус синхронизации.

Мне удалось воссоздать синхронизированный статус с ситуацией достижения 0, чтобы убедиться, что это редко и совсем не постоянно. Потребовалось отключить «всплеск» в конфигурации серверов и разорвать соединение сразу после синхронизации.

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 91.198.10.4     194.190.168.1    2 u   20   64  177   51.137   -2.192  11.049
 192.168.1.1     193.67.79.202    2 u   65   64   77    0.459   -1.818   0.922
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*91.198.10.4     194.190.168.1    2 u   21   64  177   51.137   -2.192  11.049
+192.168.1.1     193.67.79.202    2 u    -   64  177    0.449   -3.192   1.828

Досягаемость составила 177, что составляет 01111111 в двоичном формате. Так что для установления синхронизации потребовалось 7 опросов.

Тогда синхронизация была потеряна в этой позиции:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+91.198.10.4     194.190.168.1    2 u  574   64    0   63.846   -9.652   0.756
*192.168.1.1     193.67.79.202    2 u  553   64    0    0.449   -3.192   0.505
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 91.198.10.4     194.190.168.1    2 u  575   64    0   69.871  -10.409   0.002
 192.168.1.1     193.67.79.202    2 u  554   64    0    0.449   -3.192   0.505

Когда числа немного странные, например, 64 * 9 = 576, а не 575, но я думаю, представление может быть неточным на 1 секунду. Учитывая это, для нарушения статуса синхронизации потребовалось 9 неудачных опросов.

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