Ntp режимы работы

Как сделать недорогую, но надежную систему единого времени на предприятии

Время на прочтение
10 мин

Количество просмотров 17K

В наше время не каждый специалист может отнести сервер точного времени к категории технически сложных устройств. На просторах Интернета существует большое количество статей о том, как сделать собственный аппаратный NTP-сервер. Тем не менее, решения, применяемые в промышленных приложениях и предлагаемые мировыми производителями, сложно назвать бюджетными. Существует ли возможность оптимизировать эти затраты, не снижая качества и надежности подсистемы точного времени на предприятии?

Для чего нужно точное время?

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

В системах видеонаблюдения таймсервер обеспечивает привязку отснятых видеозаписей к астрономическому времени. Также устройство позволяет безошибочно сопоставлять информацию от разных информационных систем на предприятии. Например, это могут быть системы видеонаблюдения и системы безопасности, такие как СКУД, системы РЗА и независимые системы телемеханики и пр.

Ряд протоколов информационного обмена используют метки времени напрямую в составе пакетов передаваемых данных. К таким протоколам можно отнести МЭК-101/104, применяемые в современных системах телемеханики.

Одним из важных требований, предъявляемых в ряде промышленных приложений, являются требования информационной безопасности, исключающие выход в Интернет для выполнения функции синхронизации времени.

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

Протокол NTP

Network time protocol (NTP) — это сетевой протокол для синхронизации часов в компьютерных системах по сетям передачи данных с коммутацией пакетов и переменной задержкой (латентностью). Высокая популярность протокола объясняется активным развитием систем на основе Ethernet. Одним из ключевых преимуществ протокола является возможность передачи меток времени непосредственно по сети передачи данных, что позволяет отказаться от отдельной шины точного времени, как например в системах 1PPS или IRIG–B. Протокол был разработан в 1985 году и является одним из старейших Интернет-протоколов, используемых в настоящее время.

NTP обеспечивает приемлемую точность синхронизации для большинства приложений. Протокол может поддерживать время с точностью до десятков миллисекунд в сети Интернет и до 0,2 мс в локальных сетях при идеальных условиях. Асимметричные маршруты передачи данных и перегрузка сети могут привести к ошибкам в 100 мс и более.

NTP синхронизирует устройства относительно всемирного координированного времени (UTC). При этом протокол учитывает появление високосной секунды в результате неравномерности вращения Земли, но никакой информации о местных часовых поясах или переходе на летнее время не передает.

Структура системы

NTP использует иерархическую систему источников точного времени. Каждый уровень иерархии называется Stratum (стратой, слоем) и ему присваивается номер, начинающийся с 0 для эталонных часов на вершине иерархии. Сервер времени на слое N синхронизируется от серверов на уровне N-1. Число N представляет собой расстояние от эталонных часов и используется для предотвращения цикличности в процессе синхронизации. Stratum не всегда является показателем качества или надежности. Например, можно найти источники времени на слое 3, которые имеют более высокое качество, чем источники времени на слое 2.

Stratum 0

В качестве эталонных часов на Stratum 0 выступают системы спутниковой навигации (ГЛОНАСС, GPS и пр.), атомные часы или радиопередатчики. Раз в секунду они генерируют импульсный сигнал (1PPS), который вызывает прерывание и генерирует метку времени на подключенных устройствах. Устройства слоя 0 также известны как опорные часы. Серверы NTP не могут позиционировать себя в системе как Stratum 0. Если в пакете передачи данных в поле Stratum установлен 0, это указывает на неопределенный слой.

gj2afssgadrg86as sfcpz75uam
Логическая структура системы синхронизации на основе NTP

Stratum 1

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

Stratum 2

Это устройства, которые синхронизируются по сети от серверов уровня 1. Часто устройства уровня 2 опрашивают несколько серверов уровня 1. Компьютеры Stratum 2 также могут быть одноранговыми с другими компьютерами Stratum 2, чтобы обеспечить более стабильное и надежное время для всех устройств в группе одноранговых узлов.

Максимальное теоретическое число слоев равно 15; Stratum 16 используется для указания того, что устройство не синхронизировано. Механизмы протокола NTP на каждом устройстве системы взаимодействуют таким образом, чтобы построить кратчайший путь к серверам Stratum 1 для всех клиентов. Это позволяет минимизировать накопленную задержку в передаче данных и повысить точность синхронизации. В основе алгоритма построения связующего дерева с минимальной длиной пути лежит алгоритм Беллмана-Форда.

Метки времени

Изначально NTP использовал 64-битные метки времени, состоявшие из 32-битной части для секунд и 32-битной части для долей секунды, что давало временную шкалу, которая прокручивалась бы каждые 2³² секунды (136 лет) и давало теоретическое разрешение 2^-32 секунды (233 пикосекунды). Отсчет времени начинался с 1 января 1900 года, поэтому первая эпоха закончилась бы 7 февраля 2036 года.

Последняя версия протокола NTPv4 вводит 128-битный формат представления времени: 64 бита для секунд и 64 бита для долей секунды, что дает временную шкалу более 584 млрд лет и разрешение в 0,05 аттосекунд. Дополнительно было введено 32-битное поле номера эры, которое устранило даже ставшей теоретической проблему окончания каждой эпохи.

Алгоритм синхронизации часов

Клиент NTP регулярно опрашивает один или несколько серверов. При этом он вычисляет смещение времени и круговую задержку. Смещение времени θ представляет собой разницу в абсолютном времени между часами сервера и клиента и определяется по формуле:

Круговая задержка δ определяется как время передачи сигнала по линиям связи от клиента к серверу и обратно. Это время, затраченное на отправку сигнала, плюс время, которое требуется для подтверждения, что сигнал был получен:

где t₀ — метка времени клиента для передачи пакета запроса,
t₁ — метка времени сервера приема пакета запроса,
t₂ — метка времени сервера для передачи ответного пакета,
t₃ — метка времени клиента приема ответного пакета.

Алгоритм расчета смещения времени и круговой задержки

Вычисляемые значения θ и δ пропускаются через фильтры и подвергаются статистическому анализу. Выбросы из общей выборки отбрасываются и оценка временного смещения производится на основе оставшихся значений. Зная величины смещения времени и круговую задержку клиент подстраивает собственное время, чтоб добиться θ равного нулю.

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

Механизмы передачи

В большинстве случаев протокол NTP использует классическую клиент-серверную модель работы, в которой клиент отправляет запрос и через некоторое время получает ответ от сервера. Однако протокол допускает работу и в одноранговых системах, где два одноранговых узла (peer) рассматривают друг друга как потенциальный источник времени. Этот режим работы также называют симметричным. Для сетевого взаимодействия NTP использует протокол UDP, по умолчанию работая на порту 123. Для передачи данных могут быть использованы различные механизмы – unicast, broadcast, multicast и manycast.

Режим Unicast

Протокол NTP для передачи данных чаще всего использует режим Unicast. В этом режиме данные передаются от одного устройства сети к другому индивидуально. В Unicast пакетах в качестве IP-адреса назначения используется конкретный адрес устройства, для которого этот пакет предназначен.

Режим Broadcast

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

Этот режим имеет ряд особенностей. Во-первых, режим Broadcast обеспечивает меньшую точность синхронизации по сравнению с Unicast. Во-вторых, широковещательные пакеты могут передаваться только в рамках одной подсети. Кроме того, для защиты от злоумышленников желательно использовать методы аутентификации.

Режим Multicast

Режим Multicast работает аналогично Broadcast. Разница заключается в том, что для доставки пакетов используется не широковещательный адрес подсети, а адрес Multicast-группы. Для клиентов и серверов задается групповой IP-адрес, который они используют для синхронизации времени. Это делает возможным синхронизацию групп машин, расположенных в различных подсетях, при условии, что соединяющие их маршрутизаторы поддерживают протокол IGMP и настроены на передачу группового трафика.

Режим Manycast

Этот режим является нововведением последней версии (v4) протокола NTP. Режим Manycast функционирует как режим Multicast только с неизвестными IP-адресами серверов NTP. Путем рассылки Multicast-сообщений клиент ищет в сети Manycast-сервера, получает от каждого из них образцы времени и производит выбор трех «лучших», с которыми будет производить синхронизацию. В случае выхода из строя одного из серверов клиент автоматически обновляет свой список.

Для передачи образцов времени клиенты и серверы, работающие в Manycast-режиме, также используют адреса Multicast-групп. Клиенты и серверы, использующие один и тот же адрес, формируют одну ассоциацию. Количество ассоциаций определяется количеством используемых Multicast-адресов.

Версии протокола

С момента своего появления в 1985 года протокол начал активно развиваться и уже к 1992 году сменил четыре версии (от NTPv0 до NTPv3). Каждая новая версия добавляла функционал и оптимизировала его работу, но оставляла неизменным формат данных и сохраняла совместимость различных версий между собой. Последняя четвертая версия протокола датирована 2010 годом. NTP продолжает развитие и в наши дни, ведутся работы по созданию решения, технически схожего с более точным протоколом PTP (Precision Time Protocol).

SNTP

Одновременно с NTPv3 в 1992 году была представлена более простая версия протокола – SNTP (Simple NTP). В протоколе SNTP используется одинаковый с протоколом NTP формат передачи и представления данных. При этом SNTP не касается алгоритмов работы сервера, а упрощает алгоритмы работы клиентов. Именно поэтому протокол чаще всего используется во встраиваемых системах и устройствах, не требующих высокой точности.

Разница между NTP и SNTP заключается в методах определения оптимальных серверов для синхронизации и методе коррекции времени. Так NTP позволяет клиенту использовать математический алгоритм пересечений (переработанную версию алгоритма Марзулло) для выбора нескольких лучших серверов в сети и плавно корректировать свое время. В SNTP для синхронизации используется один предопределенный NTP сервер, в то время как другие могут являться лишь резервными на случай потери связи с основным устройством. При этом клиент, использующий SNTP, способен корректировать время только скачком по факту получения ответа от сервера.

Типовая схема системы синхронизации и ее недостатки

Традиционно система точного времени на промышленных объектах строится на основе NTP-сервера, состоящего из головного устройства, монтируемого в одном шкафу с сетевым оборудованием, и выносной антенны, которая устанавливается на улице и подключается к серверу при помощи коаксиального кабеля. При этом на головном устройстве имеется несколько сетевых интерфейсов (Ethernet или RS-232/485) для подключения клиентов в одной или нескольких сетях.

ma7u qk5dvu0qnb5cm3fncgphsk
Типовая схема системы точного времени

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

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

Также к недостаткам можно отнести необходимость применения выносной антенны и коаксиального кабеля. Почему? Прежде всего, стоимость качественной GPS/ГЛОНАСС антенны с длинным кабелем и защитой от грызунов легко может перевалить за 10 000 руб. в ценах 2020 года. При этом коаксиальные кабели имеют ограниченную длину для передачи сигналов спутниковых систем. При длине более 50 м сигнал будет значительно затухать, что является серьезным ограничивающим фактором в больших зданиях.

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

Как сделать систему дешевле и надежнее

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

Всё решение, связанное с системой синхронизации, включая GPS/ГЛОНАСС антенну, может уместиться в небольшую коробочку, как это сделано в
FL TIMESERVER от Phoenix Contact. Устройство выполнено по принципу smart-антенны, то есть совмещает в себе непосредственно функционал сервера времени и антенну GPS/ГЛОНАСС приемника. Конструктивное исполнение – это единственное, что отличает его от привычных решений.

eq8pr
Сервер времени FL TIMESERVER NTP

В плане функционала никаких отличий нет: устройство способно принимать метки времени и данные геолокации от спутниковых систем навигации (ГЛОНАСС, GPS) и транслировать эту информацию для клиентов в сети Ethernet.

an9c0l5vgkynzrrbg3rqqqrotgc
Система точного времени на основе решения Phoenix Contact

При использовании подобного решения система синхронизации значительно упрощается и позволяет избавиться от недостатков традиционного подхода. FL TIMESERVER имеет только один порт Ethernet, но при необходимости использовать несколько интерфейсов достаточно подключить его в коммутатор или же использовать несколько smart-антенн. В этом случае мы получим полноценное резервирование серверов времени, а не только его сетевого интерфейса. При этом конечное решение все равно окажется дешевле многих существующих аналогов. FL TIMESERVER можно вынести за пределы сетевого шкафа или шкафа автоматизации, сэкономив место внутри. В этом решении не требуется отдельная антенна, здесь она уже встроена и к сети предприятия мы можем подключаться обычным Ethernet кабелем. В свою очередь это позволяет вынести сервер времени на расстояние до 100 м от основного оборудования без опасения, что сигнал затухнет. Самым главным преимуществом подобного решения является совсем другой порядок цен. Стоимость одного сервера времени менее 300 евро, что делает его удобным в применении как в небольших, так и в крупных проектах.

Источник

Доброго дня, гости и постоянные читатели блога. Постепенно перехожу от основ к более углубленному изучению Linux. Сегодня хочу рассмотреть работу протокола ntp, а так же настройку сервера времени на Linux (ntp server). Итак, начнем с теории.

Протокол NTP

Сервер времени FL TIMESERVER NTP

Как показывает практика, устройство способно обеспечивать связь со спутниковыми системами даже внутри зданий, но для более надежного приема сигналов может эксплуатироваться в уличных условиях, потому что выполнено в корпусе с уровнем пылевлагозащиты IP68 и способно работать в широком температурном диапазоне от -40 до +70 С. При этом сервер времени монтируется как обычная антенна, имеет резервированное питание от цепи 24 В постоянного тока и/или через Ethernet кабель (РоЕ) и диагностируется по SNMP. При монтаже на открытом воздухе используется герметизирующий кабельный ввод, чтоб сохранить высокий уровень пылевлагозащиты.

В плане функционала никаких отличий нет: устройство способно принимать метки времени и данные геолокации от спутниковых систем навигации (ГЛОНАСС, GPS) и транслировать эту информацию для клиентов в сети Ethernet.

Система точного времени на основе решения Phoenix Contact

При использовании подобного решения система синхронизации значительно упрощается и позволяет избавиться от недостатков традиционного подхода. FL TIMESERVER имеет только один порт Ethernet, но при необходимости использовать несколько интерфейсов достаточно подключить его в коммутатор или же использовать несколько smart-антенн. В этом случае мы получим полноценное резервирование серверов времени, а не только его сетевого интерфейса. При этом конечное решение все равно окажется дешевле многих существующих аналогов. FL TIMESERVER можно вынести за пределы сетевого шкафа или шкафа автоматизации, сэкономив место внутри. В этом решении не требуется отдельная антенна, здесь она уже встроена и к сети предприятия мы можем подключаться обычным Ethernet кабелем. В свою очередь это позволяет вынести сервер времени на расстояние до 100 м от основного оборудования без опасения, что сигнал затухнет. Самым главным преимуществом подобного решения является совсем другой порядок цен. Стоимость одного сервера времени менее 300 евро, что делает его удобным в применении как в небольших, так и в крупных проектах.

Источник

Доброго дня, гости и постоянные читатели блога. Постепенно перехожу от основ к более углубленному изучению Linux. Сегодня хочу рассмотреть работу протокола ntp, а так же настройку сервера времени на Linux (ntp server). Итак, начнем с теории.

Протокол NTP

Network Time Protocol (NTP) — сетевой протокол для синхронизации внутренних часов компьютера с использованием сетей с переменной латентностью (читай «шириной»/качеством канала).

NTP использует для своей работы протокол UDP и порт 123.

Текущая версия протокола — NTP 4. NTP использует иерархическую систему «часовых уровней» (их так же называют Stratum). Уровень 0 (или Stratum 0) — это, обычно, устройства представляющие собой атомные часы (молекулярные, квантовые), GPS часы или радиочасы. Данные устройства обычно не публикуются во всемирную сеть, а подключаются напрямую к серверам времени уровня 1 посредством протокола RS-232 (на иллюстрации обозначены желтыми стрелками). Уровень 1 синхронизирован с высокоточными часами уровня 0, обычно работают в качестве источников для серверов уровня 2. Уровень 2 синхронизируется с одной из машин уровня 1, а так же возможна синхронизация с серверами своего уровня. Уровень 3 работает аналогично второму. Обычно в сеть публикуются сервера уровней от второго и ниже. Протокол NTP поддерживает до 256 уровней. Так же хочется отметить, что сервера уровней 1 и2, а иногда и 3 не всегда открыты для всеобщего доступа. Иногда, чтобы синхронизироваться с ними, необходимо послать запрос по почте — администраторам домена.

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

Назначение сервера NTP в локальной сети

Для чего нам может понадобиться NTP server? Например, существуют службы в операционных системах, которые могут зависеть от синхронизированного времени. Наиболее ярким примером таких служб является протокол аутентификации Kerberos. Для его работы необходимо, чтобы на компьютерах, доступ к которым осуществляется с использованием этого протокола, системное время различалось не более чем на 5 минут. Кроме того, точное время на всех компьютерах значительно облегчает анализ журналов безопасности при расследовании инцидентов в локальной сети.

Режимы работы NTP сервера/клиента

Клиент/сервер

Этот режим на сегодняшний день наиболее часто используется в сети Интернет. Схема работы – классическая. Клиент посылает запрос, на который в течение некоторого времени сервер присылает ответ. Настройка клиента производится с помощью директивы server в конфигурационном файле, где указывается DNS имя сервера времени.

Симметричный активный/пассивный режим

Этот режим используется в том случае, если производится синхронизация времени между большим количеством равноправных машин. Помимо того, что каждая машина синхронизируется с внешним источником, она также осуществляет синхронизацию со своими соседями (peer), выступая для них в качестве клиента и сервера времени. Поэтому даже если машина «потеряет» внешний источник, она все еще сможет получить точное время от своих соседей. Соседи могут работать в двух режимах – активном и пассивном. Работая в активном режиме, машина сама передает свое время всем машинам-соседям, перечисленным в секции peers конфигурационного файла ntp.conf. Если же в этой секции соседи не указаны, то считается, что машина работает в пассивном режиме. Для того чтобы злоумышленник не смог скомпрометировать другие машины, представившись в качестве активного источника, необходимо использовать аутентификацию.

Режим Broadcast

Этот режим рекомендуется использовать в тех случаях, когда малое количество серверов обслуживает большое количество клиентов. Работая в этом режиме, сервер периодически рассылает пакеты, используя широковещательный адрес подсети. Клиент, настроенный на синхронизацию таким способом, получает широковещательный пакет сервера и производит синхронизацию с сервером. Особенностью этого режима является то, что время доставляется в рамках одной подсети (ограничение broadcast-пакетов). Кроме того, для защиты от злоумышленников необходимо использовать аутентификацию.

Режим Multicast

Данный режим во многом похож на broadcast. Отличие заключается в том, что для доставки пакетов используются multicast-адреса сетей класса D адресного пространства IP-адресов. Для клиентов и серверов задается адрес multicast-группы, которую они используют для синхронизации времени. Это делает возможным синхронизацию групп машин, расположенных в различных подсетях, при условии, что соединяющие их маршрутизаторы поддерживают протокол IGMP и настроены на передачу группового трафика.

Режим Manycast

Этот режим является нововведением четвертой версии протокола NTP. Он подразумевает поиск клиентом среди своих сетевых соседей manycast-серверов, получение от каждого из них образцов времени (с использованием криптографии) и выбор на основании этих данных трех «лучших» manycast-серверов, с которыми клиент будет производить синхронизацию. В случае выхода из строя одного из серверов клиент автоматически обновляет свой список.

Для передачи образцов времени клиенты и серверы, работающие в manycast-режиме, используют адреса multicast-групп (сети класса D). Клиенты и серверы, использующие один и тот же адрес, формируют одну ассоциацию. Количество ассоциаций определяется количеством используемых multicast-адресов.

Время в Linux

Кратко расскажу, какое время существует в Linux и как его задать. В Linux, как и в другой ОС, существует 2 времени. Первые — аппаратные, иногда называемые Real Time Clock, сокращенно (RTC) (они же — часы BIOS) обычно они связаны с колеблющимся кварцевым кристаллом, имеющим точность хода до нескольких секунд в день. Точность зависит от различных колебаний, например, окружающей температуры. Вторые часы — внутренние программные часы, которые идут непрерывно, в том числе и при перерывах в работе системы. Они подвержены отклонениям, связанным с большой системной нагрузкой и задержкой прерываний. Однако система обычно считывает показания аппаратных часов при загрузке и потом использует системные часы.

Дата и время операционной системы устанавливается при загрузке на основании значения аппаратных часов, а так же настроек часового пояса. Настройки часового пояса берутся из файла /etc/localtime. Данный файл — есть ссылка (но чаще — копия) одного из файлов в структуре каталога /usr/share/zoneinfo/.

Аппаратные часы Linux могут хранить время в формате UTC (аналог GMT), либо текущее территориальное время. Общая рекомендация в том, какое время устанавливать (?) следующая: если на компьютере установлено несколько ОС и одна из них — Windows, то необходимо использовать текущее время (т.к. Windows берет время из BIOS/CMOS и считает его локальным). Если используются только операционные системы UNIX семейства, то желательно хранить время в BIOS в UTC формате.

После загрузки операционной системы, часы операционной системы и BIOS полностью независимы. Ядро системы раз в 11 секунд синхронизирует системные часы с аппаратными.

Через некоторое время между аппаратными и программными часами может быть разница в несколько секунд. Какие же часы содержат правильное время? Ни те, ни другие, пока мы не настроим синхронизацию времени.

Примечание:

Ядро Linux’а всегда хранит и вычисляет время, как число секунд прошедших с полночи 1-го января 1970 года, в независимости от того, установлены ваши часы на локальное или всемирное время. Преобразование в локальное время производится в процессе запроса.

Поскольку количество секунд с 1-го января 1970 года всемирного времени сохраняется как знаковое 32-битное целое (это справедливо для Linux/Intel систем), ваши часы перестанут работать где-то в 2038 году. Linux не имеет проблемы 2000-го года, но имеет проблему 2038 года. К счастью, к тому времени все linux’ы будут запущены на 64-х разрядных системах. 64-х битное целое будет содержать наши часы приблизительно до 292271-миллионного года.

NTP Server Linux

Введение

Существует масса реализаций для синхронизации времени для ОС Linux. Наиболее известными являются Xntpd (NTP версия 3), ntpd (NTP версия 4), Crony и ClockSpeed. В нашем примере мы будем использовать ntp-сервер ntpd.

Демон ntpd является одновременно и сервером времени и клиентом, в зависимости от настроек конфигурационного файла /etc/ntpd.conf (иногда /etc/ntp.conf), демон может и «принимать» время с уделенных серверов и «раздавать» другим хостам время.

Общая схема синхронизации времени в локальной сети следующая: необходимо иметь 1 или 2 сервера, имеющие доступ в глобальную сеть, которые будут получать время из интернет. Все компьютеры локальной сети синхронизировать с указанными серверами, получающими время из интернет.

Установка ntpd

Собственно, установка демона сводится к установке следующих пакетов: ntp (пакет включающий самого демона), ntpdate (утилита для ручной синхронизации времени — устарела), ntp-doc (документация по пакету), в некоторых дистрибутивах нужно будет установить так же ntp-utils (утилиты для диагностики), в некоторых они включены в пакет ntp. Как производить установку программ в Linux , я описывал в управление ПО Linux. После установки пакета, в большинстве дистрибутивов, демон будет уже сконфигурирован как как ntp-клиент (например в Debian было так). Соответственно, автоматически были созданы основные конфигурационные файлы: /etc/ntp.conf и /var/lib/ntp/ntp.drift и автоматом запущен демон.

Перед настройкой демона на синхронизацию с внешним миром я бы посоветовал установить текущую системную дату на значение, максимально приближенное к реальному времени. Установка даты в Linux производится командой: date MMDDhhmmCCYY.ss, где MM — месяц, DD — день месяца, hh — часы, mm — минуты, CCYY — 4 цифры года, ss — секунды. При этом, значения CCYY.ss указывать не обязательно.

ntp-server:~# date 121720062010.30 Птн Дек 17 20:06:30 MSK 2010

Как видно, указанная команда установит текущие дату и время на 27 декабря 2010года, 20:06:30. Команда date без параметров, выводить текущее системное время. У данной команды есть куча параметров, с которыми можно ознакомиться в man date.

Так же, необходимо правильно настроить аппаратные часы и часовой пояс. Как говорилось выше, часовой пояс настраивается копированием необходимого файла зоны из каталога /usr/share/zoneinfo/ в файл /etc/localtime:

ntp-server:~# cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Аппаратные часы я настроил на UTC:

[ntp1@proxy ~]# cat /etc/sysconfig/clock | grep UTC # UTC=true indicates that the clock is set to UTC; UTC=true

ntp2-server:~# cat /etc/default/rcS | grep UTC UTC=yes

В первом примере указан конфигурационный файл, определяющий использование UTC для RH, второй — для Deb-дистрибутивов.

Кроме установки настроек на использование времени в формате UTC, необходимо задать аппаратное время. (в большинстве случаев в этом нет необходимости, потому что заданное системное время неизбежно синхронизируется с аппаратным, силами ядра). Но все же, если у вас есть желание это сделать… Команда hwclock читает и устанавливает аппаратные часы на основании переданных ему параметров. Доступные параметры описаны в странице руководства команды. Вот несколько примеров использования hwclock:

ntp-server# hwclock    # считывает время из аппаратных часов ntp-server# hwclock --systohc --utc    # устанавливает время аппаратных часов равным # UTC на основании системного времени ntp-server# hwclock --systohc    # устанавливает время аппаратных часов # равным местному на основании системного времени ntp-server# hwclock --set --date "22 Mar 2002 13:17" # устанавливает время аппаратных часов # равным указанной строке

Другим вариантом изменения времени в аппаратных часах — это доступ в BIOS при загрузке системы. Поскольку время ОС независимо от аппаратных часов, любые изменения в BIOS будут учтены при следующей загрузке.

Теперь, когда у нас все подготовлено и установлено, приступим к настройке.

Управление демоном ntpd

Управление демоном ntpd ничем не отличается от управления любыми другими демонами. Запуск или перезапуск службы ntpd:

#/etc/init.d/ntp start #/etc/init.d/ntp restart

Остановка:

#/etc/init.d/ntp stop

Или:

#/bin/kill `cat /var/run/ntpd.pid`

Демон имеет следующие параметры запуска:

-p — PID-файл,
-g — разрешить переход на большой скачек времени
-c — конфиг файл
-q — принудительная ручная синхронизация

Настройка сервера ntpd

Первым делом, посоветую изменить параметры запуска демона в следующем конфигурационном файле :

Debian:

ntp-server:~# cat /etc/default/ntp NTPD_OPTS='-g'

RedHat:

[ntp2@proxy ~]# cat /etc/sysconfig/ntpd # Parameters for NTP daemon. # See ntpd(8) for more details. .... # Specifies additional parameters for ntpd. NTPD_ARGS="-g"

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

Итак, как я уже говорил, информация о конфигурации демона ntpd лежит в файле /etc/ntp.conf. Синтаксис файла стандартен, как и во многих других конфигах: пустые строки и строки, начинающиеся с символа «#» игнорируются. Вот простой пример:

ntp-server:~# cat /etc/ntp.conf server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift

Параметр server задает, какие серверы будут использоваться для синхронизации, по одному в каждой строке. Если сервер задан с аргументом prefer, как ntplocal.example.com, то этому серверу отдается предпочтение перед остальными. Ответ от предпочтительного сервера будет отброшен, если он значительно отличается от ответов других серверов, в противном случае он будет использоваться безотносительно к другим ответам. Аргумент prefer обычно используется для серверов NTP, о которых известно, что они очень точны, такими, на которых используется специальное оборудование точного времени.

Параметр driftfile задает файл, который используется для хранения смещения частоты системных часов. На сколько я понял, данный файл постоянно хранит какое-то значение, которое формируется на основании анализа прошедших корректировок времени и если внешние источники времени становятся недоступны, то корректировка времени происходит по значению из файла drift. Он не должен изменяться никакими другими процессами. И перед указанием данного файла в конфигурации — файл должен быть создан.

По умолчанию сервер NTP будет доступен всем хостам в Интернет. Параметр restrict в файле /etc/ntp.conf позволяет вам контролировать, какие машины могут обращаться к вашему серверу. Если вы хотите запретить всем машинам обращаться к вашему серверу NTP, добавьте следующую строку в файл /etc/ntp.conf:

restrict default ignore

Если вы хотите разрешить синхронизировать свои часы с вашим сервером только машинам в вашей сети, но запретить им настраивать сервер или быть равноправными участниками синхронизации времени, то вместо указанной добавьте строчку:

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

где 192.168.1.0 является IP адресом вашей сети, а 255.255.255.0 её сетевой маской. /etc/ntp.conf может содержать несколько директив restrict.

Для корректной и более точной работы демона, желательно выбрать сервера уровня — от stratum 2 (можно конечно stratum1, но придется убить время на поиски такого сервера) и из выбранных stratum 2 те, до которых минимальное «расстояние». Обычно такие сервера могут предоставляться вашим провайдером. Количество выбираемых серверов желательно — более 2-х 3-х, чем больше тем лучше, но в разумных пределах. Если Вам лень выбирать лучшие сервера, то можно взять список открытых серверов второго уровня отсюда: http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers.

Выбираем список эталонных NTP серверов

Идем по указанному адресу (http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers) и подбираем список начальных серверов. Из данного списка выбираем удовлетворяющий нашим требованиям серверы, с помощью анализа вывода команды ntpdate. При выполнении команды, применяется следующий синтаксис:

ntpdate параметры серверы_через_пробел

Для того чтобы наш запрос не вносил изменения в систему, необходимо использовать параметр -q, который указывает на использование запроса без внесения изменений. Так же, возможно использовать ключ -d, указывающий, что команда будет выполняться в отладочном режиме, с выводом дополнительных сведений, без внесения реальных изменений (при данном ключе выводится куча другого мусора :), который нам в данный момент не нужен ). Остальные параметры можно посмотреть в man 8 ntpdate. Из указанной ссылки я выбрал все сервера Open Access, расположенные в России (RU) + тот, который предоставил провайдер и запустил команду, получилось примерно следующее:

ntp-server:~# ntpdate -q ntp2.ntp-servers.net ntp1.vniiftri.ru ntp2.vniiftri.ru ntp4.vniiftri.ru ntp0.ntp-servers.net ntp1.ntp-servers.net ntp3.vniiftri.ru ntp.corbina.net server 88.147.255.85, stratum 1, offset 0.006494, delay 0.09918 server 62.117.76.142, stratum 1, offset 0.002552, delay 0.06920 server 62.117.76.141, stratum 1, offset 0.003147, delay 0.06918 server 62.117.76.140, stratum 1, offset 0.004823, delay 0.07350 server 88.147.254.228, stratum 1, offset -0.002355, delay 0.12030 server 88.147.254.229, stratum 1, offset -0.000922, delay 0.10577 server 62.117.76.138, stratum 1, offset 0.005331, delay 0.07401 server 195.14.40.141, stratum 2, offset 0.002846, delay 0.07188 13 Jan 19:14:09 ntpdate[1946]: adjust time server 62.117.76.141 offset 0.003147 sec

В примере наши сервера удачно выдали уровень stratum1, что не может не радовать (кроме сервера провайдера ), offset — это расхождение во времени с этим сервером в секундах, delay — задержка синхронизации в секундах. Обычно, бОльшая точность получается при использовании серверов, которые имеют низкую задержку передачи пакетов по сети. Для выявления этого, возможно воспользоваться утилитами ping и traceroute. Соответственно, выбрав сначала те, у которых время ответа меньше, а из них — те, до которых меньше хопов. Я же, чтобы не терять время, воспользуюсь всем указанными серверами и впишу их в конфигурационный файл. Итого, зная все вышеперечисленное, опишу свой получившийся файл /etc/ntp.conf:

ntp-server:~# cat /etc/ntp.conf # Сервера локальной сети (закомментированы, не используются - в сети один сервер) #server 192.168.0.2 #server 192.168.0.5 # интернет-сервера server ntp2.ntp-servers.net server ntp1.vniiftri.ru server ntp2.vniiftri.ru server ntp4.vniiftri.ru server ntp0.ntp-servers.net server ntp1.ntp-servers.net server ntp3.vniiftri.ru server ntp.corbina.net # Файлы сервера driftfile       /var/lib/ntp/ntp.drift logfile /var/log/ntpstats # ограничение доступа к серверу: # по умолчанию игнорируем все restrict        default ignore # локалхост без параметров - значит разрешено все. Параметры идут только на запреты. restrict        127.0.0.1 # далее описываются сервера с которыми мы синхронизируемся в локальной сети. # Разрешаем им все кроме трапов и запросов к нам restrict        192.168.0.2     noquery notrap restrict        192.168.0.5     noquery notrap # для локалки так же разрешаем все, кроме трапов и модификаций restrict        192.168.0.1 mask 255.255.255.0 nomodify notrap nopeer # разрешаем внешним источникам времени доступ: restrict ntp2.ntp-servers.net restrict ntp1.vniiftri.ru restrict ntp2.vniiftri.ru restrict ntp4.vniiftri.ru restrict ntp0.ntp-servers.net restrict ntp1.ntp-servers.net restrict ntp3.vniiftri.ru restrict ntp.corbina.net # а этот хак, который выставляет уровень доверия серверу (strata) самому себе равный 3 # в двух словах чем выше уровень-тем меньше число. 0 - это атомные часы, # 1 - это синхронизированные с ними, 2 - с первым, и так далее. server 127.127.1.1 fudge   127.127.1.1     stratum 3

Для более углубленного понимания и настройки сервера, опишу некоторые параметры конфигурации ntpd, о которых не упоминал::

enable/disable auth/monitor/pll/pps/stats — включить/выключить режим работы:

auth — с неупомянутыми соседями общаться только в режиме аутентификации;

monitor — разрешить мониторинг запросов;

pll — разрешить настраивать частоту местных часов по NTP;

stats — разрешить сбор статистики;

statistics loopstats — при каждой модификации локальных часов записывает строчку в файл loopstats;

statistics peerstats — каждое общение с соседом записывается в журнал, хранящийся в файле peerstats;

statistics clockstats — каждое сообщение от драйвера локальных часов записывается в журнал, хранящийся в файле clockstats;

statsdir {имя_каталого_со_статистикой} — задает имя каталога, в котором будут находится файлы со статистикой сервера;

filegen [file {filename}] [type {typename}] [flag {flagval}] [link|nolink] [enable|disable]— определяет алгоритм генерации имен файлов, которые состоят из:

префикс — постоянная часть имени файла, задается либо при компиляции, либо специальными командами конфигурации;

имя файла — добавляется к префиксу без косой черты, две точки запрещены, может быть изменена ключем file;

суффикс — генерируется в зависимости от typename;

restrict numeric-address [mask {numericc-mask}] [flag] — задает ограничение доступа: пакеты сортируются и маскам, берется исходный адрес и последовательно сравнивается, от последнего удачного сравнения берется флаг [flag]доступа:

нет флагов — дать доступ;

ignore — игнорировать все пакеты;

noquery — игнорировать пакеты NTP 6 и 7 (запрос и модификация состояния);

nomodify — игнорировать пакеты NTP 6 и 7 (модификация состояния);

limited — обслуживать только ограниченное количество клиентов из данной сети;

nopeer — обслуживать хост, но не синхронизироваться с ним;

clientlimit limit — для флага limited определяет максимальное количество обслуживаемых клиентов (по дефолту 3);

Итого, мы получили ntpd-server, который синхронизируется с внешним миром, позволяет получать время для клиентов из локальной сети 192.168.0.1 с маской 255.255.255.0, а так же может синхронизироваться с локальным сервером (если раскомментировать несколько строк). Нам осталось настроить клиентов и узнать, как наблюдать за нашим сервером.

Наблюдение за сервером ntpd и за синхронизацией

Когда у вас все настроено. NTP будет держать время в синхронизированном состоянии. Этот процесс можно наблюдать при помощи команды NTP Query (ntpq):

ntp-server:~# ntpq -p remote           refid      st t when poll reach   delay   offset jitter ============================================================================== -n3.time1.d6.hsd .PPS.            1 u   34   64 177   70.162    2.375   8.618 +ntp1.vniiftri.r .PPS.            1 u   33   64 177   43.479   -0.020 10.198 *ntp2.vniiftri.r .PPS.            1 u    6   64 177   43.616   -0.192   0.688 +ntp4.vniiftri.r .PPS.            1 u    4   64 177   43.623    0.440   0.546 -n1.time1.d6.hsd .PPS.            1 u   53   64   77   92.865 -11.358 38.346 -ns1.hsdn.org    .GPS.            1 u   40   64 177   78.057   -3.292 35.083 -ntp3.vniiftri.r .PPS.            1 u   44   64   77   47.667    2.292   2.611 -scylla-l0.msk.c 192.43.244.18    2 u   62   64   77   41.565   -1.564 28.914

Данная команда с ключом -p выводит на стандартный вывод список источников времени с их характеристиками (остальные параметры команды в man ntpq). Значение каждой колонки следующее:

remote

Имя удаленного NTP-сервера. Если указать ключ -n, вы получите IP-адреса серверов вместо имён.

refid

Указывает, откуда каждый сервер получает время в данный момент. Это может быть имя хоста или что-то вроде .GPS., указывающее на источник глобальной системы позиционирования (Global Positioning System).

st

Stratum (уровень) это число от 1 до 16, указывающее на точность сервера. Единица означает максимальную точность, 16 — сервер недоступен. Ваш уровень будет равен уровню наименее точного удаленного сервера плюс 1.

poll

Интервал между опросами (в секундах). Значение будет изменяться между минимальной и максимальной частотой опросов. В начале интервал будет маленьким, чтобы синхронизация происходила быстро. После того как часы синхронизируются, интервал начинает увеличиваться, чтобы уменьшить трафик и нагрузку на популярные сервера времени.

reach

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

delay

Количество времени (в секундах) необходимого для получения ответа на запрос «который час? «.

offset

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

jitter

Дисперсия (Jitter) — это мера статистических отклонений от значения смещения (поле offset) по нескольким успешным парам запрос-ответ. Меньшее значение дисперсии предпочтительнее, поскольку позволяет точнее синхронизировать время.

Значение знаков перед именами серверов

x — фальшивый источник по алгоритму пересечения;
. — исключён из списка кандидатов из-за большого расстояния;
— — удалено из списка кандидатов алгоритмом кластеризации;
+ — входит в конечный список кандидатов;
# — выбран для синхронизации, но есть 6 лучших кандидатов;
* — выбран для синхронизации;
o — выбран для синхронизации, но используется PPS;
пробел — слишком большой уровень, цикл или явная ошибка;

Служба ntpd «умная» и сама отсеивает источники времени слишком выбивающиеся за рамки разумного. Через некоторое время после запуска ntpd выберет наиболее достоверные источники данных и будет синхронизироваться с ними. Представленный нами список эталонных NTP серверов регулярно пересматривается службой.

Проверить возможность синхронизации локально на сервере возможно командой:

ntp-server:~# ntpdate -q localhost server 127.0.0.1, stratum 2, offset -0.000053, delay 0.02573 server ::1, stratum 2, offset -0.000048, delay 0.02571 14 Jan 14:49:57 ntpdate[2231]: adjust time server ::1 offset -0.000048 sec

Из вывода команды видно, что наш сервер уже стал уровня stratum 2. Для достижения данного уровня, необходимо некоторое время. Возможно, в первые 10-15 минут уровень сервера будет выше.

О корректной работе сервера ntp можно так же судить по логам демона ntpd:

ntp-server:~# cat /var/log/ntpstats/ntp 13 Jan 20:13:16 ntpd[1764]: Listening on interface #5 eth0, fe80::a00:27ff:fec1:8059#123 Enabled 13 Jan 20:13:16 ntpd[1764]: Listening on interface #6 eth0, 192.168.0.8#123 Enabled 14 Jan 14:31:00 ntpd[2217]: synchronized to 62.117.76.142, stratum 1 14 Jan 14:31:10 ntpd[2217]: time reset +10.291312 s 14 Jan 14:31:10 ntpd[2217]: kernel time sync status change 0001 14 Jan 14:34:31 ntpd[2217]: synchronized to 88.147.255.85, stratum 1 14 Jan 14:36:04 ntpd[2217]: synchronized to 62.117.76.141, stratum 1 14 Jan 15:04:36 ntpd[2217]: synchronized to 62.117.76.142, stratum 1 14 Jan 15:10:58 ntpd[2217]: synchronized to 62.117.76.140, stratum 1 14 Jan 15:17:54 ntpd[2217]: no servers reachable 14 Jan 15:31:49 ntpd[2217]: synchronized to 62.117.76.140, stratum 1 14 Jan 15:32:14 ntpd[2217]: time reset +13.139105 s

Настройка netfilter (iptables) для NTP сервера

Настроив работу сервера, неплохо было бы его защитить. Мы знаем, что сервер работает на 123/udp порту, при этом запросы так же отправляются с порта 123/udp. Ознакомившись со статьей, что такое netfilter и правила iptables и ознакомившись с практическими примерами iptables, можно создать правила фильтрации сетевого трафика:

ntp ~ # iptables-save # типовые правила iptables для DNS *filter :INPUT DROP [7511:662704] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP # разрешить доступ локальной сети к NTP серверу: -A INPUT -s 192.168.1.1/24 -d 192.168.1.1/32 -p udp -m udp --dport 123 -m conntrack --ctstate NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -p icmp -j ACCEPT -A OUTPUT -p udp -m udp --sport 32768:61000 -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 32768:61000 -j ACCEPT -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # разрешить доступ NTP серверу совершать исходящие запросы -A OUTPUT -p udp -m udp --sport 123 --dport 123 -m conntrack --ctstate NEW -j ACCEPT COMMIT

Это типовой пример! Для задания правил iptables под Ваши задачи и конфигурацию сети, необходимо понимать принцип работы netfilter в Linux, почитав вышеуказанные статьи.

Настройка клиентских машин

Для синхронизации времени на UNIX-машинах локальной сети целесообразно использовать утилиту ntpdate, запуская ее при помощи демона cron несколько раз в сутки, например каждый час. Для этого, в кронтаб пользователя root необходимо добавить следующую строку:

0 * * * * /usr/sbin/ntpdate -s <IP-адрес или FQDN-имя NTP-сервера локальной сети>

Ключ -s направляет вывод команды демону syslog. Если на клиентских машинах есть пару лишних мегабайт оперативки, то можно запустить демон ntpd, как и на сервере со следующим конфигом:

server <IP-адрес или FQDN-имя NTP-сервера локальной сети> restrict default ignore restrict <IP-адрес или FQDN-имя NTP-сервера локальной сети> noquery notrap restrict 127.0.0.1 nomodify notrap

Думаю, в данном конфиге все понятно: источник времени (server) — локальный ntpd-сервер, доступ всем запретить, разрешить только локальному ntpd-серверу.

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

Для настройки NTP клиента Windows, необходимо выполнить в консоли следующие команды:

C:>net time /setsntp:<IP-адрес или FQDN-имя NTP-сервера локальной сети> The command completed successfully. C:>net stop w32time The Windows Time service is stopping. The Windows Time service was stopped successfully. C:>net start w32time The Windows Time service is starting. The Windows Time service was started successfully. C:>net time /querysntp The current SNTP value is: <IP-адрес или FQDN-имя NTP-сервера локальной сети> The command completed successfully.

Заключение

Ну вроде все! Объем статьи получился громадным… Даже сам не ожидал. Подведу маленький итог изложенному. В данной статье нам, надеюсь, стало понятно что есть и как работает NTP-сервер. Научились настраивать сервер и клиентов на UNIX и Windows машинах. В нескольких словах, структура синхронизации времени в локальной сети следующая: Имеется 1,2 или более серверов точного времени в локальной сети, они синхронизируют свое время с внешними источниками в глобальной сети. Настройки сервера и клиентов основаны на файлах /etc/ntp.conf (основной конфигурационный файл демона ntpd), /etc/localtime (файл текущего часового пояса), а так же /etc/sysconfig/ntp (для RH) и /etc/default/ntp (для Deb) — файлы параметров запуска демона. Для локального ntp-сервера в конфигурационном файле указываются внешние сервера для получения времени и разрешается доступ для этих серверов параметром restrict, а так же для компьютеров локальной сети, для клиентов указывается источник времени — локальные сервера в локальной сети, а так же запрещается доступ для всех, кроме источника времени в локальной сети. Все. Всем спасибо за внимание! Буду рад комментариям!

Что могу посоветовать почитать дополнительно:

тут (архив статьи) описано, как подключить GPS к серверу для организации своего сервера точного времени уровня Stratum1.

тут описано, как настроить авторизацию на ntp-сервере.

Upd 2012.02.14: добавил настройку netfilter для NTP

С Уважением, Mc.Sim!

Другие материалы в категории NTP

NTP Server на Linux (ntpd)

Теги: daemon, NTP, service

Источник

Network Time Protocol

International standard RFC 5905

Developed by David L. Mills, Network Time Foundation

Introduced 1985

The Network Time Protocol (NTP) is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks. In operation since before 1985, NTP is one of the oldest Internet protocols in current use. NTP was designed by David L. Mills of the University of Delaware.

NTP is intended to synchronize all participating computers to within a few milliseconds of Coordinated Universal Time (UTC).^[1]^: 3 It uses the intersection algorithm, a modified version of Marzullo’s algorithm, to select accurate time servers and is designed to mitigate the effects of variable network latency. NTP can usually maintain time to within tens of milliseconds over the public Internet, and can achieve better than one millisecond accuracy in local area networks under ideal conditions. Asymmetric routes and network congestion can cause errors of 100 ms or more.^[2]^[3]

The protocol is usually described in terms of a client–server model, but can as easily be used in peer-to-peer relationships where both peers consider the other to be a potential time source.^[1]^: 20 Implementations send and receive timestamps using the User Datagram Protocol (UDP) on port number 123.^[4]^[5]^: 16 They can also use broadcasting or multicasting, where clients passively listen to time updates after an initial round-trip calibrating exchange.^[3] NTP supplies a warning of any impending leap second adjustment, but no information about local time zones or daylight saving time is transmitted.^[2]^[3]

The current protocol is version 4 (NTPv4),^[5] which is backward compatible with version 3.^[6]

History[edit]

RFC evolution for NTP

1980 —

–

1985 —

–

1990 —

–

1995 —

–

2000 —

–

2005 —

–

2010 —

–

2015 —

–

2020 —

–

←
DCNET Internet Clock Service^[14]

In 1979, network time synchronization technology was used in what was possibly the first public demonstration of Internet services running over a trans-Atlantic satellite network, at the National Computer Conference in New York. The technology was later described in the 1981 Internet Engineering Note (IEN) 173^[18] and a public protocol was developed from it that was documented in RFC 778. The technology was first deployed in a local area network as part of the Hello routing protocol and implemented in the Fuzzball router, an experimental operating system used in network prototyping, where it ran for many years.

Other related network tools were available both then and now. They include the Daytime and Time protocols for recording the time of events, as well as the ICMP Timestamp messages and IP Timestamp option (RFC 781). More complete synchronization systems, although lacking NTP’s data analysis and clock disciplining algorithms, include the Unix daemon timed, which uses an election algorithm to appoint a server for all the clients;^[19] and the Digital Time Synchronization Service (DTSS), which uses a hierarchy of servers similar to the NTP stratum model.

In 1985, NTP version 0 (NTPv0) was implemented in both Fuzzball and Unix, and the NTP packet header and round-trip delay and offset calculations, which have persisted into NTPv4, were documented in RFC 958. Despite the relatively slow computers and networks available at the time, accuracy of better than 100 milliseconds was usually obtained on Atlantic spanning links, with accuracy of tens of milliseconds on Ethernet networks.

In 1988, a much more complete specification of the NTPv1 protocol, with associated algorithms, was published in RFC 1059. It drew on the experimental results and clock filter algorithm documented in RFC 956 and was the first version to describe the client–server and peer-to-peer modes. In 1991, the NTPv1 architecture, protocol and algorithms were brought to the attention of a wider engineering community with the publication of an article by David L. Mills in the IEEE Transactions on Communications.^[20]

In 1989, RFC 1119 was published defining NTPv2 by means of a state machine, with pseudocode to describe its operation. It introduced a management protocol and cryptographic authentication scheme which have both survived into NTPv4, along with the bulk of the algorithm. However the design of NTPv2 was criticized for lacking formal correctness by the DTSS community, and the clock selection procedure was modified to incorporate Marzullo’s algorithm for NTPv3 onwards.^[21]

In 1992, RFC 1305 defined NTPv3. The RFC included an analysis of all sources of error, from the reference clock down to the final client, which enabled the calculation of a metric that helps choose the best server where several candidates appear to disagree. Broadcast mode was introduced.

In subsequent years, as new features were added and algorithm improvements were made, it became apparent that a new protocol version was required.^[22] In 2010, RFC 5905 was published containing a proposed specification for NTPv4.^[23] Following the retirement of Mills from the University of Delaware, the reference implementation is currently maintained as an open source project led by Harlan Stenn.^[24]^[25] On the IANA side, a ntp (network time protocols) work group is in charge of reviewing proposed drafts.^[26]

The protocol has significantly progressed since NTPv4.^[23] As of 2022, three RFC documents describing updates to the protocol have been published,^[5] not counting the numerous peripheral standards such as NTS (RFC 8915).^[26] Mills had mentioned plans for a «NTPv5» on his page, but one was never published.^[23] An unrelated draft termed «NTPv5» by M. Lichvar of chrony was initiated in 2020 and includes security, accuracy, and scaling changes.^[27]

SNTP[edit]

As NTP replaces the use of the old Time Protocol, some use-cases nevertheless finds the full protocol too complicated. In 1992, Simple Network Time Protocol (SNTP) was defined to fill this niche. The SNTPv3 standard describes a way to use NTPv3, such that no storage of state over extended periods of time is needed. The topology becomes essentially the same as with the Time Protocol, as only one server is used.^[10] In 1995, SNTP was updated to SNTPv4 with some features of the then-in-development NTPv4;^[12] the current latest version is RFC 5905, a 2010 revision of SNTPv4, merging it into the main NTPv4 standard.^[5] SNTP is fully interoperable with NTP since it does not define a new protocol.^[28] However, the simple algorithms provide times of reduced accuracy and thus it is inadvisable to sync time from an SNTP source.^[29]

Clock strata[edit]

Yellow arrows indicate a direct connection; red arrows indicate a network connection.

NTP uses a hierarchical, semi-layered system of time sources. Each level of this hierarchy is termed a stratum and is assigned a number starting with zero for the reference clock at the top. A server synchronized to a stratum n server runs at stratum n + 1. The number represents the distance from the reference clock and is used to prevent cyclical dependencies in the hierarchy. Stratum is not always an indication of quality or reliability; it is common to find stratum 3 time sources that are higher quality than other stratum 2 time sources.^[a] A brief description of strata 0, 1, 2 and 3 is provided below.

Stratum 0

These are high-precision timekeeping devices such as atomic clocks, GNSS (including GPS) or other radio clocks, or a PTP-synchonized clock.^[30] They generate a very accurate pulse per second signal that triggers an interrupt and timestamp on a connected computer. Stratum 0 devices are also known as reference clocks. NTP servers cannot advertise themselves as stratum 0. A stratum field set to 0 in NTP packet indicates an unspecified stratum.^[31]

Stratum 1

These are computers whose system time is synchronized to within a few microseconds of their attached stratum 0 devices. Stratum 1 servers may peer with other stratum 1 servers for sanity check and backup.^[32] They are also referred to as primary time servers.^[2]^[3]

Stratum 2

These are computers that are synchronized over a network to stratum 1 servers. Often a stratum 2 computer queries several stratum 1 servers. Stratum 2 computers may also peer with other stratum 2 computers to provide more stable and robust time for all devices in the peer group.

Stratum 3

These are computers that are synchronized to stratum 2 servers. They employ the same algorithms for peering and data sampling as stratum 2, and can themselves act as servers for stratum 4 computers, and so on.

The upper limit for stratum is 15; stratum 16 is used to indicate that a device is unsynchronized. The NTP algorithms on each computer interact to construct a Bellman-Ford shortest-path spanning tree, to minimize the accumulated round-trip delay to the stratum 1 servers for all the clients.^[1]^: 20

In addition to stratum, the protocol is able to identify the synchronization source for each server in terms of a reference identifier (refid).
Common time reference identifiers (refid) codes

Refid^[33] Clock Source

GOES Geosynchronous Orbit Environment Satellite

GPS Global Positioning System

GAL Galileo Positioning System

PPS Generic pulse-per-second

IRIG Inter-Range Instrumentation Group

WWVB LF Radio WWVB Fort Collins, Colorado 60 kHz

DCF LF Radio DCF77 Mainflingen, DE 77.5 kHz

HBG LF Radio HBG Prangins, HB 75 kHz (ceased operation)

MSF LF Radio MSF Anthorn, UK 60 kHz

JJY LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz

LORC MF Radio Loran-C station, 100 kHz

TDF MF Radio Allouis, FR 162 kHz

CHU HF Radio CHU Ottawa, Ontario

WWV HF Radio WWV Fort Collins, Colorado

WWVH HF Radio WWVH Kauai, Hawaii

NIST NIST telephone modem

ACTS NIST telephone modem

USNO USNO telephone modem

PTB German PTB time standard telephone modem

MRS (Informal) Multi Reference Sources

GOOG (Unofficial) Google Refid used by google NTP servers as time4.google.com

For servers on stratum 2 and below, the refid is an encoded form of the upstream time server’s IP address. For IPv4, this is simply the 32-bit address; for IPv6, it would be the first 32 bits of the MD5 hash of the source address. Refids serve to detect and prevent timing loops to the first degree.^[5]

The refid field is filled with status words in the case of kiss-o’-death (KoD) packets, which tell the client to stop sending requests so that the server can rest.^[5] Some examples are INIT (initialization), STEP (step time change), and RATE (client requesting too fast).^[34] The program output may additionally use codes not transmitted in the packet to indicate error, such as XFAC to indicate a network disconnection.^[33]

The IANA maintains a registry for refid source names and KoD codes. Informal assignments can still appear.^[35]

Timestamps[edit]

The 64-bit binary fixed-point timestamps used by NTP consist of a 32-bit part for seconds and a 32-bit part for fractional second, giving a time scale that rolls over every 2³² seconds (136 years) and a theoretical resolution of 2⁻³² seconds (233 picoseconds). NTP uses an epoch of January 1, 1900. Therefore, the first rollover occurs on February 7, 2036.^[36]^[37]

NTPv4 introduces a 128-bit date format: 64 bits for the second and 64 bits for the fractional-second. The most-significant 32-bits of this format is the Era Number which resolves rollover ambiguity in most cases.^[38]^[39] According to Mills, «The 64-bit value for the fraction is enough to resolve the amount of time it takes a photon to pass an electron at the speed of light. The 64-bit second value is enough to provide unambiguous time representation until the universe goes dim.»^[40]^[b]

Clock synchronization algorithm[edit]

A typical NTP client regularly polls one or more NTP servers. The client must compute its time offset and round-trip delay. Time offset θ is positive or negative (client time > server time) difference in absolute time between the two clocks. It is defined by

${displaystyle theta ={frac {(t_{1}-t_{0})+(t_{2}-t_{3})}{2}},}$

and the round-trip delay δ by

${displaystyle delta ={(t_{3}-t_{0})-(t_{2}-t_{1})},}$

where

t₀ is the client’s timestamp of the request packet transmission,

t₁ is the server’s timestamp of the request packet reception,

t₂ is the server’s timestamp of the response packet transmission and

t₃ is the client’s timestamp of the response packet reception.^[1]^: 19

To derive the expression for the offset, note that for the request packet,

${displaystyle t_{0}+theta +delta /2=t_{1}}$

and for the response packet,

${displaystyle t_{3}+theta -delta /2=t_{2}}$

Solving for θ yields the definition of the time offset.

The values for θ and δ are passed through filters and subjected to statistical analysis («mitigation»). Outliers are discarded and an estimate of time offset is derived from the best three remaining candidates. The clock frequency is then adjusted to reduce the offset gradually («discipline»), creating a feedback loop.^[1]^: 20

Accurate synchronization is achieved when both the incoming and outgoing routes between the client and the server have symmetrical nominal delay. If the routes do not have a common nominal delay, a systematic bias exists of half the difference between the forward and backward travel times. A number of approaches have been proposed to measure asymmetry,^[41] but among practical implementations only chrony seems to have one included.^[42]^[43]

Software implementations[edit]

The NTP management protocol utility ntpq being used to query the state of a stratum 2 server.

Reference implementation[edit]

The NTP reference implementation, along with the protocol, has been continuously developed for over 20 years. Backwards compatibility has been maintained as new features have been added. It contains several sensitive algorithms, especially to discipline the clock, that can misbehave when synchronized to servers that use different algorithms. The software has been ported to almost every computing platform, including personal computers. It runs as a daemon called ntpd under Unix or as a service under Windows. Reference clocks are supported and their offsets are filtered and analysed in the same way as remote servers, although they are usually polled more frequently.^[1]^: 15–19 This implementation was audited in 2017, finding 14 potential security issues.^[44]

Windows Time[edit]

All Microsoft Windows versions since Windows 2000 include the Windows Time service (W32Time),^[45] which has the ability to synchronize the computer clock to an NTP server.

W32Time was originally implemented for the purpose of the Kerberos version 5 authentication protocol, which required time to be within 5 minutes of the correct value to prevent replay attacks. The version in Windows 2000 and Windows XP only implements SNTP, and violates several aspects of the NTP version 3 standard.^[46]

Beginning with Windows Server 2003 and Windows Vista, W32Time became compatible with a significant subset of NTPv3.^[47] Microsoft states that W32Time cannot reliably maintain time synchronization with one second accuracy.^[48] If higher accuracy is desired, Microsoft recommends using a newer version of Windows or different NTP implementation.^[49]

Beginning with Windows 10 version 1607 and Windows Server 2016, W32Time can be configured to reach time accuracy of 1 s, 50 ms or 1 ms under certain specified operating conditions.^[50]^[48]^[51]

OpenNTPD[edit]

In 2004, Henning Brauer of OpenBSD presented OpenNTPD, an NTPv3/SNTPv4^[52] implementation with a focus on security and encompassing a privilege separated design. Whilst it is aimed more closely at the simpler generic needs of OpenBSD users, it also includes some protocol security improvements while still being compatible with existing NTP servers. The simpler code base sacrifices accuracy, deemed unnecessary in this use case.^[53] A portable version is available in Linux package repositories.

NTPsec[edit]

NTPsec is a fork of the reference implementation that has been systematically security-hardened. The fork point was in June 2015 and was in response to a series of compromises in 2014.^[specify] The first production release shipped in October 2017.^[54] Between removal of unsafe features, removal of support for obsolete hardware, and removal of support for obsolete Unix variants, NTPsec has been able to pare away 75% of the original codebase, making the remainder easier to audit.^[55] A 2017 audit of the code showed eight security issues, including two that were not present in the original reference implementation, but NTPsec did not suffer from eight other issues that remained in the reference implementation.^[56]

chrony[edit]

chrony is an independent NTP implementation mainly sponsored by Red Hat, who uses it as the default time program in their distributions.^[57] Being written from scratch, chrony has a simpler codebase allowing for better security^[58] and lower resource consumption.^[59] It does not however compromise on accuracy, instead syncing faster and better than the reference ntpd in many circumstances. It is versatile enough for ordinary computers, which are unstable, go into sleep mode or have intermittent connection to the Internet. It is also designed for virtual machines, a more unstable environment.^[60]

Chrony has been evaluated as «trustworthy», with only a few incidents.^[61] It is able to achieve improved precision on LAN connections, using hardware timestamping on the network adapter.^[42] Support for Network Time Security (NTS) was added on version 4.0.^[62] chrony is available under GNU General Public License version 2, was created by Richard Curnow in 1997 and is currently maintained by Miroslav Lichvar.^[59]

Others[edit]

Ntimed was started by Poul-Henning Kamp of FreeBSD in 2014 and abandoned in 2015.^[63] The implementation was sponsored by the Linux Foundation.^[64]

systemd-timesyncd is the SNTP client built into systemd. Albeit seldom written about, this implementation is used by Debian since version «bookworm»^[65] and the downstream Ubuntu.

Leap seconds[edit]

On the day of a leap second event, ntpd receives notification from either a configuration file, an attached reference clock, or a remote server. Although the NTP clock is actually halted during the event, because of the requirement that time must appear to be strictly increasing, any processes that query the system time cause it to increase by a tiny amount, preserving the order of events. If a negative leap second should ever become necessary, it would be deleted with the sequence 23:59:58, 00:00:00, skipping 23:59:59.^[66]

An alternative implementation, called leap smearing, consists in introducing the leap second incrementally during a period of 24 hours, from noon to noon in UTC time. This implementation is used by Google (both internally and on their public NTP servers), Amazon AWS,^[67] and Facebook.^[68] Chrony supports leap smear in smoothtime and leapsecmode configurations, but such use is not to be mixed with a public NTP pool as leap smear is non-standard and will throw off client calculation in a mix.^[69]

Security concerns[edit]

Only a few other security problems have been identified in the reference implementation of the NTP codebase, but those that appeared in 2009^[which?] were cause for significant concern.^[70]^[71] The protocol has been undergoing revision and review throughout its history. The codebase for the reference implementation has undergone security audits from several sources for several years.^[72]

A stack buffer overflow exploit was discovered and patched in 2014.^[73] Apple was concerned enough about this vulnerability that it used its auto-update capability for the first time.^[74] Some implementation errors are basic, such as a missing return statement in a routine, that can lead to unlimited access to systems that are running some versions of NTP in the root daemon. Systems that do not use the root daemon, such as those derived from Berkeley Software Distribution (BSD), are not subject to this flaw.^[75]^{[dubious – discuss]}

A 2017 security audit of three NTP implementations, conducted on behalf of the Linux Foundation’s Core Infrastructure Initiative, suggested that both NTP^[76]^[77] and NTPsec^[78] were more problematic than Chrony^[79] from a security standpoint.^[80]

NTP servers can be susceptible to man-in-the-middle attacks unless packets are cryptographically signed for authentication.^[81] The computational overhead involved can make this impractical on busy servers, particularly during denial of service attacks.^[82] NTP message spoofing from a man-in-the-middle attack can be used to alter clocks on client computers and allow a number of attacks based on bypassing of cryptographic key expiration.^[83] Some of the services affected by fake NTP messages identified are TLS, DNSSEC, various caching schemes (such as DNS cache), Border Gateway Protocol (BGP), Bitcoin^{[citation needed]}and a number of persistent login schemes.^[84]^[85]

NTP has been used in distributed denial of service attacks.^[86]^[87] A small query is sent to an NTP server with the return IP address spoofed to be the target address. Similar to the DNS amplification attack, the server responds with a much larger reply that allows an attacker to substantially increase the amount of data being sent to the target. To avoid participating in an attack, NTP server software can be upgraded or servers can be configured to ignore external queries.^[88]

Secure extensions[edit]

NTP itself includes support for authenticating servers to clients. NTPv3 supports a symmetric key mode, which is not useful against MITM. The public key system known as «autokey» in NTPv4 adapted from IPSec offers useful authentication,^[81] but is not practical for a busy server.^[82] Autokey was also later found to suffer from several design flaws,^[89] with no correction published, save for a change in the message authentication code in RFC 8573.

Network Time Security (NTS) is a secure version of NTPv4 with TLS and AEAD.^[90] The main improvement over previous attempts is that a separate «key establishment» server handles the heavy asymmetric cryptography, which needs to be done only once. If the server goes down, previous users would still be able to fetch time without fear of MITM.^[91] NTS is currently supported by several time servers,^[92]^[93] including CloudFlare. It is supported by NTPSec and chrony.^[94]

Microsoft also has an approach to authenticate NTPv3/SNTPv4 packets using a Windows domain identity, known as MS-SNTP.^[95] This system is implemented in the reference ntpd and chrony, using samba for the domain connection. ^[96]

See also[edit]

Allan variance

Clock network

International Atomic Time

IRIG timecode

NITZ

NTP pool

Ntpdate

Notes[edit]

^ Telecommunication systems use a different definition for clock strata.

^ 2⁻⁶⁴ seconds is about 54 zeptoseconds (light would travel 16.26 picometers, or approximately 0.31 × Bohr radius), and 2⁶⁴ seconds is about 585 billion years.

References[edit]

^ ^a ^b ^c ^d ^e ^f David L. Mills (12 December 2010). Computer Network Time Synchronization: The Network Time Protocol. Taylor & Francis. pp. 12–. ISBN 978-0-8493-5805-0. Archived from the original on 18 July 2014. Retrieved 16 October 2016.

^ ^a ^b ^c «Executive Summary: Computer Network Time Synchronization». Archived from the original on 2011-11-02. Retrieved 2011-11-21.

^ ^a ^b ^c ^d «NTP FAQ». The NTP Project. Archived from the original on 2011-09-06. Retrieved 2011-08-27.

^ «Port Numbers». The Internet Assigned Numbers Authority (IANA). Archived from the original on 2001-06-04. Retrieved 2011-01-19.

^ ^a ^b ^c ^d ^e ^f ^g D. Mills; J. Burbank; W. Kasch (August 2010). J. Martin (ed.). Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force (IETF). doi:10.17487/RFC5905. ISSN 2070-1721. RFC 5905. Proposed Standard. Obsoletes RFC 1305, 4330. Updated by RFC 7822, 8573 and 9109.

^ ^a ^b David L. Mills (March 1992). Network Time Protocol (Version 3) — Specification, Implementation and Analysis. Network Working Group. doi:10.17487/RFC1305. RFC 1305. Obsolete. Obsoleted by RFC 5905. Obsoletes RFC 958, 1059 and 1119.

^ D. Mills (September 1985). Network Time Protocol (NTP). Network Working Group. doi:10.17487/RFC0958. RFC 958. Obsolete. Obsoleted by RFC 1059, 1119 and 1305.

^ D. Mills (July 1988). Network Time Protocol (Version 1) Specification and Implementation. Network Working Group. doi:10.17487/RFC1059. RFC 1059. Obsolete. Obsoleted by RFC 1119 and 1305.

^ D. Mills (September 1989). Network Time Protocol (Version 2) Specification and Implementation. Network Working Group. doi:10.17487/RFC1119. RFC 1119. Obsolete. Obsoleted by RFC 1305. Obsoletes RFC 958 and 1059.

^ ^a ^b RFC 1361 Simple Network Time Protocol (SNTP), August 1992.

^ RFC 1769 Simple Network Time Protocol (SNTP), March 1995.

^ ^a ^b RFC 2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, October 1996.

^ RFC 4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, January 2006

^ RFC 778 DCNET Internet Clock Service, April 1981.

^ T. Mizrahi; D. Mayer (March 2016). Network Time Protocol Version 4 (NTPv4) Extension Fields. IETF. doi:10.17487/RFC7822. ISSN 2070-1721. RFC 7822. Informational. Updates RFC 5905.

^ A. Malhotra; S. Goldberg (June 2019). Message Authentication Code for the Network Time Protocol. IETF. doi:10.17487/RFC8573. ISSN 2070-1721. RFC 8573. .

^ F. Gont; G. Gont; M. Lichvar (August 2021). RFC 9109. Internet Engineering Task Force. doi:10.17487/RFC9109. ISSN 2070-1721. Proposed Standard. Updates RFC 5905

^ D.L. Mills (25 February 1981), Time Synchronization in DCNET Hosts, archived from the original on 1996-12-30

^ «TIMED(8)», UNIX System Manager’s Manual, archived from the original on 2011-07-22, retrieved 2017-09-12

^ David L. Mills (October 1991). «Internet Time Synchronization: The Network Time Protocol» (PDF). IEEE Transactions on Communications. 39 (10): 1482–1493. doi:10.1109/26.103043. Archived (PDF) from the original on 2016-06-10. Retrieved 2017-11-06.

^ David L. Mills (March 1992). Network Time Protocol (Version 3) — Specification, Implementation and Analysis. Network Working Group. doi:10.17487/RFC1305. RFC 1305. Obsolete. The clock-selection procedure was modified to remove the first of the two sorting/discarding steps and replace with an algorithm first proposed by Marzullo and later incorporated in the Digital Time Service. These changes do not significantly affect the ordinary operation of or compatibility with various versions of NTP, but they do provide the basis for formal statements of correctness.

^ David L. Mills (15 November 2010). Computer Network Time Synchronization: The Network Time Protocol on Earth and in Space, Second Edition. CRC Press. p. 377. ISBN 978-1-4398-1464-2.

^ ^a ^b ^c «Future Plans», Network Time Synchronization Research Project, archived from the original on 23 December 2014, retrieved 24 December 2014

^ «NTP Needs Money: Is A Foundation The Answer?». InformationWeek. March 23, 2015. Archived from the original on April 10, 2015. Retrieved April 4, 2015.

^ «NTP’s Fate Hinges On ‘Father Time’«. InformationWeek. March 11, 2015. Archived from the original on April 10, 2015. Retrieved April 4, 2015.

^ ^a ^b «Network Time Protocols (ntp): Documents». datatracker.ietf.org. Retrieved 27 December 2022.

^ Lichvar, Miroslav. «Network Time Protocol Version 5». www.ietf.org.

^ «Network Time Protocol Version 4: Protocol and Algorithms Specification». June 2010. p. 54. Archived from the original on 2012-09-10. Retrieved 2012-08-26. Primary servers and clients complying with a subset of NTP, called the Simple Network Time Protocol (SNTPv4) […], do not need to implement the mitigation algorithms […] The fully developed NTPv4 implementation is intended for […] servers with multiple upstream servers and multiple downstream servers […] Other than these considerations, NTP and SNTP servers and clients are completely interoperable and can be intermixed […]

^ Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. doi:10.17487/RFC4330. RFC 4330.

^ «Combining PTP with NTP to Get the Best of Both Worlds». www.redhat.com. Programs from the linuxptp package can be used in a combination with an NTP daemon. A PTP clock on a NIC is synchronized by ptp4l and is used as a reference clock by chronyd or ntpd for synchronization of the system clock.

^ RFC 5905, p. 21

^ «Network Time Protocol: Best Practices White Paper». Archived from the original on 1 October 2013. Retrieved 15 October 2013.

^ ^a ^b «‘ntpq -p’ output». NLUG.ML1.co.uk. Archived from the original on 2018-11-12. Retrieved 2018-11-12.

^ «Event Messages and Status Words». docs.ntpsec.org. Refid codes are used in kiss-o’-death (KoD) packets, the reference identifier field in ntpq and ntpmon billboard displays and log messages.

^ «Network Time Protocol (NTP) Parameters». www.iana.org.

^ David L. Mills (12 May 2012). «The NTP Era and Era Numbering». Archived from the original on 26 October 2016. Retrieved 24 September 2016.

^ W. Richard Stevens; Bill Fenner; Andrew M. Rudoff (2004). UNIX Network Programming. Addison-Wesley Professional. pp. 582–. ISBN 978-0-13-141155-5. Archived from the original on 2019-03-30. Retrieved 2016-10-16.

^ «How NTP Represents the Time (Computer Network Time Synchronization)». Archived from the original on 2017-06-15. Retrieved 2018-07-20.

^ «A look at the Year 2036/2038 problems and time proofness in various systems». 14 March 2017. Archived from the original on 2018-07-21. Retrieved 2018-07-20.

^ University of Delaware Digital Systems Seminar presentation by David Mills, 2006-04-26

^ Gotoh, T.; Imamura, K.; Kaneko, A. (2002). «Improvement of NTP time offset under the asymmetric network with double packets method». Conference Digest Conference on Precision Electromagnetic Measurements. Conference on Precision Electromagnetic Measurements. pp. 448–449. doi:10.1109/CPEM.2002.1034915. ISBN 0-7803-7242-5.

^ ^a ^b Lichvar, Miroslav (18 September 2018). «chrony – chrony.conf(5)». Chrony project. Chrony project. Retrieved 2 August 2020. This directive enables hardware timestamping of NTP packets sent to and received from the specified network interface.

^ «sourcestats.c, function estimate_asymmetry()». git.tuxfamily.org (chrony).

^ «Pentest-Report NTP 01.2017» (PDF). Cure53. 2017. Archived (PDF) from the original on 2018-12-01. Retrieved 2019-07-03.

^ «Windows Time Service Technical Reference». technet.microsoft.com. 2011-08-17. Archived from the original on 2011-09-06. Retrieved 2011-09-19.

^ «Windows Time Service page at NTP.org». Support.NTP.org. 2008-02-25. Archived from the original on 2017-05-14. Retrieved 2017-05-01.

^ «How the Windows Time Service Works». technet.microsoft.com. 2010-03-12. Archived from the original on 2011-09-24. Retrieved 2011-09-19.

^ ^a ^b «Support boundary to configure the Windows Time service for high accuracy environments». Microsoft. 2011-10-19. Archived from the original on 2009-01-12. Retrieved 2008-12-10.

^ Ned Pyle (2007-10-23). «High Accuracy W32time Requirements». Microsoft. Archived from the original on 2012-10-17. Retrieved 2012-08-26.

^ «Windows Server 2016 Accurate Time». technet.microsoft.com. Archived from the original on 2016-12-02. Retrieved 2016-12-07.

^ dahavey. «Support boundary for high-accuracy time». docs.microsoft.com. Retrieved 2021-07-24.{{cite web}}: CS1 maint: url-status (link)

^ «ntpd(8) — OpenBSD manual pages». man.openbsd.org. It implements the Simple Network Time Protocol version 4, as described in RFC 5905, and the Network Time Protocol version 3, as described in RFC 1305.

^ The OpenBSD Project (21 August 2006). «FAQ 6.12.1: ‘But OpenNTPD isn’t as accurate as the ntp.org daemon!’«. The OpenBSD Project. Archived from the original on 2016-02-05. Retrieved 2020-05-14.

^ «The Secure Network Time Protocol (NTPsec) Distribution». Archived from the original on 2019-01-13. Retrieved 2019-01-12.

^ Liska, Allan (December 10, 2016). NTP Security: A Quick-Start Guide. Apress. pp. 80–. ISBN 978-1-4842-2412-0.

^ «Pentest-Report NTPsec 01.2017» (PDF). Cure53. 2017. Archived (PDF) from the original on 2019-07-04. Retrieved 2019-07-03.

^ Lichvar, Miroslav (20 July 2016). «Combining PTP with NTP to Get the Best of Both Worlds». Red Hat Enterprise Linux Blog. Red Hat. Archived from the original on 30 July 2016. Retrieved 19 November 2017. Starting with Red Hat Enterprise Linux 7.0 (and now in Red Hat Enterprise Linux 6.8) a more versatile NTP implementation is also provided via the chrony package

^ «Securing Network Time». Core Infrastructure Initiative, a Linux Foundation Collaborative Project. Core Infrastructure Initiative. 27 September 2017. Archived from the original on 28 October 2017. Retrieved 19 November 2017. In sum, the Chrony NTP software stands solid and can be seen as trustworthy

^ ^a ^b «chrony introduction». TuxFamily, a non-profit organization. chrony. Archived from the original on 9 December 2009. Retrieved 19 November 2017. The software is supported on Linux, FreeBSD, NetBSD, macOS, and Solaris.

^ Both, David. «Manage NTP with Chrony». Opensource.com. Archived from the original on 29 June 2019. Retrieved 29 June 2019.

^ Heiderich, Mario (August 2017). «Pentest-Report Chrony 08.2017» (PDF). Cure53.de Team. wiki.mozilla.org, AKA MozillaWiki or WikiMO. Archived from the original (PDF) on 5 October 2017. Retrieved 19 November 2017. Withstanding eleven full days of on-remote testing in August of 2017 means that Chrony is robust, strong, and developed with security in mind.

^ «chrony/chrony.git — Official Git repository for the Chrony project». git.tuxfamily.org. Retrieved 2021-07-31.

^ Poul-Henning, Kamp. «20140926 – Playing with time again». PHK’s Bikeshed. Archived from the original on 20 December 2019. Retrieved 4 June 2015.

^ Poul-Henning, Kamp. «Network time synchronization software, NTPD replacement». ntimed git repository README file. Github. Archived from the original on 2 August 2015. Retrieved 4 June 2015.

^ «Switching from OpenNTPd to Chrony — anarcat». anarc.at. So in effect, systemd-timesyncd became the default NTP daemon in Debian in bookworm, which I find somewhat surprising.

^ David Mills. «The NTP Timescale and Leap Seconds». Archived from the original on 7 September 2013. Retrieved 15 October 2013.

^ «Google Developers Leap Smear». Archived from the original on 4 April 2019. Retrieved 4 April 2019.

^ Obleukhov, Oleg (18 March 2020). «Building a more accurate time service at Facebook scale». Engineering at Meta.

^ «chrony – Frequently Asked Questions». chrony.tuxfamily.org.

^ «Security Notice». Support.NTP.org. 2009-12-10. Retrieved 2011-01-12.

^ «Cisco IOS Software Network Time Protocol Packet Vulnerability». Cisco Systems. 23 September 2009. Archived from the original on 11 June 2020. Retrieved 11 June 2020.

^ «Code Audit». Support.NTP.org. 2009-06-13. Retrieved 2011-01-12.

^ «Network Time Protocol Vulnerabilities (Update C) | ICS-CERT». Ics-cert.us-cert.gov. Archived from the original on 2014-12-20. Retrieved 2015-04-15.

^ Cunningham, Andrew (Dec 23, 2014). «Apple automatically patches Macs to fix severe NTP security flaw». arstechnica. Archived from the original on April 15, 2015. Retrieved Apr 29, 2015.

^ Fairhead, Harry (23 December 2014). «NTP The Latest Open Source Security Problem». I Programmer. Archived from the original on 24 December 2014. Retrieved 24 December 2014.

^ NTP SecurityNotice Page Archived 2014-02-19 at the Wayback Machine

^ NVD NIST Product Search NTP

^ NVD NIST Product Search NTPsec Archived 2020-06-26 at the Wayback Machine

^ NVD NIST Product Search Chrony Archived 2020-06-26 at the Wayback Machine

^ «CII Audit Identifies Most Secure NTP Implementation». The Linux Foundation. September 28, 2017. Archived from the original on 2018-02-03. Retrieved 2019-07-03.

^ ^a ^b Network Time Protocol Version 4: Autokey Specification. IETF. June 2010. doi:10.17487/RFC5906. RFC 5906.

^ ^a ^b «NTP Security Analysis». Archived from the original on 7 September 2013. Retrieved 11 October 2013.

^ Jose Selvi (2014-10-16). «Bypassing HTTP Strict Transport Security» (PDF). Archived from the original (PDF) on 2014-10-18. Retrieved 2014-10-16.

^ Aanchal Malhotra; Isaac E. Cohen; Erik Brakke & Sharon Goldberg (20 October 2015). «Attacking the Network Time Protocol» (PDF). NDSS. Archived from the original (PDF) on 22 October 2015. Retrieved 27 October 2015.

^ «Attacking the Network Time Protocol». www.cs.bu.edu. Archived from the original on 2015-10-24. Retrieved 2015-10-27.

^ Goodin, Dan (2014-01-13). «New DoS attacks taking down game sites deliver crippling 100Gbps floods». Ars Technica. Archived from the original on 2014-01-24. Retrieved 2014-01-25.

^ Lee, Dave (2014-02-11). «Huge Hack ‘Ugly Sign of Future’ for Internet Threats». BBC. Archived from the original on 2014-02-11. Retrieved 2014-02-12.

^ «DRDoS / Amplification Attack using ntpdc monlist command». support.NTP.org. 2010-04-24. Archived from the original on 2014-03-30. Retrieved 2014-04-13.

^ https://www.ietf.org/proceedings/83/slides/slides-83-tictoc-1.pdf

^ «nts.time.nl homepage». nts.time.nl. Retrieved 2021-08-19.

^ D. Franke; D. Sibold; K. Teichel; M. Dansarie; R. Sundblad (September 2020). Network Time Security for the Network Time Protocol. Internet Engineering Task Force. doi:10.17487/RFC8915. ISSN 2070-1721. RFC 8915. Proposed Standard.

^ Langer, Martin (2019-12-05). «Setting up NTS-Secured NTP with NTPsec». Weberblog.net. Retrieved 2021-08-19.

^ «How to use NTS | Netnod». Netnod. Retrieved 2021-08-19.{{cite web}}: CS1 maint: url-status (link)

^ «Network Time Security · Cloudflare Time Services docs». developers.cloudflare.com.

^ https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sntp/8106cb73-ab3a-4542-8bc8-784dd32031cc

^ «Comparison of NTP implementations». chrony.tuxfamily.org. Retrieved 2019-10-08.

Further reading[edit]

Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4). doi:10.17487/RFC5907. RFC 5907.

Network Time Protocol (NTP) Server Option for DHCPv6. doi:10.17487/RFC5908. RFC 5908.

External links[edit]

Official website

Official Stratum One Time Servers list

IETF NTP working group

Microsft Windows accurate time guide and more

Time and NTP paper

NTP Survey 2005

Current NIST leap seconds file compatible with ntpd

David L. Mills, A Brief History of NTP Time: Confessions of an Internet Timekeeper (PDF), retrieved 2021-02-07

Источник

Общие переменные

Следующие переменные являются общими для двух или более систем, партнеров и классов пакетов. Когда необходимо отличить общие переменные с идентичными именами, вводится идентификатор переменной.

Адрес партнера ( peer.peeraddr, pkt.peeraddr ), порт партнера ( peer.peerport, pkt.peerport ). 32-битный IP—адрес и 16-битный номер порта партнера.

Адрес ЭВМ ( peer.hostaddr, pkt.hostaddr ), порт ЭВМ ( peer.hostport, pkt.hostport ). 32-битный IP—адрес и 16-битный номер порта ЭВМ. Эти переменные включаются в переменные состояния для поддержки мультиинтерфейсных систем.

Индикатор приращения ( sys.leap, peer.leap, pkt.leap ) — это двухбитный код предупреждения о включении дополнительных секунд во временную шкау NTP. Эти биты устанавливаются до 23:59 дня добавления и сбрасываются после 00:00 следующего дня. В результате день, для которого проведена эта процедура, окажется длиннее или короче на одну секунду. Для вторичных серверов эти биты устанавливаются протоколом NTP. Биты 0 и 1 ( LI ) принимают значения, перечисленные в таблице 7.1.

Таблица
7.1.
Значения кодов индикатора LI

LI Величина Значение

00 0 предупреждения нет

01 1 последняя минута содержит 61 секунду

10 2 последняя минута содержит 59 секунд

11 3 аварийный сигнал (часы не синхронизованы)

Во всех случаях, за исключением аварийного сигнала (alarm = 112), протокол NTP никак не изменяет эти биты, а только передает их программам преобразования времени, которые не являются частью протокола. Аварийная ситуация возникает, когда по какой-либо причине локальные часы оказываются не синхронизованными. Это может случиться в ходе инициализации системы или в случае, когда первичные часы оказываются недоступны в течение длительного времени.

Режим ( peer.mode, pkt.mode ) — это целое 3-битовое число, обозначающее код режима ассоциации, который может принимать значения, приведенные в таблице 7.2.

Таблица
7.2.
Значения кодов Режим

Режим Значение

0 Зарезервировано

1 симметричный активный

2 симметричный пассивный

3 Клиент

4 Сервер

5 широковещательный

6 для управляющих сообщений NTP

7 зарезервировано для частного использования

Слой ( sys.stratum, peer.stratum, pkt.stratum ) — это целое число, указывающее код слоя локальных часов, который может принимать значения, приведенные в таблице 7.3.

Таблица
7.3.
Значения кодов слой

Слой Значение

0 Не специфицирован или недоступен

1 Первичный эталон (например, радио-часы)

2-15 Вторичный эталон (через NTP или sntp)

16-255 Зарезервировано на будущее

Для целей сравнения значение нуль для кода слоя считается выше, чем любая другая величина. Заметим, что максимальное значение целого, закодированное как пакетная переменная, ограничено параметром ntp.maxstratum.

Период обмена ( sys.poll, peer.hostpoll, peer.peerpoll, pkt.poll ). Это целая переменная со знаком, которая указывает минимальный интервал между передаваемыми сообщениями, измеренный в секундах и представленный как степень 2. Например, значение 6 указывает на минимальный интервал в 64 секунды.

Точность ( sys.precision, peer.precision, pkt.precision ). Это целая переменная со знаком, обозначающая точность часов в секундах и выраженная как ближайшая степень числа 2. Значение должно быть округлено в большую сторону до ближайшего значения степени 2, например, сетевой частоте 50-Гц (20 мс) или 60-Гц (16.67 мс) будет поставлена в соответствие величина -5 (31.25 мс), в то время как кварцевой частоте 1000-Гц (1 мс) будет поставлено в соответствие значение -9 (1.95 мс).

Базовая задержка ( sys.rootdelay, peer.rootdelay, pkt.rootdelay ). Это число с фиксированной запятой со знаком, которое указывает на величину полной циклической задержки (RTT) до первичного эталона частоты, выраженной в секундах.

Базовая дисперсия ( sys.rootdispersion, peer.rootdispersion, pkt.rootdispersion ). Это число с фиксированной запятой больше нуля, указывающее на максимальное значение временной ошибки по отношению к первичному эталону в секундах.

Идентификатор эталонных часов ( sys.refid, peer.refid, pkt.refid ). Это 32-битовый код, идентифицирующий конкретные эталонные часы. В случае слоя 0 (не специфицирован) или слоя 1 (первичный эталонный источник), это 4-октетная ASCII-строка, выровненная по левому краю и дополненная при необходимости нулями, например:

Таблица
7.4.
Коды идентификаторов часов

Слой Код Значение

0 dcn Протокол маршрутизации dcn

0 dts Цифровая служба времени (digital time service)

0 nist Общий модем nist

0 tsp Временной протокол tsp

1 atom Атомные часы (калиброванные)

1 vlf vlf-радио (omega, и пр.)

1 callsign Общее радио

1 gps gps УВЧ позиционирование спутников

1 lorc loran-c радионавигация

1 wwvb Радио wwvb НЧ (диапазон 5)

1 goes Спутник goes УВЧ (диапазон 9)

1 wwv Радио wwv ВЧ (диапазон 7)

В случае слоя 2 и выше (вторичный эталон) — это 4-октетный IP—адрес партнера, выбранного для синхронизации.

Эталонная временная метка ( sys.reftime, peer.reftime, pkt.reftime ) — локальное время в формате временных меток, соответствующее моменту последней коррекции показаний часов. Если локальные часы не были синхронизованы, переменная содержит нуль.

Базовая временная метка ( peer.org, pkt.org ) — локальное время в формате временных меток, соответствующее моменту посылки последнего NTP -сообщения. Если партнер недостижим, переменная принимает нулевое значение.

Временная метка получения ( peer.rec, pkt.rec ) — локальное время в формате временных меток, которое соответствуюет моменту прихода последнего NTP -сообщения, полученного от партнера. Если партнер недостижим, переменная принимает нулевое значение.

Временная метка передачи ( peer.xmt, pkt.xmt ) — локальное время в формате временных меток, соответствующее моменту отправки NTP -сообщения.

Системные переменные

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

Переменная локальные часы ( sys.clock ) содержит показание локальных часов в формате временных меток. Локальное время получается от аппаратных часов конкретной ЭВМ и дискретно увеличивается с конструктивно заданными приращениями.

Переменная Базовые часы ( sys.peer ) представляет собой селектор, идентифицирующий используемый источник синхронизации. Обычно это указатель на структуру, содержащую переменные партнера. Значение нуль указывает, что в настоящее время источник синхронизации отсутствует.

Переменные партнера

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

Бит конфигурации ( peer.config ) — бит, индицирующий, что ассоциация была сформирована на основе конфигурационной информации и не должна быть расформирована, когда партнер становится недоступен.

Временная метка актуализации ( peer.update ) — локальное время в формате временной метки, отмечающее момент, когда было получено последнее NTP сообщение. Переменная используется для вычисления дисперсии временного сдвига.

Регистр достижимости ( peer.reach ) — сдвиговый регистр битов ntp.window, используемых для определения статуса достижимости партнера. Ввод данных производится со стороны младших бит (справа). Партнер считается достижимым, если как минимум один бит этого регистра равен 1.

Таймер партнера ( peer.timer ) — целочисленный счетчик, используемый для управления интервалом между последовательно посылаемыми NTP -сообщениями. После установки значения счетчика его содержимое уменьшается на 1 (1сек), пока не достигнет нуля. При этом вызывается процедура передачи. Заметим, что работа этого таймера не должна зависеть от локальных часов.

Пакетные переменные

Номер версии ( pkt.version ) — целое число, индицирующее номер версии отправителя. NTP -сообщения всегда посылаются с текущим значением версии ntp.version и будут восприняты лишь при условии совпадения кодов версии ( ntp.version ). Исключения допускаются лишь при смене номера версии.

Переменные фильтра часов

Когда используются фильтры и алгоритмы отбора, дополнительно привлекаются следующие переменные состояния.

Регистр фильтра ( peer.filter ) — сдвиговый регистр каскадов ntp.shift, где каждый каскад запоминает значения измеренной задержки, смещения и вычисленной дисперсии, соответствующих одному наблюдению. Эти три параметра вводятся со стороны старших разрядов и сдвигаются в направлении младших разрядов (направо). При получении результатов нового наблюдения старые результаты теряются.

Счетчик корректных данных ( peer.valid ) — целочисленный счетчик, указывающий на корректные образцы, остающиеся в регистре фильтра. Он используется для определения состояния доступности и для управления увеличением и уменьшением периода рассылки сообщений.

Смещение ( peer.offset ) — число с фиксированной запятой со знаком, индицирующее значение смещение часов партнера по отношению к локальным часам в секундах.

Задержка ( peer.delay ) — число с фиксированной запятой со знаком, индицирующее полную циклическую задержку (RTT) часов партнера по отношению к локальным часам с учетом времени распространения сообщения и отклика в сети в секундах. Заметим, что переменная может принимать как положительное, так и отрицательное значение в зависимости от точности часов и накопившейся ошибки смещения.

Дисперсия ( peer.dispersion ) — число с фиксированной запятой, индицирующее максимальную ошибку часов партнера по отношению к локальным часам с учетом сетевой задержки в секундах. Допускаются только значения больше нуля.

Параметры

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

Номер версии ( ntp.version ) — текущий номер версии NTP (3).

Порт NTP ( ntp.port ) — стандартный номер порта (123), присвоенный протоколу NTP.

Максимальный номер слоя ( ntp.maxstratum ) — максимальный номер слоя, который может быть использован при кодировании пакетной переменной. Этот параметр обычно интерпретируется как определение бесконечности (недостижимости для протокола маршрутизации в субсети).

Максимальный возраст часов ( ntp.maxage ) — максимальный интервал в секундах, в течение которого эталонные часы будут рассматриваться как корректные после последней сверки.

Максимальный сбой ( ntp.maxskew ) — максимальная ошибка смещения, связанная со сбоем локальных часов за время ntp.maxage, в секундах. Отношение ntp.maxskew к ntp.maxage интерпретируется как максимальный сбой, вызванный всей совокупностью факторов.

Максимальное расстояние ( ntp.maxdistance ) — максимально допустимое расстояние между партнерами при синхронизации с использованием алгоритма отбора.

Минимальный период рассылки ( ntp.minpoll ) — минимальный период рассылки, допустимый для любого из партнеров в сети Интернет. Этот период выражается в секундах и представляет собой степень 2.

Максимальный период рассылки ( ntp.maxpoll ) — максимальный период рассылки, допустимый для любого из партнеров в сети Интернет. Этот период выражается в секундах и представляет собой степень 2.

Минимум избранных часов ( ntp.minclock ) — минимальное число партнеров, необходимое для синхронизации (при использовании алгоритма отбора).

Максимум избранных часов> ( ntp.maxclock ) — максимальное число партнеров, необходимое для организации отбора (при использовании алгоритма селекции).

Минимальная дисперсия ( ntp.mindisperse ) — минимальное значение приращения дисперсии для каждого из слоев в секундах (при использовании алгоритма фильтрации).

Максимальная дисперсия ( ntp.maxdisperse ) — максимальная дисперсия в секундах с учетом потерянных данных (при использовании алгоритма фильтрации).

Размер регистра доступности ( ntp.window ) — размер регистра доступности ( peer.reach ) в битах.

Размер фильтра ( ntp.shift ) — размер сдвигового регистра фильтра часов ( peer.filter ) в каскадах.

Вес фильтра ( ntp.filter ) — вес, используемый при вычислении дисперсии фильтра (применяется при работе с алгоритмом фильтрации).

Выбранный вес ( ntp.select ) — вес, используемый при вычислении выбранной дисперсии (применяется при работе алгоритма селекции).

Режимы работы

За исключением широковещательного режима, NTP —ассоциация формируется, когда два партнера обмениваются сообщениями и один или оба из них создает и поддерживает протокольную машину, называемую ассоциацией. Ассоциация может работать в одном из 5 режимов, заданных переменной peer.mode: симметрично активный, симметрично пассивный, клиент, сервер и широковещательный:

Симметрично активный (1). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от достижимости или слоя своего партнера. При работе в этом режиме ЭВМ оповещает о своем намерении синхронизовать и быть синхронизованной партнером.

Симметрично пассивный (2). Этот тип ассоциации первоначально создается по прибытии сообщения от партнера, работающего в симметрично активном режиме. Он сохраняется, пока партнер достижим и функционирует в слое, ниже или равном данной ЭВМ. В противном случае ассоциация распадается. Однако ассоциация будет существовать до тех пор, пока, по крайней мере, одно сообщение не будет послано в качестве отклика. При работе в этом режиме ЭВМ оповещает о своем намерении синхронизовать и быть синхронизованной партнером.

Клиент (3). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от достижимости или слоя своего партнера. При работе в этом режиме ЭВМ (обычно это сетевая рабочая станция) оповещает о своем намерении быть синхронизованной партнером.

Сервер (4). Этот тип ассоциации первоначально создается по прибытии запроса клиента и существует только для отклика на этот запрос. После отклика ассоциация ликвидируется. При работе в этом режиме ЭВМ (обычно рабочая сетевая станция) оповещает о намерении синхронизовать партнера.

Широковещательный (5). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от доступности или слоя партнеров. При работе в этом режиме ЭВМ (обычно сетевой сервер времени, который работает в широковещательной среде) оповещает о намерении синхронизовать всех партнеров.

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

В симметричных режимах отличие клиента от сервера практически исчезает. Симметрично пассивный режим предназначен для использования временными серверами, работающими вблизи базовых узлов (нижний слой ) субсети синхронизации и со сравнительно большим числом партнеров. В этом режиме идентификации партнера не требуется заранее, так как ассоциация с ее переменными состояния создана, только когда получено NTP -сообщение. Более того, запомненное состояние может быть использовано позднее, когда партнер станет недостижим или будет работать на более высоком уровне и по этой причине будет непригоден в качестве источника синхронизации.

Симметрично активный режим предназначен для использования серверами времени, работающими вблизи оконечных узлов (наивысший слой ) синхронизации. Надежный временной сервис обычно может быть реализован с помощью двух партнеров на ближайшем нижележащем слое и одном партнере в том же слое. По этой причине поток сообщений обычно невелик, даже когда связь потеряна, и на каждый запрос приходит отклик об ошибке.

В нормальной ситуации один партнер работает в активном режиме (симметричный активный, клиент или широковещательный), как это сконфигурировано в стартовом файле, в то время как другие работают в пассивном режиме (симметричный пассивный или сервер), часто без предварительной конфигурации. Однако оба партнера могут быть сконфигурированы для работы в симметричном режиме. Условие ошибки возникает, когда оба партнера работают в одном и том же режиме, но не в симметричном активном. В таких случаях каждый партнер будет игнорировать сообщения, поступающие от другого, и ассоциация, если она существовала, будет ликвидирована из-за недостижимости партнера.

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

Обработка событий

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

Источник


International standard	RFC 5905
Developed by	David L. Mills, Network Time Foundation
Introduced	1985

Refid^[33]	Clock Source
GOES	Geosynchronous Orbit Environment Satellite
GPS	Global Positioning System
GAL	Galileo Positioning System
PPS	Generic pulse-per-second
IRIG	Inter-Range Instrumentation Group
WWVB	LF Radio WWVB Fort Collins, Colorado 60 kHz
DCF	LF Radio DCF77 Mainflingen, DE 77.5 kHz
HBG	LF Radio HBG Prangins, HB 75 kHz (ceased operation)
MSF	LF Radio MSF Anthorn, UK 60 kHz
JJY	LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz
LORC	MF Radio Loran-C station, 100 kHz
TDF	MF Radio Allouis, FR 162 kHz
CHU	HF Radio CHU Ottawa, Ontario
WWV	HF Radio WWV Fort Collins, Colorado
WWVH	HF Radio WWVH Kauai, Hawaii
NIST	NIST telephone modem
ACTS	NIST telephone modem
USNO	USNO telephone modem
PTB	German PTB time standard telephone modem
MRS	(Informal) Multi Reference Sources
GOOG	(Unofficial) Google Refid used by google NTP servers as time4.google.com

LI	Величина	Значение
00	0	предупреждения нет
01	1	последняя минута содержит 61 секунду
10	2	последняя минута содержит 59 секунд
11	3	аварийный сигнал (часы не синхронизованы)

Режим	Значение
0	Зарезервировано
1	симметричный активный
2	симметричный пассивный
3	Клиент
4	Сервер
5	широковещательный
6	для управляющих сообщений NTP
7	зарезервировано для частного использования

Слой	Значение
0	Не специфицирован или недоступен
1	Первичный эталон (например, радио-часы)
2-15	Вторичный эталон (через NTP или sntp)
16-255	Зарезервировано на будущее

Слой	Код	Значение
0	dcn	Протокол маршрутизации dcn
0	dts	Цифровая служба времени (digital time service)
0	nist	Общий модем nist
0	tsp	Временной протокол tsp
1	atom	Атомные часы (калиброванные)
1	vlf	vlf-радио (omega, и пр.)
1	callsign	Общее радио
1	gps	gps УВЧ позиционирование спутников
1	lorc	loran-c радионавигация
1	wwvb	Радио wwvb НЧ (диапазон 5)
1	goes	Спутник goes УВЧ (диапазон 9)
1	wwv	Радио wwv ВЧ (диапазон 7)