В настоящее время NTP отклоняет свой восходящий поток и довольно сильно дрейфует (15 секунд смещения пока что и растет). При проверке причины с помощью ntpq флэш-код flash=400 peer_dist.
Проверяя документацию NTP, одноранговый узел помечается как удаленный, если обратный путь занимает больше 1,5 секунд. Однако, используя tcpdump, я вижу, что пакеты уходят, а ответ возвращается в миллисекундах:
09:06:36.304204 IP 10.127.255.230.ntp > 10.127.255.213.ntp: NTPv4, Client, length 68
09:06:36.304371 IP 10.127.255.213.ntp > 10.127.255.230.ntp: NTPv4, Server, length 68
Общая архитектура здесь - это сервер с 1 протоколом TCP в этой подсети (который получает свое время от восходящего потока за пределами кластера), который обслуживает время для узлов в подсети. Сервер синхронизирован и обслуживает время в обычном режиме, однако все узлы в подсети сообщают как unsynchronised.
Простой перезапуск ntpd не имеет никакого эффекта, поскольку одноранговый узел все еще отклонен. Однако после изменения maxdist с помощью tos maxdist 5000 в ntp.conf, затем он синхронизирует (flash=00 ok).
Почему ntp думает, что расстояние больше 1,5 с, когда я могу видеть (используя ntpq / tcpdump), что запросы завершаются за миллисекунды? Есть ли какой-то внутренний параметр NTP, который я могу настроить, кроме maxdist что здесь имеет смысл? Есть ли еще какая-то отладка, чтобы диагностировать это?
Это всего лишь один пример кластера, в котором это происходит, но я вижу те же симптомы в других местах.
Для справки вот (язвительный) ntp документация для maxdist:
maxdist maxdistance
Specify the synchronization distance threshold used by the clock selection algorithm. The default is 1.5 s. This determines both the minimum number of packets to set the system clock and the maximum roundtrip delay. It can be decreased to improve reliability or increased to synchronize clocks on the Moon or planets.
Если ntpd сообщает код peer_dist для восходящего однорангового узла, это означает, что между корневой дисперсией, сообщенной одноранговым узлом, и дисперсией, измеренной в одноранговой ассоциации, 1,5-секундный порог был превышен.
Учитывая, что ваши запросы выполняются за несколько миллисекунд, вполне вероятно, что проблема связана с вышестоящим слоем. Чтобы подтвердить или опровергнуть это, вам нужно проанализировать захват пакета. Вы контролируете и апстрим?
Здесь, вероятно, стоит упомянуть, что ваш проект с 1 сервером NTP в подсети, связанным с 1 сервером NTP в восходящем направлении, означает, что вы отменяете алгоритмы выбора и кластеризации, что приведет к менее точному времени для клиентов. Каждая страта NTP должна иметь 4-10 источников для максимальной точности.