Ntp port: pool.ntp.org: Использование пула NTP

pool.ntp.org: Использование пула NTP

Как пользоваться пулом NTP?

Если вы используете программу ntpd из комплекта, рапространяемого ntp.org (работает на большинстве современных операционных систем, включая Linux, *BSD, Windows и некоторые другие), для обычной синхронизации ваших часов по Интернету будет достаточно такой конфигурации:

driftfile /var/lib/ntp/ntp.drift

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org

Имена 0, 1, 2 и 3.pool.ntp.org указывают на случайно выбранные из пула сервера (выбираются заново каждый час). Перед запуском ntpd убедитесь, что погрешность ваших часов находится в разумных пределах (не превышает нескольких минут). Для этого можно провести моментальную синхронизацию с пулом при помощи команды ntpdate pool.ntp.org, или просто установить время вручную при помощи команды date. После этого вы можете запустить ntpd. Через некоторое время (до получаса) команда ntpq -pn должна выдать нечто похоже на следующее:

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+81. 6.42.224     193.5.216.14     2 u   68 1024  377  158.995   51.220  50.287
*217.162.232.173 130.149.17.8     2 u  191 1024  176   79.245    3.589  27.454
-129.132.57.95   131.188.3.222    3 u  766 1024  377   22.302   -2.928   0.508

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

Из-за того, что имя pool.ntp.org будет выдавать вам сервера со всего мира, качество синхронизации может быть не очень высоким. Рекомендуем использовать для синхронизации континентальные зоны (например, europe, north-america, oceania or asia.pool.ntp.org). Еще более оптимальным решением будет использование зоны, соответствующей вашей стране (например, ru.pool.ntp.org для России, ua.pool.ntp.org для Украины и т.д.). Также вы можете использовать цифровой префикс (0, 1 или 2) перед именем зоны.

Если вы используете последние версии Windows, вы также можете использовать встроенный в систему NTP-клиент. Это делается командой

net time /setsntp:pool.ntp.org

В некоторых версиях Windows можно указывать более одного сервера:

net time /setsntp:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org"

Это должно работать на Windows 2000/XP/2003. Также вы можете, войдя в систему с правами администратора, щелкнуть правой кнопкой мыши по часам на панели задач, выбрать «Настройка даты/времени», перейти на закладку «Время Интернета» и ввести в предложенное тесктовое поле имя сервера для синхронизации.

Немецкая фирма Meinberg портировала ntpd под Windows.

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

Additional Notes

Дополнительные замечания

Если ваш интернет-провайдер имеет собственные NTP-сервера, или вы знаете хорошие NTP-сервера недалеко от вас, используете именно их, а не нас — вы получите более высокое качество синхронизации при меньшей нагрузке на сеть. Если вы знаете только один сервер поблизости от вас, вы можете использовать его, например, с двумя серверами из pool.

Изредка случается так, что вам дважды выдается один и тот же сервер — эту проблему можно решить простым перезапуском ntpd. Если вы используете зону своей страны, учтите, что в ней может оказаться всего один-два сервера. В этом случае рекомендуем использовать континентальную зону. Посмотреть, сколько серверов работает в каждой зоне, вы можете здесь.

Будьте дружелюбны. Многие сервера предоставляются добровольцами, и почти все NTP-сервера на самом деле являются файловыми, почтовыми или web-серверами, на которых просто запущен ntpd. Поэтому не используйте более трех серверов в своей конфигурации, и не выкидывайте грязных трюков с параметрами burst и minpoll — все, чего вы добьетесь, это гибель нашего проекта, раньше или позже.

Убедитесь, что на вашем компьютере корректно настроен часовой пояс. ntpd ничего не знает о часовых поясах. Он работает только со временем Гринвича (UTC).

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

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

Принцип работы службы времени Windows

• 05/08/2018
• Чтение занимает 9 мин

В этой статье

Применяется к: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows 10 или более поздних версий

Содержание раздела

Примечание

В этом разделе объясняется работа службы времени Windows (W32Time). Сведения о настройке службы времени Windows см. в статье Configuring Systems for High Accuracy (Настройка систем для обеспечения высокой точности).

Примечание

В Windows Server 2003 и Microsoft Windows 2000 Server служба каталогов называется «служба каталогов Active Directory» В Windows Server 2008 и более поздних версиях служба каталогов называлась «Доменные службы Active Directory» (AD DS). Остальная часть этой статьи относится к AD DS, но эти сведения применимы также и к Active Directory.

Хотя служба времени Windows не является точной реализацией протокола сетевого времени (NTP), она использует комплексный набор алгоритмов, определенных в спецификациях NTP, чтобы гарантировать максимальную точность часов на компьютерах в сети. В идеале все часы на компьютерах в домене AD DS синхронизируются со временем полномочного компьютера. На синхронизацию времени в сети могут повлиять многие факторы. На точность синхронизации в AD DS часто влияют следующие факторы:

• условия сети;

• точность аппаратных часов компьютера;

• объем ресурсов ЦП и сети, доступных службе времени Windows.

Важно!

До Windows Server 2016 служба W32Time не предназначалась для поддержки зависящих от времени потребностей приложений. Не теперь обновления Windows Server 2016 позволяют реализовать в домене решение с точностью 1 мс. Дополнительные сведения см. в статьях Windows 2016 Accurate Time (Точное время для Windows Server 2016) и Support boundary for high-accuracy time (Граница области поддержки для сверхточного времени).

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

Лес AD DS имеет предварительно определенную иерархию синхронизации времени. Служба Windows Time синхронизирует время между компьютерами в иерархии, в верхней части которой находятся наиболее точные эталонные часы. Если на компьютере настроено более одного источника времени, Служба времени Windows использует алгоритмы NTP для выбора наилучшего из настроенных источников времени, на основе способности компьютера синхронизироваться с этим источником времени. Служба времени Windows не поддерживает сетевую синхронизацию из широковещательных или многоадресных узлов. Дополнительные сведения об этих функциях NTP см. в документе RFC 1305 в базе данных RFC IETF.

Каждый компьютер, на котором работает Служба времени Windows, использует службу для поддержания наиболее точного времени. Компьютеры, являющиеся членами домена, выступают в качестве клиента времени по умолчанию, поэтому в большинстве случаев настраивать Службу времени Windows не нужно. Однако Службу времени Windows можно настроить на выполнения запроса о времени из назначенного источника времени, кроме того служба также может предоставить время клиентам.

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

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

Архитектура службы времени Windows

Служба времени Windows состоит из следующих компонентов:

• Диспетчер служб

• Диспетчер Службы времени Windows

• Правила работы с часами

• Поставщики времени

На следующем рисунке показана архитектура Службы времени Windows.

Архитектура Службы времени Windows

Диспетчер служб отвечает за запуск и остановку Службы времени Windows. Диспетчер служб Службы времени Windows отвечает за запуск действий поставщиков времени NTP, включенных в операционную систему. Диспетчер служб Службы времени Windows управляет всеми функциями Службы времени Windows и объединением всех образцов времени. Помимо предоставления информации о текущем состоянии системы, например, об текущем источнике времени или о последнем обновлении системных часов, диспетчер служб Службы времени Windows также отвечает за создание событий в журнале событий.

Процесс синхронизации времени состоит из следующих этапов.

• Поставщики входных данных запрашивают и получают образцы времени из настроенных источников времени NTP.

• Эти примеры затем передаются в диспетчер служб Службы времени Windows, который собирает все образцы и передает их подкомпоненту «правила работы с часами».

• Подкомпонент «правила работы с часами» применяет алгоритмы NTP, которые приводят к выбору лучшего образца времени.

• Подкомпонент «правила работы с часами» корректирует время системных часов до наиболее точного времени, изменяя тактовою частоту или непосредственно время.

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

Протоколы времени для службы времени Windows

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

Служба времени Windows использует протокол NTP для синхронизации времени по сети. NTP — это протокол времени в Интернете, включающий алгоритмы правил работы, необходимые для синхронизации часов. NTP является более точным протоколом времени, чем Simple Network Time Protocol (SNTP), который используется в некоторых версиях Windows; однако W32Time продолжает поддерживать SNTP для обеспечения обратной совместимости с компьютерами, на которых работают службы времени на основе SNTP, такие как Windows 2000.

Протокол сетевого времени

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

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

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

Алгоритм NTP

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

Алгоритмы NTP наиболее точны при низкой и умеренной нагрузке сети и сервера. Как и любой другой алгоритм, учитывающий время прохождения сети, алгоритмы NTP могут плохо работать в условиях сильной перегрузки сети. Дополнительные сведения об алгоритмах NTP см. в документе RFC 1305 в базе данных RFC IETF.

Поставщик времени NTP

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

Поставщик NTP является стандартным поставщиком времени, включенным в операционную систему. Поставщик NTP соответствует стандартам, указанным в NTP версии 3 для клиента и сервера, и может взаимодействовать с клиентами и серверами SNTP для обеспечения обратной совместимости с Windows 2000 и другими клиентами SNTP. Поставщик NTP в Службе времени Windows состоит из следующих двух частей.

• Поставщик выходных данных NtpServer. Это сервер времени, который отвечает на запросы времени клиента в сети.

• Поставщик выходных данных NtpClient. Это клиент времени, который получает сведения о времени из другого источника, либо от аппаратного устройства, либо от сервера NTP, и может возвращать образцы времени, полезные для синхронизации локальных часов.

Хотя фактические операции этих двух поставщиков тесно связаны, они отображаются независимо от службы времени. Начиная с Windows 2000 Server, где есть подключение компьютера Windows к сети, он настраивается как NTP-клиент. Кроме того, компьютеры, на которых запущена Служба времени Windows, по умолчанию пытаются синхронизировать время только с контроллером домена или вручную указанным источником времени. Это предпочтительные поставщики времени, потому что они доступны автоматически и защищают источники времени.

Безопасность NTP

В лесу AD DS Служба времени Windows использует стандартные функции безопасности домена для обеспечения проверки подлинности данных времени. Безопасность пакетов NTP, отправляемых между компьютером–членом домена и контроллером локального домена, который действует в качестве сервера времени, основана на аутентификации по общему ключу. Служба времени Windows использует ключ сеанса Kerberos компьютера для создания подписей с проверкой подлинности в пакетах NTP, отправляемых по сети. Пакеты NTP не передаются в безопасном канале сетевого входа в систему. Вместо этого, когда компьютер запрашивает время у контроллера домена в иерархии домена, Служба времени Windows требует аутентификации времени. Затем контроллер домена возвращает необходимые сведения в формате 64-разрядного значения, которое прошло проверку подлинности с помощью ключа сеанса из службы сетевого входа в систему. Если возвращенный пакет NTP не подписан с помощью ключа сеанса компьютера или подписан неправильно — время отклоняется. Все такие ошибки проверки подлинности регистрируются в журнале событий. Таким образом Служба времени Windows обеспечивает безопасность данных NTP в лесу AD DS.

Как правило, клиенты Службы времени Windows автоматически получают точное время для синхронизации с контроллеров домена в том же домене. В лесу контроллеры дочернего домена синхронизируют время с контроллерами в родительских доменах. Когда сервер времени возвращает прошедший проверку подлинности пакет NTP на клиент, который запрашивает время, пакет подписывается с помощью ключа сеанса Kerberos, определенного учетной записью междоменного доверия. Учетная запись междоменного доверия создается, когда новый домен AD DS присоединяется к лесу, а служба сетевого входа в систему управляет ключом сеанса. Таким образом, контроллер домена, настроенный как надежный в корневом домене леса, становится аутентифицированным источником времени для всех контроллеров домена, как в родительском, так и в дочернем домене, и косвенно для всех компьютеров, расположенных в дереве доменов.

Службу времени Windows можно настроить на работу между лесами, однако эта конфигурация не защищена. Например, NTP-сервер может быть доступен в другом лесу. Однако, поскольку этот компьютер находится в другом лесу, ключ сеанса Kerberos для подписывания и проверки подлинности пакетов NTP отсутствует. Для получения точной синхронизации времени с компьютера в другом лесу клиенту нужен сетевой доступ к этому компьютеру, а служба времени должна быть настроена на использование определенного источника времени, расположенного в другом лесу. Если клиент вручную настроен на доступ к времени с NTP-сервера за пределами собственной доменной иерархии, то пакеты NTP, передаваемые между клиентом и сервером времени, не проходят проверку подлинности и, следовательно, не являются безопасными. Несмотря на реализацию доверия лесов, Служба времени Windows не защищена между лесами. Хотя безопасный канал сетевого входа в систему является механизмом проверки подлинности для Службы времени Windows, проверка подлинности в лесах не поддерживается.

Аппаратные устройства, поддерживаемые Службой времени Windows

Часы на основе оборудования, такие как GPS или радиочасы, часто используются в качестве устройств с высокоточными эталонными часами. По умолчанию поставщик времени NTP Службы времени Windows не поддерживает прямое подключение аппаратного устройства к компьютеру, однако вы можете создать программный независимый поставщик времени, поддерживающий этот тип подключения. Этот тип поставщика, в сочетании со Службой времени Windows, может обеспечить надежную и стабильную привязку по времени.

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

Многие приемники GPS и другие устройства времени могут функционировать в сети как NTP-серверы. Лес AD DS можно настроить на синхронизацию времени с этих внешних устройств, только если они также работают в сети как NTP-серверы. Для этого настройте контроллер домена в качестве эмулятора основного контроллера домена в корне леса, чтобы выполнить синхронизацию с NTP-сервером, предоставленным устройством GPS. Сведения о том, как это сделать, см. статью Configure the Windows Time service on the PDC emulator in the Forest Root Domain (Настройка службы времени Windows для эмулятора основного контроллера домена в корневом домене леса).

Простой протокол сетевого времени

Протокол SNTP — это упрощенный протокол, предназначенный для серверов и клиентов, которым не требуется степень точности, предоставляемая NTP. SNTP является более элементарной версией NTP — основного протокола времени, используемого в Windows 2000. Так как форматы сетевых пакетов SNTP и NTP идентичны, эти два протокола являются взаимодействующими. Основное различие между ними заключается в том, что SNTP не поддерживает системы управления ошибками и сложные фильтры, предоставляемые NTP. Дополнительные сведения о простом протоколе сетевого времени см. в документе RFC 1769 в базе данных RFC IETF.

Взаимодействие протокола времени

Служба времени Windows может работать в смешанной среде компьютеров под управлением Windows 2000, Windows XP и Windows Server 2003, поскольку протокол SNTP, используемый в Windows 2000, совместим с протоколом NTP в Windows XP и Windows Server 2003.

Служба времени в Windows NT Server 4.0, именуемая TimeServ, синхронизирует время в сети Windows NT 4.0. TimeServ — это дополнительный компонент, доступный в составе Microsoft Windows NT 4.0 Resource Kit и не обеспечивающий степень надежности синхронизации времени, необходимой для Windows Server 2003.

Служба времени Windows может взаимодействовать с компьютерами под управлением Windows NT 4.0, поскольку они могут синхронизировать время с компьютерами под управлением Windows 2000 или Windows Server 2003; однако компьютер под управлением Windows 2000 или Windows Server 2003 не обнаруживает серверы времени Windows NT 4.0 автоматически. Например, если ваш домен настроен на синхронизацию времени с помощью метода синхронизации на основе иерархии домена, и вы хотите, чтобы компьютеры в иерархии домена синхронизировали время с контроллером домена Windows NT 4.0, вам нужно настроить эти компьютеры на синхронизацию с контроллерами домена Windows NT 4.0 вручную.

В Windows NT 4.0 используется более простой механизм синхронизации времени, чем в Службе времени Windows. Таким образом, чтобы обеспечить точную синхронизацию времени по сети, рекомендуется обновить все контроллеры домена Windows NT 4.0 до Windows 2000 или Windows Server 2003.

Процессы и взаимодействия службы времени Windows

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

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

Компьютеры под управлением Windows XP Home Edition или не присоединенных к домену компьютеров, не пытаются синхронизироваться с доменной иерархией, но по умолчанию настроены на получение времени от time.windows.com.

Для установки компьютера под управлением Windows Server 2003 в качестве доверенного, компьютер должен быть настроен как надежный источник времени. По умолчанию первый контроллер домена, установленный в домене Windows Server 2003, автоматически настраивается как надежный источник времени. Поскольку этот компьютер является полномочным для домена, он должен быть настроен на синхронизацию с внешним источником времени, а не с иерархией домена. Кроме того, по умолчанию все остальные члены домена Windows Server 2003 настроены на синхронизацию с иерархией домена.

После установки сети Windows Server 2003 Службу времени Windows можно настроить на использование одного из следующих параметров синхронизации.

• Синхронизация на основе иерархии домена

• Источник синхронизации, указанный вручную

• Все доступные механизмы синхронизации

• Без синхронизации.

Каждый из упомянутых типов синхронизации подробно рассматриваются в следующих разделах.

Синхронизация на основе иерархии домена

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

Синхронизация времени в иерархии AD DS

Конфигурация надежного источника времени

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

Выбор источника данных

Процесс выбора источника времени может создать две проблемы в сети:

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

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

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

• Если компьютер является членом сервера или рабочей станции в домене, то по умолчанию он следует иерархии AD DS и синхронизирует свое время с контроллером домена в локальном домене, на котором в настоящее время работает Служба времени Windows.

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

• Надежный источник времени можно синхронизировать только с контроллером домена в родительском домене.

• Эмулятор основного контроллера домена может синхронизироваться с надежным источником времени в собственном домене или на любом контроллере в родительском домене.

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

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

Запросы к источнику времени контроллера домена

Примечание

• Компьютер никогда не синхронизируется с самим собой. Если компьютер пытается синхронизироваться с эмулятором основного контроллера локального домена, он не пытается выполнить запросы 3 или 6.

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

Определение оценки

Когда Служба времени Windows определяет, что она идентифицировала контроллер домена с наилучшей оценкой, она больше не выполняет запросы. Оценки, присваиваемые службой времени, являются кумулятивными, что означает, что эмулятор PDC, расположенный на одном и том же сайте, получает оценку в девять баллов.

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

Указанная вручную синхронизация

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

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

Все доступные механизмы синхронизации

Параметр «Все доступные механизмы синхронизации» является наиболее полезным методом синхронизации для пользователей в сети. Этот метод позволяет синхронизироваться с иерархией доменов и может также, в зависимости от конфигурации, предоставлять альтернативный источник времени, если иерархия домена становится недоступной. Если клиенту не удается синхронизировать время с иерархией домена, источник времени автоматически возвращается к источнику времени, указанному параметром NtpServer. Этот метод синхронизации наиболее часто обеспечивает точное время для клиентов.

Остановка синхронизации времени

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

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

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

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

Отключение Службы времени Windows

Службу времени Windows (W32Time) можно отключить полностью. Если вы решили реализовать сторонний продукт синхронизации времени, использующий NTP, сначала нужно отключить Службу времени Windows. Это связано с тем, что все NTP-серверы нуждаются в доступе к порту 123 UDP, и пока Служба времени Windows запущена на операционной системе Windows Server 2003, порт 123 остается зарезервированным Службой времени Windows.

Сетевые порты, используемые службой времени Windows

Служба времени Windows взаимодействует в сети для определения надежных источников времени, получения сведений о времени и предоставления сведений о времени другим компьютерам. Этот обмен данными выполняется в соответствии с определением RFC и SNTP.

Назначения портов для Службы времени Windows

См. также

Windows Time Service Technical Reference (Технический справочник по службе времени Windows) Windows Time Service Tools and Settings (Средства и параметры службы времени Windows) Статья 902229 базы знаний Майкрософт

Руководство по отладке, а также поиску и устранению неполадок протокола NTP

Введение

В этом документе описывается использование отладки для поиска и устранения неполадок в работе протокола NTP, а также выходные данные основных команд show ntp.

Команды show протокола NTP

Прежде чем начинать поиск причин неполадок в работе протокола NTP, необходимо понять, как использовать следующие команды и их выходные данные:

• show ntp association
• show ntp association detail
• show ntp status

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

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

show ntp association

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

Вот пример выходных данных команды show ntp association:

CLA_PASA#sh ntp association
     address        ref clock    st when poll reach delay offset   disp
 ~127.127.7.1     127.127.7.1      9   50   64 377    0.0   0.00    0.0
 ~10.50.44.69     10.50.36.106     5 21231 1024  0    3.8  -4.26 16000.
+~10.50.44.101    10.50.38.114     5   57   64   1    3.6  -4.30 15875.
+~10.50.44.37     10.50.36.50      5    1  256 377    0.8   1.24    0.2
 ~10.50.44.133    10.50.38.170     5 12142 1024  0    3.2   1.24 16000.
+~10.50.44.165    10.50.38.178     5   35  256 357    2.5  -4.09    0.2
+~10.50.38.42     86.79.127.250    4    7  256 377    0.8  -0.29    0.2
*~10.50.36.42     86.79.127.250    4  188  256 377    0.7  -0.17    0.3
+~10.50.38.50     86.79.127.250    4   42  256 377    0.9   1.02    0.4
+~10.50.36.50     86.79.127.250    4   20  256 377    0.7   0.87    0.5
 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

    address    ref clock st when poll reach  delay offset  disp
~10.50.44.69 10.50.36.106  5 21231 1024  0   3.8  -4.26 16000.

show ntp association detail

Вот пример выходных данных команды show ntp association detail:

Router#sho ntp assoc detail
10.4.2.254 configured, our_master, sane, valid, stratum 1
ref ID .GPS., time D36968AA.CC528FE7 (02:10:50.798 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.44, reach 377, sync dist 207.565
delay 2.99 msec, offset 268.3044 msec, dispersion 205.54
precision 2**19, version 3
org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012)
rcv time D36968B7.A2F44E2C (02:11:03.636 UTC Fri May 25 2012)
xmt time D36968B7.A21D3780 (02:11:03.633 UTC Fri May 25 2012)
filtdelay =    2.99   2.88 976.61 574.65 984.71 220.26 168.12   2.72
filtoffset = 268.30 172.15 -452.49 -253.59 -462.03 -81.98 -58.04  22.38
filterror =    0.02   0.99   1.95   1.97   2.00   2.01   2.03   2.04
10.3.2.254 configured, selected, sane, valid, stratum 1
ref ID .GPS., time D36968BB.B16C4A21 (02:11:07.693 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 3.34, reach 377, sync dist 192.169
delay 0.84 msec, offset 280.3251 msec, dispersion 188.42
precision 2**19, version 3
org time D36968BD.E69085E4 (02:11:09.900 UTC Fri May 25 2012)
rcv time D36968BD.9EE9048B (02:11:09.620 UTC Fri May 25 2012)
xmt time D36968BD.9EA943EF (02:11:09.619 UTC Fri May 25 2012)
filtdelay =    0.84   0.75 663.68   0.67   0.72 968.05 714.07   1.14
filtoffset = 280.33 178.13 -286.52  42.88  41.41 -444.37 -320.25  35.15
filterror =    0.02   0.99   1.97   1.98   1.98   2.00   2.03   2.03
10.1.2.254 configured, insane, invalid, stratum 1
ref ID .GPS., time D3696D3D.BBB4FF24 (02:30:21.733 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 4.15, reach 1, sync dist 15879.654
delay 0.98 msec, offset 11.9876 msec, dispersion 15875.02
precision 2**19, version 3
org time D3696D3D.E4C253FE (02:30:21.893 UTC Fri May 25 2012)
rcv time D3696D3D.E1D0C1B9 (02:30:21.882 UTC Fri May 25 2012)
xmt time D3696D3D.E18A748D (02:30:21.881 UTC Fri May 25 2012)
filtdelay =    0.98   0.00   0.00   0.00   0.00   0.00   0.00   0.00
filtoffset =  11.99   0.00   0.00   0.00   0.00   0.00   0.00   0.00
filterror =    0.02 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0

Термины, уже определенные в разделе, посвященном команде show ntp association, не повторяются.

org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012)
rcv time D36968B7.A2F44E2C (02:11:03.636 UTC Fri May 25 2012)

filtdelay =   2.99  2.88 976.61 574.65 984.71 220.26 168.12 2.72
filtoffset = 268.30 172.15 -452.49 -253.59 -462.03 -81.98 -58.04 22.38
filterror =   0.02  0.99   1.95   1.97   2.00  2.01  2.03 2.04

show ntp status

Вот пример выходных данных команды show ntp status:

USSP-B33S-SW01#sho ntp status
Clock is synchronized, stratum 2, reference is 10.4.2.254
nominal freq is 250.0000 Hz, actual freq is 250.5630 Hz, precision is 2**18
reference time is D36968F7.7E3019A9 (02:12:07.492 UTC Fri May 25 2012)
clock offset is 417.2868 msec, root delay is 2.(-18), или 3,8 микросекунды.
Потеря синхронизации между одноранговыми узлами NTP или между сервером времени и клиентом может произойти по многим причинам. В NTP синхронизация с компьютером, время которого могло бы быть неоднозначным, предотвращается следующими способами:
 
       
NTP никогда не синхронизируется с компьютером, который сам не синхронизирован.
 
        
NTP сравнивает время, о котором сообщают несколько компьютеров, и не синхронизируется с компьютером, время которого существенно отличается от других, даже если его значение уровня меньше.
 
       
 
      
    
Поиск и устранение неполадок NTP с помощью отладки
  
   
Вот некоторые наиболее распространенные причины неполадок в работе NTP:
 
   
Пакеты NTP не получены.
 
    
Пакеты NTP получены, но не обработаны процессом NTP в IOS.
 
    
Пакеты NTP обработаны, но ошибочные показатели или данные пакета приводят к потере синхронизации.
 
    
Период тактовых импульсов NTP установлен вручную.
 
   
Вот важные команды отладки, которые позволяют выявить причину этих неполадок:
 
   
debug ip packets <acl>
 
    
debug ntp packets
 
    
debug ntp validity
 
    
debug ntp sync
 
    
debug ntp events
 
   
В следующих разделах иллюстрируется использование отладок для устранения этих распространенных неполадок.
 
   
Примечание.Воспользуйтесь инструментом Command Lookup ( только для зарегистрированных заказчиков), чтобы получить дополнительную информацию о командах, используемых в этом разделе.
 
   
Примечание.Перед использованием команд debug обратитесь к документу Важные сведения о командах отладки.
 
    
    
Пакеты NTP не получены
  
   
Используйте команду debug ip packet, чтобы проверить, происходит ли получение и передача пакетов NTP. Так как выходные данные команды отладки могут быть обширными, можно ограничить их с помощью списков контроля доступа (ACL). NTP использует порт 123 протокола пользовательских датаграмм (UDP).
 
   
Создайте ACL 101:
access-list 101 permit udp any any eq 123
access-list 101 permit udp any eq 123 any
Пакеты NTP обычно имеют порт источника и порт назначения 123; это будет полезно:
permit udp any eq 123 any eq 123 
Используйте этот ACL-список для ограничения выходных данных команды debug ip packet:
debug ip packet 101
Если неполадка связана с конкретными одноранговыми узлами, сузьте ACL 101 до этих узлов. Если адрес однорангового узла — 172.16.1.1, измените ACL 101 следующим образом:
access-list 101 permit udp host 172.16.1.1 any eq 123
access-list 101 permit udp any eq 123 host 172.16.1.1
Выходные данные в этом примере указывают, что пакеты не отправляются:
241925: Apr 23 2012 15:46:26.101 ETE: IP: s=10.50.38.70 (Tunnel99), d=10.50.44.101, len 76, 
input feature
241926: Apr 23 2012 15:46:26.101 ETE:    UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0, 
forus FALSE, sendself FALSE, mtu 0
241927: Apr 23 2012 15:46:26.101 ETE: IP: s=10.50.38.70 (Tunnel99), d=10.50.44.101, len 76, 
input feature
241928: Apr 23 2012 15:46:26.101 ETE:    UDP src=123, dst=123, MCI Check(55), rtype 0, 
forus FALSE, sendself FALSE, mtu 0
Как только вы подтвердите, что пакеты NTP не получены, необходимо сделать следующее:
Проверьте, правильно ли настроен NTP.
Проверьте, не блокирует ли ACL-список пакеты NTP.
Проверьте наличие проблем маршрутизации к IP-адресу источника или назначения.
Пакеты NTP не обрабатываются
Если включены команды debug ip packet и debug ntp packets, можно увидеть получаемые и передаваемые пакеты, а также действия NTP с этими пакетами. Для каждого полученного пакета NTP (как показано командой debug ip packet) существует соответствующая запись, создаваемая командой debug ntp packets.
Вот выходные данные отладки, когда процесс NTP обрабатывает полученные пакеты:
Apr 20 00:16:34.143 UTC: IP: tableid=0, s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), routed 
via FIB
.Apr 20 00:16:34.143 UTC: IP: s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), len 76, sending
.Apr 20 00:16:34.143 UTC: IP: s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), len 76, sending 
full packet
.Apr 20 00:16:34.143 UTC: NTP: xmit packet to 10.1.2.254:
.Apr 20 00:16:34.143 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Apr 20 00:16:34.143 UTC: rtdel 0021 (0.504), rtdsp 1105E7 (17023.056), refid 0A0102FE 
(10.1.2.254)
.Apr 20 00:16:34.143 UTC: ref D33B2922.24FEBDC7 (00:15:30.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:34.143 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:34.143 UTC: xmt D33B2962.24CAFAD1 (00:16:34.143 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: IP: s=10.1.2.254 (Vlan2), d=10.3.2.31, len 76, rcvd 2
.Apr 20 00:16:34.143 UTC: NTP: rcv packet from 10.1.2.254 to 10.3.2.31 on Vlan2:
.Apr 20 00:16:34.143 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.Apr 20 00:16:34.143 UTC: rtdel 0000 (0.000), rtdsp 009D (2.396), refid 47505300 (71.80.83.0)
.Apr 20 00:16:34.143 UTC: ref D33B2952.4CC11CCF (00:16:18.299 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: org D33B2962.24CAFAD1 (00:16:34.143 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: rec D33B2962.49D3724D (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: xmt D33B2962.49D997D0 (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: inp D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: tableid=0, s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), routed 
via FIB
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending 
full packet
.Apr 20 00:16:36.283 UTC: NTP: xmit packet to 10.8.2.254:
.Apr 20 00:16:36.283 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 002F (0.717), rtdsp 11058F (17021.713), refid 0A0102FE 
(10.1.2.254)
.Apr 20 00:16:36.283 UTC: ref D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: s=10.8.2.254 (Vlan2), d=10.3.2.31, len 76, rcvd 2
.Apr 20 00:16:36.283 UTC: NTP: rcv packet from 10.8.2.254 to 10.3.2.31 on Vlan2:
.Apr 20 00:16:36.283 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 0000 (0.000), rtdsp 0017 (0.351), refid 47505300 (71.80.83.0)
.Apr 20 00:16:36.283 UTC: ref D33B295B.8AF7FE33 (00:16:27.542 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: rec D33B2964.4A6AD269 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.4A7C00D0 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: inp D33B2964.498A755D (00:16:36.287 UTC Fri Apr 20 2012)
Вот пример, когда NTP не обрабатывает полученные пакеты. Несмотря на то что пакеты NTP получены (как показывает команда debug ip packet), процесс NTP не обрабатывает их. Для отправленных пакетов NTP представлены соответствующие выходные данные команды debug ntp packets, поскольку процесс NTP должен сгенерировать пакет. Эта неполадка характерна для полученных пакетов NTP, которые не обрабатываются.
071564: Apr 23 2012 15:46:26.100 ETE: NTP: xmit packet to 10.50.44.101:
071565: Apr 23 2012 15:46:26.100 ETE: leap 0, mode 1, version 3, stratum 5, ppoll 1024
071566: Apr 23 2012 15:46:26.100 ETE: rtdel 07B5 (30.106), rtdsp 0855 (32.547), refid 0A32266A 
(10.50.38.106)
071567: Apr 23 2012 15:46:26.100 ETE: ref D33FDB05.1A084831 (15:43:33.101 ETE Mon Apr 23 2012)
071568: Apr 23 2012 15:46:26.100 ETE: org 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071569: Apr 23 2012 15:46:26.100 ETE: rec 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071570: Apr 23 2012 15:46:26.100 ETE: xmt D33FDBB2.19D3457C (15:46:26.100 ETE Mon Apr 23 2012)
PCY_PAS1#
071571: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, 
input feature
071572: Apr 23 2012 15:47:31.497 ETE:    UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0, 
forus FALSE, sendself FALSE, mtu 0
071573: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, 
input feature
071574: Apr 23 2012 15:47:31.497 ETE:    UDP src=123, dst=123, MCI Check(55), rtype 0, 
forus FALSE, sendself FALSE, mtu 0
071575: Apr 23 2012 15:47:31.497 ETE: FIBipv4-packet-proc: route packet from Tunnel99 src 
10.50.38.78 dst 10.50.44.69
071576: Apr 23 2012 15:47:31.497 ETE: FIBfwd-proc: base:10.50.44.69/32 receive entry
PCY_PAS1#
071577: Apr 23 2012 15:47:31.497 ETE: FIBipv4-packet-proc: packet routing failed
071578: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, rcvd 2
071579: Apr 23 2012 15:47:31.497 ETE:    UDP src=123, dst=123
071580: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, stop 
process pak for forus packet
071581: Apr 23 2012 15:47:31.497 ETE:    UDP src=123, dst=123
PCY_PAS1#
071582: Apr 23 2012 16:03:30.105 ETE: NTP: xmit packet to 10.50.44.101:
071583: Apr 23 2012 16:03:30.105 ETE: leap 0, mode 1, version 3, stratum 5, ppoll 1024
071584: Apr 23 2012 16:03:30.105 ETE: rtdel 0759 (28.702), rtdsp 087D (33.157), refid 0A32266A 
(10.50.38.106)
071585: Apr 23 2012 16:03:30.105 ETE: ref D33FDF05.1B2CC3D4 (16:00:37.106 ETE Mon Apr 23 2012)
071586: Apr 23 2012 16:03:30.105 ETE: org 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071587: Apr 23 2012 16:03:30.105 ETE: rec 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071588: Apr 23 2012 16:03:30.105 ETE: xmt D33FDFB2.1B1D5E7E (16:03:30.105 ETE Mon Apr 23 2012)
PCY_PAS1#
071589: Apr 23 2012 16:04:35.502 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, 
input feature
071590: Apr 23 2012 16:04:35.506 ETE:    UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0, 
forus FALSE, sendself FALSE, mtu 0
071591: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, 
input feature
071592: Apr 23 2012 16:04:35.506 ETE:    UDP src=123, dst=123, MCI Check(55), rtype 0, forus 
FALSE, sendself FALSE, mtu 0
071593: Apr 23 2012 16:04:35.506 ETE: FIBipv4-packet-proc: route packet from Tunnel99 src 
10.50.38.78 dst 10.50.44.69
071594: Apr 23 2012 16:04:35.506 ETE: FIBfwd-proc: base:10.50.44.69/32 receive entry
PCY_PAS1#
071595: Apr 23 2012 16:04:35.506 ETE: FIBipv4-packet-proc: packet routing failed
071596: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, rcvd 2
071597: Apr 23 2012 16:04:35.506 ETE:    UDP src=123, dst=123
071598: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, stop 
process pak for forus packet
071599: Apr 23 2012 16:04:35.506 ETE:    UDP src=123, dst=123
PCY_PAS1#
Потеря синхронизации
Потеря синхронизации может произойти, если значение дисперсии и/или задержки для сервера оказывается очень большим. Большие значения указывают, что пакеты слишком долго перемещаются от сервера или однорангового узла до клиента по отношению к источнику синхросигналов. Итак, локальный компьютер не может доверять точности времени, представленного в пакете, поскольку не знает, как долго передавался пакет.
Протокол NTP скрупулезен в отношении времени и не будет выполнять синхронизацию с другим устройством, которому не может доверять или не может скорректировать так, чтобы ему можно было доверять.
Если канал загружен и по пути выполняется буферизация, возникает задержка пакетов при доставке клиенту NTP. Поэтому метка времени в последующем пакете NTP может иногда очень сильно отличаться, и локальный клиент не может скорректировать это различие.
Отключить проверку таких пакетов в NTP можно только при использовании SNTP (простой сетевой протокол синхронизации времени). SNTP не может по большей части считаться альтернативным вариантом, поскольку не имеет широкой поддержки в программном обеспечении.
Столкнувшись с потерей синхронизации, необходимо проверить каналы связи:
Они перегружены?
Есть ли отбрасывание пакетов в ваших каналах глобальной сети (WAN)
Выполняется ли шифрование?
Контролируйте значение достижимости с помощью команды show ntp associations detail. Самое большое значение — 377. Если значение равно 0 или мало, пакеты NTP поступают с перебоями, а локальный клиент теряет синхронизацию с сервером.
debug ntp validity
Команда debug ntp validity указывает, если пакет NTP не прошел проверку правильности или достоверности, а также причину сбоя. Сравните эти выходные данные с проверками правильности, указанными в RFC1305, которые используются для проверки пакета NTP, полученного от сервера. Определены восемь проверок:
Проверка
Маска
Пояснение
1
0x01
Получен дубликат пакета
2
0x02
Получен поддельный пакет
3
0x04
Протокол не синхронизирован
4
0x08
Задержка или дисперсия однорангового узла не прошла проверку граничных условий
5
0x10
Сбой аутентификации однорангового узла
6
0x20
Часы однорангового узла не синхронизированы (характерно для несинхронизированного сервера)
7
0x40
Уровень однорангового узла вне пределов
8
0x80
Задержка или дисперсия корневого узла не прошла проверку граничных условий
Вот пример выходных данных команды debug ntp validity:
PCY_PAS1#debug ntp validity 
NTP peer validity debugging is on
009585: Mar 1 2012 09:14:32.670 HIVER: NTP: packet from 192.196.113.57 failed validity tests 52
009586: Mar 1 2012 09:14:32.670 HIVER: Authentication failed
009587: Mar 1 2012 09:14:32.670 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009588: Mar 1 2012 09:14:38.210 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009589: Mar 1 2012 09:14:38.210 HIVER: Authentication failed
PCY_PAS1#
009590: Mar 1 2012 09:14:43.606 HIVER: NTP: packet from 163.110.103.27 failed validity tests 14
009591: Mar 1 2012 09:14:43.606 HIVER: Authentication failed
PCY_PAS1#
009592: Mar 1 2012 09:14:48.686 HIVER: NTP: packet from 192.196.113.57 failed validity tests 52
009593: Mar 1 2012 09:14:48.686 HIVER: Authentication failed
009594: Mar 1 2012 09:14:48.686 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009596: Mar 1 2012 09:14:54.222 HIVER: NTP: packet from 163.110.103.35 failed validity tests 14
009597: Mar 1 2012 09:14:54.222 HIVER: Authentication failed
PCY_PAS1#
009598: Mar 1 2012 09:14:54.886 HIVER: NTP: synced to new peer 10.50.38.106
009599: Mar 1 2012 09:14:54.886 HIVER: NTP: 10.50.38.106 synced to new peer
PCY_PAS1#
009600: Mar 1 2012 09:14:59.606 HIVER: NTP: packet from 163.110.103.27 failed validity tests 14
009601: Mar 1 2012 09:14:59.606 HIVER: Authentication failed
PCY_PAS1#
009602: Mar 1 2012 09:15:04.622 HIVER: NTP: packet from 192.196.113.137 failed validity tests 52
009603: Mar 1 2012 09:15:04.622 HIVER: Authentication failed
009604: Mar 1 2012 09:15:04.622 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009605: Mar 1 2012 09:15:10.238 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009606: Mar 1 2012 09:15:10.238 HIVER: Authentication failed
PCY_PAS1#
009607: Mar 1 2012 09:15:15.338 HIVER: NTP: packet from 163.83.23.140 failed validity tests 52
009608: Mar 1 2012 09:15:15.338 HIVER: Authentication failed
009609: Mar 1 2012 09:15:15.338 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009610: Mar 1 2012 09:15:20.402 HIVER: NTP: packet from 192.196.113.92 failed validity tests 74
009611: Mar 1 2012 09:15:20.402 HIVER: Authentication failed
009612: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Clock unsynchronized
009613: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Stratum out of bound
debug ntp packets
Можно использовать команду debug ntp packets, чтобы просмотреть время, предоставленное одноранговым узлом или сервером в полученном пакете. Локальный компьютер синхронизации времени также сообщает известное ему время одноранговому узлу или серверу в передаваемом пакете.
Поле
пакет rcv
пакет xmit
org
Метка времени отправителя пакета, которая представляет собой время сервера.
Метка времени отправителя (клиента) при отправке пакета. (Клиент отправляет пакет на сервер.
rec
Метка времени на клиенте при получении пакета.
Текущее время клиента.
В этом примере выходных данных метки времени в пакете, полученном от сервера, и пакете, отправленном на другой сервер, одинаковы; это указывает, что NTP клиент синхронизирован.
USSP-B33S-SW01#debug ntp packets
NTP packets debugging is on
USSP-B33S-SW01#
May 25 02:21:48.182 UTC: NTP: rcv packet from 10.1.2.254 to 10.3.2.31 on Vlan2:
May 25 02:21:48.182 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
May 25 02:21:48.182 UTC: rtdel 0000 (0.000), rtdsp 00F2 (3.693), refid 47505300 (71.80.83.0)
May 25 02:21:48.182 UTC: ref D3696B38.B722C417 (02:21:44.715 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: org D3696B3C.2EA179BA (02:21:48.182 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: rec D3696B3D.E58DE1BE (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: xmt D3696B3D.E594E7AF (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: inp D3696B3C.2EDFC333 (02:21:48.183 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:22:46.051 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:22:46.051 UTC: rtdel 00C0 (2.930), rtdsp 1C6FA (1777.252), refid 0A0402FE (10.4.2.254)
May 25 02:22:46.051 UTC: ref D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: org D3696B37.E72C75AE (02:21:43.903 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: rec D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: xmt D3696B76.0D43AE7D (02:22:46.051 UTC Fri May 25 2012)
Вот пример выходных данных, когда часы не синхронизированы. Обратите внимание на разницу во времени между пакетами xmit и rcv. Дисперсия однорангового узла будет иметь максимальное значение в 16000. Кроме того, для узла будет указана достижимость 0.
USSP-B33S-SW01#
.May 25 02:05:59.011 UTC: NTP: xmit packet to 10.4.2.254:
.May 25 02:05:59.011 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.May 25 02:05:59.011 UTC: rtdel 00A3 (2.487), rtdsp 1104D0 (17018.799), refid 0A0402FE 
(10.4.2.254)
.May 25 02:05:59.011 UTC: ref D3696747.03D8661A (02:04:55.015 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.May 25 02:05:59.011 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.May 25 02:05:59.011 UTC: xmt D3696787.03105783 (02:05:59.011 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: NTP: rcv packet from 10.4.2.254 to 10.3.2.31 on Vlan2:
.May 25 02:05:59.011 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.May 25 02:05:59.011 UTC: rtdel 0000 (0.000), rtdsp 0014 (0.305), refid 47505300 (71.80.83.0)
.May 25 02:05:59.011 UTC: ref D3696782.C96FD778 (02:05:54.786 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: org D3696787.03105783 (02:05:59.011 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: rec D3696787.281A963F (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: xmt D3696787.282832C4 (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: inp D3696787.03C63542 (02:05:59.014 UTC Fri May 25 2012)
debug ntp sync and debug ntp events
Команда debug ntp sync формирует выходные данные, состоящие из одной строки, которые показывают, синхронизированы ли часы, или синхронизация изменилась. Эта команда обычно выполняется вместе с командой debug ntp events.
Команда debug ntp events показывает все происходящие события NTP, что помогает определить, не привело ли изменение в NTP к неполадке, такой как нарушение синхронизации часов. (Другими словами, если ваши синхронизированные часы внезапно сходят с ума, вы знаете, что нужно искать изменение или триггер!
Вот пример обеих команд отладки. Первоначально клиентские часы были синхронизированы. Команда debug ntp events показывает, что произошло изменение на уровне однорангового узла NTP и синхронизация часов нарушилась.
USSP-B33S-SW01#debug ntp sync
NTP clock synchronization debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
USSP-B33S-SW01#debug ntp events
NTP events debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
May 25 02:25:57.620 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:25:57.620 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:25:57.620 UTC: rtdel 00D4 (3.235), rtdsp 26B26 (2418.549), refid 0A0402FE (10.4.2.254)
May 25 02:25:57.620 UTC: ref D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696BF7.E5F91077 (02:24:55.898 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: NTP: rcv packet from 10.4.2.254 to 10.3.2.31 on Vlan2:
May 25 02:25:57.620 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
May 25 02:25:57.620 UTC: rtdel 0000 (0.000), rtdsp 000E (0.214), refid 47505300 (71.80.83.0)
May 25 02:25:57.620 UTC: ref D3696C37.D528800E (02:25:59.832 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696C37.E5C7AB3D (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C37.E5D1F273 (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: inp D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:25:59.830 UTC: NTP: clock reset
May 25 02:25:59.830 UTC: NTP: sync change
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:26:05.817 UTC: NTP: xmit packet to 10.1.2.254:
May 25 02:26:05.817 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
May 25 02:26:05.817 UTC: rtdel 00C2 (2.960), rtdsp 38E9C (3557.068), refid 0A0402FE (10.4.2.254)
May 25 02:26:05.817 UTC: ref D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:26:05.817 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: xmt D3696C3D.D12D0565 (02:26:05.817 UTC Fri May 25 2012)
Настройка периода тактовых импульсов NTP вручную
Веб-сайт Cisco.com предупреждает о следующем:
«Команда ntp clock-period формируется автоматически для отражения постоянно изменяющегося поправочного коэффициента, когда вводится команда copy running-configuration startup-configuration для сохранения конфигурации в NVRAM. Не пытайтесь использовать команду ntp clock-period вручную. Обязательно удалите строку с этой командой при копировании файлов конфигурации на другие устройства»
Значение периода тактовых импульсов зависит от аппаратного обеспечения и поэтому отличается для каждого устройства.(-32) = 0.0040065678767859935760498046875, или немногим больше 4 миллисекунд.
Cisco рекомендует обеспечить работу маршрутизатора в течение приблизительно одной недели в нормальных сетевых условиях, а затем использовать команду wr mem, чтобы сохранить это значение. Это обеспечит точное значение для следующей перезагрузки и позволит ускорить синхронизацию NTP.
Не Не Не используйте команду ntp clock-period при сохранении конфигурации для использования на другом устройстве, поскольку эта команда восстановит значение по умолчанию для периода тактовых импульсов этого устройства. Настоящее значение будет вычислено повторно (но точность системных часов в течение периода повторного расчета уменьшится).
Помните, что это значение зависит от аппаратного обеспечения, поэтому использование скопированной конфигурации на других устройствах может приводить к неполадкам. Для устранения этой проблемы Cisco планирует заменить версию 3 протокола NTP версией 4.
Будучи неосведомленным об этих проблемах, вы можете решить исправить это значение вручную. Для перехода от одного устройства к другому вы можете решить скопировать старую конфигурацию и вставить ее на новое устройство. К сожалению, поскольку команда ntp clock-period приведена в конфигурациях running-config и startup-config, на новое устройство вставляется и период тактовых импульсов NTP. Когда это происходит, NTP на новом клиенте всегда теряет синхронизацию с сервером с высоким значением дисперсии однорангового узла.
Вместо этого очистите период тактовых импульсов NTP с помощью команды no ntp clock-period, а затем сохраните конфигурацию. Маршрутизатор в конечном счете вычислит подходящий для него период тактовых импульсов.
Команда ntp clock-period больше недоступна в ПО Cisco IOS версии 15.0 и более поздних версий; синтаксический анализатор теперь отклоняет эту команду со следующей ошибкой:
"%NTP: This configuration command is deprecated."
Поэтому нельзя настраивать период тактовых импульсов вручную. Кроме того, период тактовых импульсов не разрешен в running-config. Синтаксический анализатор отклоняет команду, если она присутствовала в конфигурации запуска (в более ранних версиях Cisco IOS, например в версии 12.4), при копировании конфигурации запуска в рабочую конфигурацию (running-config) в ходе загрузки.
Новая, заменяющая команда — ntp clear drift.
Дополнительные сведения
Настройка синхронизации времени из Интернета | windows
Описывается процедура настройки синхронизации времени Windows по сети. Как тоже самое делается на FreeBSD и Linux, читайте в статье [1].




1. На firewall нужно открыть порт 123 UDP (служба NTP - Network Time Protocol).
2. Выбрать компьютер с W2k, который будет сервером времени (у меня он назывался в нашей сети как AS01). Он будет время получать через Инет, а остальные компьютеры в сети (клиенты времени) будут синхронизировать своё время с ним.
3. На сервере командой

net time \\as01 /setsntp:"192.5.41.209 192.5.41.41"

прописывается путь, откуда получаем время. Вместо IP адресов серверов времени (NTP-провайдеров эталонного времени) можно указывать их имена. Эта команда сама меняет ключи в реестре по адресу
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters:
   ntpserver REG_SZ 192.5.41.209 192.5.41.41
   type REG_SZ NTP
Примечание: список серверов времени можно взять на одном из множества сайтов провайдеров точного времени, которые есть в Интернете.
4. Чтобы компьютер AS01 мог работать как сервер времени, параметр LocalNTP надо изменить с 0 на 1.
5. Рестартуем службу w32time. Теперь AS01 у нас получает точное время.
6. Клиенты W2K настраиваются командой

net time \\имя_компьютера-клиента /setsntp:AS01

После этой команды службу времени на клиенте надо рестартовать.
7. Клиенты win98 настраиваются на исполнение шедулером команды:


Время на станции синхронизируется со временем сервера-источника домена, членом которого является данная станция:

net time \\time_server_name /set /y

Время на станции согласуется со временем произвольно выбранного сервера:

net time /domain:domain_name /set /y

Синхронизация времени рабочей станции со временем станции-источника указанного домена, т. е. в нашем случае "net time \\AS01 /set /y".
Для синхронизации времени и проверки службы w32time существует консольная утилита w32tm (очень подробно описана во встроенной справке Windows). Пример использования:

w32tm /config /update /manualpeerlist:server_IP_address /syncfromflags:MANUAL

[Ссылки]
1. Синхронизация времени по NTP.
Настройка NTP сервера в MikroTik
Если вам хочется в своей сети ещё и NTP сервер то можно использовать для этого MikroTik. Предварительно необходимо установить пакет NTP и  настроить клиент как в этой инструкции. В самом простом случае достаточно активировать сервер.
Пояснения по Broadcast, Multicast, Manycast
Broadcast mode.
Клиенты NTP "слушают" широковещательные сообщения, рассылаемые сервером NTP. После получения первого широковещательного сообщения клиент синхронизирует часы локального узла с использованием режима unicast mode. После этого клиент NTP переходит в режим ожидания прихода следующего широковещательного сообщения. Широковещательные сообщения NTP отправляются на широковещательный адрес сети каждые 64 секунды.
В режиме unicast mode клиент NTP client соединяется с указанный сервером NTP. В настройках клиента NTP адрес IP сервера NTP должен быть определён как адрес первого или второго сервера NTP. Клиент синхронизирует своё время с сервером NTP. Далее каждые 64–1024 секунды клиент запрашивает время с сервера NTP. Режим unicast mode является единственным, который использует параметры настроек "первый" и "второй" серверы NTP.
Для работы в этом режиме нужно указывать Broadcast addresses. Напомню что для сети 192.168.88.0/24 это 192.168.88.255.
Multicast mode
Работает аналогично режиму broadcast mode. При этом вместо широковещательных сообщений на адрес, например, 255.255.255.255 сообщения multicast принимаются с адреса 224.0.1.1. То есть, для доставки пакетов используются multicast-адреса сетей класса D адресного пространства IP-адресов. Для клиентов и серверов задается адрес multicast-группы, которую они используют для синхронизации времени. Это делает возможным синхронизацию групп машин, расположенных в различных подсетях, при условии, что соединяющие их маршрутизаторы поддерживают протокол IGMP и настроены на передачу группового трафика.
Manycast mode.
Функционирует как режим unicast mode только с неизвестными адресами IP серверов NTP. Для обнаружения сервера NTP клиент отправляет сообщение multicast на адрес, например, IP 239.192.1.1. Другими словами, используются адреса multicast-групп (сети класса D). Клиенты и серверы, использующие один и тот же адрес, формируют одну ассоциацию. Количество ассоциаций определяется количеством используемых multicast-адресов.Если сервер NTP настроен на то, чтобы "слушать" эти сообщения multicast (стоит галочка в поле Manycast), то он "отвечает" на такие сообщения.После получения клиентом ответа клиень переходит в режим unicast mode и синхронизируется с ответившим ему сервером NTP. Одновременно с этим клиент продолжает поиск большего (ударение на букву о) числа серверов NTP, периодически отправляя сообщения multicast каждые 64 секунды.Этот режим является нововведением 4-й версии протокола NTP. В manycast mode подразумевается поиск клиентом среди своих сетевых соседей manycast-серверов, получение от каждого из них образцов времени (с использованием криптографии) и на основании этих данных выбирается 3 «лучших» manycast-сервера, с которыми клиент будет производить синхронизацию. В случае выхода из строя одного из серверов клиент автоматически обновляет свой список.
Настройка Firewall
Если вы блокируете доступ из локальной сети к MikroTik вам необходимо открыть udp 123 порт в соответствующих цепочках: 
Раздача NTP сервера с помощью DHCP
 Всё довольно просто: 
На практике с локальных NTP предпочитают брать время преимущественно Linux машины.
5 Простые проверки [Zabbix Documentation 5.4]
 Ключ
▲
 Описание
 Возвращаемое значение
 Параметры
 Комментарии
icmpping[<цель>,<пакеты>,<интервал>,<размер>,<время ожидания>]
Доступность хоста через пинг по ICMP.
0 - ошибка при пинге по ICMP
1 - успешный пинг по ICMP
цель - IP хоста или DNS имя
пакеты - количество пакетов
интервал - время между успешными пакетами в миллисекундах
размер - размер пакета в байтах
время ожидания - время ожидания в миллисекундах
Пример:
⇒ icmpping[,4] → если по крайней мере один пакет из четырех вернется, элемент данных возвратит 1.
Смотрите также таблицу со значениями по умолчанию.
icmppingloss[<цель>,<пакеты>,<интервал>,<размер>,<время ожидания>]
Процентное отношение потерянных пакетов.
Число с плавающей точкой.
цель - IP хоста или DNS имя
пакеты - количество пакетов
интервал - время между успешными пакетами в миллисекундах
размер - размер пакета в байтах
время ожидания - время ожидания в миллисекундах
Смотрите также таблицу со значениями по умолчанию.
icmppingsec[<цель>,<пакеты>,<интервал>,<размер>,<время ожидания>,<режим>]
Время ответа на пинг по ICMP (в секундах).
Число с плавающей точкой
цель - IP хоста или DNS имя
пакеты - количество пакетов
интервал - время между успешными пакетами в миллисекундах
размер - размер пакета в байтах
время ожидания - время ожидания в миллисекундах
режим - один из min, max, avg (по умолчанию)
 Если хост недоступен (превышено время ожидания), элемент данных вернет 0.
Если элемент данных “icmppingsec” вернет значение меньше 0.0001 секунд, значение будет равно 0.0001 секунд.
Смотрите также таблицу со значениями по умолчанию.
net.tcp.service[сервис,<ip>,<порт>]
Проверка запущен ли сервис и отвечает ли на TCP подключения.
0 - сервис недоступен
1 - сервис работает
сервис - один из ssh, ntp, ldap, smtp, ftp, http, pop, nntp, imap, tcp, https, telnet (смотри детали)
ip - IP адрес или DNS имя (по умолчанию, используется IP/DNS узла сети)
порт - номер порта (по умолчанию для сервиса используется стандартный номер порта).
Пример:
⇒ net.tcp.service[ftp,,45] → можно использовать для проверки доступности FTP сервера на 45 порту TCP.
Обратите внимание, для сервиса tcp обязательно нужно указывать порт.
Эти проверки могут привести к дополнительным записям в системных лог файлах (обычно сессии SMTP и SSH журналируются).
Проверка шифрованных протоколов (таких как IMAP на 993 порту или POP на 995 порту) в настоящее время не поддерживается. Как решение, пожалуйста, для подобных проверок используйте net.tcp.service[tcp,<ip>,порт].
Сервисы https и telnet поддерживаются Zabbix начиная с версии 2.0.
net.tcp.service.perf[сервис,<ip>,<порт>]
Проверка производительности сервиса.
Число с плавающей точкой.
0.000000 - сервис недоступен
сек - количество секунд потребовавшихся для подключения к сервису
сервис - один из ssh, ntp, ldap, smtp, ftp, http, pop, nntp, imap, tcp, https, telnet (смотри детали)
ip - IP адрес или DNS имя (по умолчанию, используется IP/DNS узла сети)
порт - номер порта (по умолчанию для сервиса используется стандартный номер порта).
Пример ключа:
⇒ net.tcp.service.perf[ssh] → можно использовать для проверки скорости начального ответа от SSH сервера.
Обратите внимание, для сервиса tcp обязательно нужно указывать порт.
Проверка шифрованных протоколов (таких как IMAP на 993 порту или POP на 995 порту) в настоящее время не поддерживается. Как решение, пожалуйста, для подобных проверок используйте net.tcp.service.perf[tcp,<ip>,порт].
Сервисы https и telnet поддерживаются Zabbix начиная с версии 2.0.
Назывался tcp_perf до Zabbix 2.0.
net.udp.service[сервис,<ip>,<порт>]
Проверка запущен ли сервис и отвечает ли на UDP подключения.
0 - сервис недоступен
1 - сервис работает
сервис - возможные значения: ntp (смотри детали)
ip - IP адрес или DNS имя (по умолчанию, используется IP/DNS узла сети)
порт - номер порта (по умолчанию для сервиса используется стандартный номер порта).
Пример:
⇒ net.udp.service[ntp,,45] → можно использовать для тестирования доступности NTP сервиса на 45 порту UDP.
Этот элемент данных поддерживается начиная с Zabbix 3.0, но ntp сервис был доступен в net.tcp.service[] элементе данных и в предыдущих версиях.
net.udp.service.perf[service,<ip>,<port>]
Проверка производительности UDP сервиса.
Число с плавающей точкой.
0.000000 - сервис недоступен
секунды - количество секунд прошедшее на ожидания ответа от сервиса
сервис - возможные значения: ntp (смотри детали)
ip - IP адрес или DNS имя (по умолчанию, используется IP/DNS узла сети)
порт - номер порта (по умолчанию для сервиса используется стандартный номер порта).
Пример:
⇒ net.udp.service.perf[ntp] → можно использовать для тестирования времени ответа от NTP сервиса.
Этот элемент данных поддерживается начиная с Zabbix 3.0, но ntp сервис был доступен в net.tcp.service[] элементе данных и в предыдущих версиях.
Синхронизация точного времени. Стандарт IEEE 1588.
Синхронизация времени в промышленных сетях необходима для согласования работы устройств и приложений, осуществляющих обработку данных в режиме реального времени. Помимо этого, синхронизация требуется в системах мониторинга и управления с целью протоколирования возникающих событий и своевременного реагирования на них.
В зависимости от решаемых задач, могут потребоваться разные уровни точности синхронизации времени. Так одной из наиболее чувствительных к точности времени систем является система автоматизации на энергетических подстанциях. Современная система автоматизации подстанции описана в стандарте МЭК 61850, в котором указано, что точность синхронизации времени на шине процессов должна быть не хуже 1 мкс.
Существует несколько методов синхронизации времени.
1. Односторонний метод
Часы Master отправляют информацию о времени на часы Slave. Последние используют полученные данные, учитывая задержку на передачу информации, для синхронизации времени. Задержка может быть измерена или рассчитана. Данный метод может быть использован только в тех системах, где сеть передачи данных и путь от часов Master к часам Slave не меняются, в противном случае при синхронизации времени будет неверно учтена задержка. При использовании этого метода следует учесть, что в любой системе могут возникнуть какие-либо помехи и шумы, которые повлияют на время передачи информации от мастера, но, так как связь односторонняя, отследить дополнительные задержки невозможно.
2. Двусторонний метод
Данный метод использует двустороннее соединение между часами Master и Slave. Это необходимо, чтобы динамически определять задержку на передачу данных при синхронизации по сети. Master и Slave обмениваются сообщениями с метками времени, после чего рассчитывается задержка, которая учитывается при синхронизации времени на устройствах.
Помимо отличий в методах синхронизации, разделяют еще и типы сетевых инфраструктур.
 Выделенная и конвергентная сети
В выделенной сети для синхронизации времени используют выделенную линию передачи данных. В такой сети используют методы синхронизации времени 1PPS и IRIG-B.
В конвергентной сети синхронизация времени происходит по тем же каналам, по которым передается весь остальной трафик системы. Для подобных систем используют протоколы синхронизации времени NTP, SNTP и PTP.
Кроме того, в отдельную группу можно отнести системы синхронизации от орбитальных спутников – например, GPS/ГЛОНАС.

Точность
Метод синхронизации
Сеть
GPS
< 1 мкс
Односторонний
Беспроводная
1PPS
< 1 мкс
Односторонний
Отдельная проводная
IRIG-B
10 мкс – 1 мс
Односторонний
Отдельная проводная
NTP
0,5 - 100 мс
Двусторонний
Сеть Интернет
SNTP
1 – 50 мс
Двусторонний
Локальная сеть
PTP
< 1 мкс
Двусторонний
Локальная сеть
Технологии синхронизации времени
Рассмотрим, что представляет собой каждый из способов синхронизации времени.
GPS (Global Positioning System) – Глобальная система позиционирования. Синхронизация времени осуществляется во время определения местонахождения устройства, оснащенного GPS-приёмником. Для этого устройство ловит сигнал со спутников, установленных на околоземной орбите. Каждый из спутников имеет атомные часы, за счет чего система GPS обеспечивает хорошую точность. Минусом данного метода является необходимость в GPS-антенне, сигнал от которой может быть нестабильным.
1PPS (1 pulse per second) – Сигнал 1PPS не содержит метки времени. Master-устройство посылает 1 импульс в секунду по отдельной сети: оптоволоконной линии, витой паре или коаксиальному кабелю. Часы Slave используют этот импульс только для синхронизации начала каждой секунды. Устройства не могут с помощью 1PPS получить информацию по дате и времени, поэтому его чаще всего используют совместно с другими протоколами синхронизации, например NTP.
NTP (Network Time protocol) – Протокол сетевого времени широко распространен в сетях Ethernet и Интернет. Принцип работы NTP основан на многоуровневой системе с множеством источников времени.
IRIG-B (Inter Range Instrumentation Group) – С помощью данной технологии передается информация о дате и времени вместе с импульсным сигналом синхронизации. IRIG-B используют выделенную сеть для передачи информации. Сеть может быть построена на оптическом волокне, витой паре или коаксиальном кабеле.
Каждый уровень системы NTP называется слоем и содержит источники времени.
Слой 0 — Эталонные часы (например, атомные часы или часы GPS)
Слой 1 — Серверы времени, подключённые напрямую к эталонным часам. Часы этого слоя считаются лучшими источниками времени в системе
Слой 2 — Серверы времени, которые синхронизируются с часами слоя 1
Всего слоев может быть до 16 (часы 16 слоя считаются не синхронизированными). Устройства предыдущего слоя всегда выступают в качестве серверов времени для устройств более низкого слоя. Каждое устройство в такой иерархической системе может получать данные о времени с устройств своего слоя и предыдущего. Полученные данные сравниваются по определенному алгоритму и выбирается наиболее точное время. Подобная развернутая многоуровневая система также позволяет оптимизировать трафик и нагрузку на устройства в сети.
SNTP (Simple Network Time Protocol) – Простой протокол сетевого времени. Применяется в локальных сетях для некритичных ко времени приложений. Формат сообщений, которыми между собой обмениваются устройства в системах SNTP и NTP, идентичен, поэтому протоколы совместимы друг с другом. В отличии от NTP, у SNTP нет сложных алгоритмов сравнения и выбора наилучшего сервера времени, поэтому устройство может быть синхронизировано только с одним сервером времени, и, если данные на сервере ошибочные, то конечное устройство не узнает об этом.
Более подробно познакомимся с протоколом синхронизации точного времени - PTP.
Стандарт IEEE 1588 v2
Для систем, которым не хватает точности синхронизации, предоставляемой протоколами NTP/SNTP, был разработан стандарт IEEE 1588 v2. Данный стандарт описывает протокол точного времени - PTP (Precision Time protocol). PTP предназначен для использования в локальных сетях и гарантирует высокую точность синхронизации.
Протокол PTP может быть реализован на программном или аппаратном уровне устройства. Наиболее точной является реализация на аппаратном уровне. Точность достигается за счет проставления меток времени сообщений PTP на аппаратном уровне интерфейсов Ethernet.
В стандарте определены алгоритмы выбора главных часов, определения задержек и их компенсация, а также процесс обмена сообщениями.
Типы устройств в системе РТР:
Гроссмейстерские часы (Grandmaster) – основные часы, по которым синхронизируется время в системе
Ведущие часы (Master) – часы, которые выступают в качестве источников точного времени для конечных устройств
Ведомые часы (Slave)– конечные устройства, на которых необходимо осуществить синхронизацию времени по протоколу PTP
Граничные часы (Boundary Clock)– сетевое оборудование (коммутаторы), которое будет выступать в качестве ведомого устройства для гроссмейстерских часов, и источником точного времени для конечных устройств. При этом коммутаторы также должны поддерживать РТР
Прозрачные часы (Transparent Clock) – коммутатор, который только измеряет время прохождения сообщений синхронизации сквозь себя и предоставляет информацию устройствам, которые участвуют в процессе синхронизации времени
Выбор Гроссмейстера
В системе PTP может быть несколько источников точного времени, но активным может быть только один. Для выбора гроссмейстера у PTP есть специальный механизм - Best Master Clock Algorithm (BMCA), который гарантирует отказоустойчивость системы PTP. Как только предыдущий гроссмейстер не может выполнять свою роль (например, потеря связи по GPS, сбой в работе самого мастера или потеря связи с системой PTP), то следующие часы, претендующие на роль основного мастера по критериям BMCA, автоматически станут источником точного времени для конечных устройств. Для этого все ведущие часы системы постоянно находятся в режиме прослушивания сообщений, отправленных на широковещательный адрес PTP, и, в случае необходимости, присваивают себе роль гроссмейстера.
Критерии BMCA
Priority 1 Field – поле первого приоритета. Значения от 0 до 255, устанавливается пользователем. Мастер выбирается по наиболее низкому приоритету (обычно ведущим часам присваивается приоритет ниже 128, а 255 для ведомых устройств)
Clock Class — класс часов. Например, часы с GPS-приемником имеют лучший приоритет в сравнении с часами, выставленными вручную
Clock Accuracy – точность синхронизации.
Clock Variance – изменения часов (джиттер и отклонения, определяются сложным логарифмическим путем)
Source Port ID – идентификатор порта источника (обычно МАС-адрес)
Priority 2 Field – поле второго приоритета. Также устанавливается пользователем
Диаграмма состояний часов в системе
Механизмы обмена сообщениями в PTP
Основные типы сообщений PTP 
Announce – сообщения содержащие параметры для определения основного мастера системы по алгоритму BMCA
Sync — сообщения от ведущих часов, которые передают информацию о времени
Follow Up – отправляются ведущими часами сразу после отправки сообщения типа sync. Данные сообщения содержат метку времени отправки сообщения sync и корректирующее значение. Используются для корректировки значения времени.
Delay – сообщения, которыми обмениваются ведомые и ведущие устройства, для определения задержки распространения сообщений синхронизации по линиям связи между ними
PTP подразумевает обмен двусторонними сообщениями с метками времени. На основе полученных меток времени рассчитывается задержка.
PTP может рассчитывать задержку двумя методами:
1. Метод one step (одношаговый)
PTP подразумевает обмен двусторонними сообщениями с метками времени. На основе полученных меток времени рассчитывается задержка.
Метка времени t2 – это время получения сообщения ведомым устройством.
Данный режим работы позволяет уменьшить трафик PTP системы за счет отсутствия сообщений типа follow up.
PTP подразумевает обмен двусторонними сообщениями с метками времени. На основе полученных меток времени рассчитывается задержка.
2. Метод two step (двухшаговый)
Механизм работы такой же как одношаговый, но метка времени t1 отправляется вторым сообщением follow up сразу после сообщения синхронизации.
Режимы работы PTP
Есть два режима вычисления задержек в системе PTP: End-to-End и Peer-to-Peer. В одной системе лучше использовать одинаковый режим работы для более корректной синхронизации устройств.
1. End-to-End
В данном режиме сетевое оборудование (коммутаторы) работает в режиме прозрачных часов. Задержка измеряется мастером для всего пути от мастера до каждого конечного устройства в отдельности.
+
В топологии могут принимать участия коммутаторы без поддержки PTP.
—
Большая нагрузка на основного мастера
2. Peer-to-peer
Все коммутаторы должны поддерживать PTP. В этом случае коммутаторы заранее измеряют задержку каждого своего канала, в следствии чего при перестроении топологии перестроение PTP быстрое.
+
Быстрая адаптация PTP при перестроении топологии
Малая нагрузка на основного мастера
—
В топологии могут принимать участия только коммутаторы с поддержкой PTP
Power профиль PTP
В стандарте IEEE 1588 v2 описано очень много параметров для системы PTP. Чтобы было проще ориентироваться в них и понимать, какие именно настройки необходимы для той или иной системы, были созданы профили PTP.
Существует отдельный профиль, определяющий синхронизацию PTP для энергетических объектов. Данный профиль гарантирует точность синхронизации до 1 мкс в топологиях с радиусом не более 16 узлов от основного мастера точного времени.
Основные параметры профиля можно увидеть в таблице:

Power профиль PTP
Время синхронизации
1 мкс
Сеть
Только сеть 2 уровня модели OSI
Адресация
Multicast
Роли устройств
Все, кроме Граничных часов
Метод расчета задержки
Одношаговый или двухшаговый
Режим работы
Peer-to-Peer
Устройства в топологии
Только с поддержкой PTP
Использование профиля Power Profile на энергетических подстанциях гарантирует полное соответствие требованиям стандарта МЭК 61850 в разрезе синхронизации времени.
Многие управляемые коммутаторы Moxa поддерживают синхронизацию по протоколу PTP. Аппаратную реализацию PTP и возможность выбора Power профиля поддерживают коммутаторы серий PT-G503, PT-7728-PTP и PT-G7728/7828.
 Информация о брандмауэре службы времени в Интернете 
 Брандмауэр - это устройство, которое может защитить ваш компьютер, выборочно блокируя подключения из Интернета. Брандмауэр может быть построен с использованием оборудования, программного обеспечения или их комбинации, а некоторые операционные системы (например, Windows XP и Linux) содержат программное обеспечение брандмауэра как часть самой операционной системы.
 Есть ряд моментов, которые следует учитывать, если у вас есть какой-либо тип межсетевого экрана и вы планируете использовать его со службой времени в Интернете NIST.Вы должны немного понимать, как компьютеры обмениваются данными через Интернет, чтобы иметь возможность правильно настроить брандмауэр.
 Есть 4 параметра, которые определяют, как клиентская программа взаимодействует с удаленным сервером. Первый - это адрес сервера, который можно указать с помощью имени, например time-a.nist.gov, или ряда чисел, например 129.6.15.28. Обе эти спецификации эквивалентны, хотя система фактически использует числовую форму - имя преобразуется в числовую форму автоматически.В общем, имя более удобно использовать, но числовая форма требует меньше накладных расходов на обработку и, как правило, предпочтительнее, если вы собираетесь делать много запросов к одному и тому же серверу.
 Второй параметр - это протокол, который определяет формат сообщений, которыми обмениваются. Серверы NIST поддерживают два общих протокола: tcp, протокол управления передачей, и udp, протокол пользовательских дейтаграмм. Наконец, третий и четвертый параметры - это номера портов на клиенте и сервере.Номер порта сервера указывает, какая программа на сервере NIST будет фактически обрабатывать ваш запрос, а номер порта клиента указывает, какая программа в вашей системе будет обрабатывать ответ.
 Номер порта в вашей системе произвольный и обычно выбирается вашей системой случайным образом каждый раз, когда клиентская программа готовится сделать запрос на время. Следовательно, от запроса к запросу он может отличаться. Однако серверы времени NIST будут прослушивать и отвечать только на запросы, адресованные нескольким конкретным номерам портов и протоколам.Это следующие комбинации:
 udp порт 123, который используется протоколом сетевого времени и простым протоколом сетевого времени. Клиентское программное обеспечение NIST можно настроить на использование этого порта, но оно не используется по умолчанию.
 TCP-порт 13, который используется клиентским программным обеспечением NIST по умолчанию и другими программами, использующими «дневной» протокол.
 TCP-порт 37 и UDP-порт 37, которые используются DATE, RDATE, SDATE и другими программами, использующими протокол «time».
 Для успешного доступа к серверам времени NIST ваш брандмауэр должен разрешать исходящие соединения через удаленный порт и комбинацию протоколов, которую вы будете использовать. Номер порта в вашей системе, вероятно, будет варьироваться от одного запроса к другому, и вам, вероятно, придется разрешить сообщениям с любого номера порта в вашей системе проходить через брандмауэр, если они адресованы одному из конкретных портов в системе NIST, и разрешить сообщениям, адресованным любому порту вашей системы, проходить через брандмауэр, если они возвращаются с одного из этих конкретных портов службы времени.
 Обычно проще настроить брандмауэр, когда ваш клиент использует дневной формат на основе TCP, поскольку связь TCP неявно связывает ответ нашего сервера времени с запросом, который его запросил, и брандмауэр с меньшей вероятностью заблокирует ответ на запрос, исходящий из локальной системы. (Клиентское программное обеспечение NISTIME использует этот формат связи по умолчанию.) Однако это не всегда верно, и иногда проще использовать формат сетевого протокола времени (NTP) на основе UDP.Поскольку этот формат очень широко используется, многие брандмауэры по умолчанию передают сообщения в этом формате.
 Клиентское программное обеспечение NISTIME может использовать любой из этих форматов, и вам следует попробовать формат NTP, если брандмауэр не будет передавать сообщения на основе TCP, которые используются по умолчанию. Выбор между двумя форматами осуществляется с помощью File | Выберите меню «Сервер». Каждый сервер в списке можно настроить для запроса в любом формате. После того, как вы настроили серверы, вы должны сохранить конфигурацию с помощью File | Сохраните конфигурацию, чтобы вам не пришлось выбирать эти параметры при повторном запуске программы.
 Если эти соединения заблокированы, программа не получит ответа на запрос времени и обычно сообщит об ошибке. Кроме того, некоторые брандмауэры не связывают ответ сервера с запрошенным сообщением и рассматривают ответ как незапрошенную «атаку». Вы должны рассмотреть эту возможность, если вы видите много «атак», которые, похоже, исходят от одного из портов службы времени, перечисленных выше. Наконец, многие программы DATE, RDATE и SDATE плохо справляются с ошибками и могут установить время в вашей системе на странное значение (часто в 2036 году), если ответ заблокирован или искажен.По этой причине мы не рекомендуем ни одну из этих программ.
 По вопросам или дополнительной информации об Интернет-службе времени NIST обращайтесь к jlevine [at] boulder.nist.gov (Judah Levine).
 Устранение неполадок протокола сетевого времени (NTP) 
 В этом документе содержится информация о том, как устранить распространенные проблемы с протоколом сетевого времени (NTP).
 Требования 
 Cisco рекомендует хорошо понимать, как работает NTP, и хорошо разбираться в протоколе сетевого времени.
 Используемые компоненты 
 Этот документ не ограничивается конкретными версиями программного и аппаратного обеспечения.
 Условные обозначения 
 См. Раздел Условные обозначения технических советов Cisco для получения дополнительной информации об условных обозначениях в документе.
 Протокол сетевого времени
 (NTP) широко используется для синхронизации компьютера с серверами времени в Интернете или другими источниками, такими как радио- или спутниковые приемники или услуги телефонного модема. Обычно он обеспечивает точность менее миллисекунды в локальных сетях и до нескольких миллисекунд в глобальных сетях.Типичные конфигурации NTP используют несколько резервных серверов и различные сетевые пути для достижения высокой точности и надежности.
 NTP использует алгоритм Марзулло для синхронизации времени с текущей версией NTP. Он может поддерживать время в общедоступном Интернете с точностью до 10 миллисекунд и может работать даже лучше в локальных сетях. Серверы времени NTP работают с пакетом TCP / IP и используют порт 123 протокола дейтаграмм пользователя (UDP).
 Серверы
 NTP обычно представляют собой выделенные устройства NTP, которые используют единую временную привязку, с которой они могут синхронизировать сеть.Эта ссылка на время чаще всего является источником всемирного координированного времени (UTC). UTC - это глобальная шкала времени, распределяемая с помощью атомных часов через Интернет, по специальным длинноволновым радиопередачам или с помощью сети Глобальной системы позиционирования (GPS). Выделенные серверы NTP необходимы для обеспечения безопасности, защиты, точности, законности и контроля.
 Алгоритм NTP использует эту временную привязку, чтобы определить величину для увеличения или уменьшения системных или сетевых часов. NTP анализирует значения меток времени, частоту ошибок и ее стабильность.Сервер NTP поддерживает оценку качества как эталонных часов, так и самого себя.
 В этом разделе перечислены некоторые общие проблемы, с которыми можно столкнуться при использовании NTP, и даны решения для каждой из них.
 Невозможно синхронизировать NTP со службой времени на основе W32 
 Когда маршрутизаторы Cisco настроены на использование серверов NTP, размещенных в Active Directory, маршрутизаторы Cisco не получают никаких пакетов NTP от сервера NTP. Эта проблема возникает из-за того, что маршрутизаторы Cisco используют NTP, а домены Active Directory используют службу W32Time.W32Time использует простой протокол сетевого времени (SNTP), подмножество NTP, для синхронизации времени. SNTP и NTP используют один и тот же формат сетевых пакетов. Основное различие между SNTP и NTP заключается в том, что SNTP не предоставляет функций проверки ошибок и фильтрации, которые предоставляет NTP. Маршрутизатор и коммутаторы Cisco используют NTP и позволяют выполнять все функции проверки ошибок и фильтрации, предоставляемые NTP v3.
 Windows W32Time показывает, что это реализация SNTP внутри (скорее заявляющая себя NTP). Cisco IOS-NTP, который пытается синхронизироваться с W32Time, получает собственное значение корневой дисперсии, которое он отправляет в W32Time, и это оказывается дорогостоящим для синхронизации Cisco IOS-NTP.Поскольку значение корневой дисперсии Cisco IOS-NTP превышает 1000 мс, оно самосинхронизируется (процедура выбора часов). Поскольку маршрутизаторы на базе Cisco IOS выполняют полную RFC-реализацию NTP, они не синхронизируются с сервером SNTP. В этом случае вывод команды  show ntp association detail  показывает, что сервер помечен как  безумный, недопустимый . Значение  корневой дисперсии  превышает 1000 мс, что заставляет реализацию Cisco IOS NTP отклонять ассоциацию.Маршрутизаторы, работающие под управлением Cisco IOS, могут быть неспособны синхронизироваться с сервером NTP, если это система Windows, в которой работает служба W32Time. Если сервер не синхронизирован, маршрутизаторы не могут передавать и получать пакеты от сервера.
 Чтобы обойти эту проблему и синхронизировать маршрутизатор на базе Cisco IOS, используйте авторитетный сервер NTP в Интернете, устройство UNIX, которое запускает NTPD или GPS на определенных платформах. В качестве альтернативы вы можете отказаться от запуска службы W32Time в системе Windows.Вместо этого вы можете использовать NTP 4.x. Все версии Windows 2000 и более поздних версий могут служить NTP-сервером. Затем другие машины в сети могут использовать сервер NTP для синхронизации своего времени.
 Маршрутизаторы не могут синхронизироваться с общедоступными серверами времени 
 Это возможные причины, по которым маршрутизаторы не могут синхронизироваться с общедоступными серверами времени:
 Списки контроля доступа, которые не позволяют пакетам UDP-порта 123 проходить через
 Неправильная конфигурация в маршрутизаторах, такая как  clock timezone  и  clock summer-time  Команды отсутствуют на маршрутизаторах
 Общедоступный сервер времени не работает
 Программное обеспечение сервера NTP в NT или UNIX неправильно настроено
 Больше трафика на маршрутизаторе и больше трафика на пути к серверу
 Мастер NTP потерял синхронизацию, и маршрутизатор периодически теряет синхронизацию
 Высокая загрузка ЦП
 Большое смещение и более между сервером и маршрутизатором (используйте команду  show ntp association detail , чтобы проверить это)
 Ошибка: слишком высокий уровень слоев - слишком много косвенных обращений от датчика к главному серверу NTP 
 Это сообщение об ошибке появляется, когда датчик пытается синхронизироваться с сервером, который сообщает свой уровень как 15.Это связано с тем, что значение уровня сервера 15 делает значение слоя датчика 16, что является недопустимым. В результате датчик вместо этого отклоняет сервер и отображает слишком высокий уровень страты - слишком много косвенных обращений от датчика к сообщению об ошибке главного сервера NTP.
 NTP использует концепцию слоя  , чтобы описать, сколько NTP  прыгает на  от машины от авторитетного источника времени. Это сообщение об ошибке указывает на то, что уровень NTP, о котором сообщает сервер NTP, слишком высок.Уровень - это число от 1 до 15, которое указывает, насколько удален сервер от точных эталонных часов. Обычно системы, которые напрямую синхронизируются с атомными часами, сообщают о своем слое как о едином. Хост, который синхронизируется с одним слоем NTP-сервером, но также служит NTP-сервером для других хостов, сообщает этим хостам свой слой как два, причем каждый последующий уровень серверов имеет слой, который на один выше, чем его родительский.
 Если вы используете хост Linux в качестве сервера NTP, жестко запрограммируйте страту, о которой он сообщает, а не позволяйте ей вычислять страту автоматически.Если это система Linux или UNIX, сервер NTP настраивается файлом  /etc/ntp.conf , а команда  fudge  используется для жесткого кодирования страты. Сервер всегда сообщает своим клиентам значение страты, на единицу превышающее значение выдумки.
 Подключение к серверу NTP
 - IBM Watson Media 
 Серверы
 ECDN требуют подключения к серверу (-ам) NTP для синхронизации своих часов. Когда часы сервера ECDN расходятся более чем на 5 минут, операционная группа ECDN больше не имеет возможности удаленно входить в систему и помогать устранять неполадки, даже если установлен флажок «Удаленная помощь».
 При установке серверов ECDN вы можете использовать:
 Локальные серверы NTP, доступные в вашей организации, или
 общедоступных серверов NTP, например: 
  0.ubuntu.pool.ntp.org,
 1.ubuntu.pool.ntp.org, 2.ubuntu.pool.ntp.org .
 Если вы используете общедоступные серверы NTP, вам также необходимо обновить конфигурацию корпоративного брандмауэра, чтобы разрешить исходящий UDP-трафик на порт 123 в эти места назначения. Вот как вы можете подтвердить эти настройки.
 Войдите на сервер ECDN.Учетные данные по умолчанию описаны на странице «Поддержка и загрузки». В командной строке оболочки введите:
  ntpq -p 
 Когда порты брандмауэра открыты достаточно, чтобы разрешить трафик NTP, вывод будет выглядеть так:
 Обратите внимание, что значение столбца « refid » будет « .POOL. ».
  remote refid st t t при достижении опроса задержки смещения смещения джиттера
================================================== ============================
 0.ubuntu.pool.n .POOL. 16 п - 64 0 0,000 0,000 0,004
 1.ubuntu.pool.n .POOL. 16 п. - 64 0 0,000 0,000 0,004
 2.ubuntu.pool.n .POOL. 16 п - 64 0 0,000 0,000 0,004
 3.ubuntu.pool.n .POOL. 16 п. - 64 0 0,000 0,000 0,004
 ntp.ubuntu.com .POOL. 16 п - 64 0 0,000 0,000 0,004  
 Когда брандмауэр блокирует трафик NTP, вывод команды будет выглядеть так:
 Обратите внимание, значение столбца « refid » .В ЭТОМ.  ", что указывает на отсутствие подключения к общедоступному серверу NTP.
  remote refid st t t при достижении опроса задержки смещения смещения джиттера
================================================== ============================
 clock.sjc.he.ne .INIT. 16 ед - 1024 0 0,000 0,000 0,000
 turing.clpo.inf .INIT. 16 ед - 1024 0 0,000 0,000 0,000
 soft-sea-01.ser .INIT. 16 ед - 1024 0 0,000 0,000 0,000  
 Обратитесь к администратору локальной сети, чтобы обновить настройки брандмауэра или получить информацию о том, какие серверы NTP могут быть доступны в вашей организации.
 НЕ обновляйте настройки сервера NTP непосредственно на виртуальной машине сервера ECDN. Вместо этого перейдите на портал управления ECDN и перейдите на эту конкретную страницу «Сведения о сервере ECDN», а затем щелкните, чтобы обновить параметры сети. Когда вы сохраните настройки, новые значения будут автоматически распространяться на сервер ECDN. Таким образом, ваши настройки будут сохранены при обновлении сервера ECDN.
 SNTP: все, что вам нужно знать о простом протоколе сетевого времени 
 Простой протокол сетевого времени (SNTP) - это интернет-протокол (IP), используемый для синхронизации часов в компьютерных сетях.
 SNTP - это подмножество протокола сетевого времени (NTP).
 Последняя версия - SNTP v4.
 Он может легко синхронизироваться с полнофункциональными серверами NTP.
 Изначально разработано для небольших компьютеров и микроконтроллеров.
 Требует меньше памяти и вычислительной мощности, чем NTP.
 Используется в приложениях, где точная синхронизация часов не критична.
 Использует набор протоколов TCP / IP, порт 123 UDP.
 SNTP - это подмножество полнофункционального протокола сетевого времени (NTP).
 Сложные статистические алгоритмы были разработаны для NTP, чтобы повысить точность синхронизации часов и уменьшить дрейф часов. Однако алгоритмы потребляют значительный объем памяти и вычислительной мощности.
 Для многих приложений, особенно на небольших компьютерах, максимальная производительность NTP не требуется. По этой причине был разработан простой протокол сетевого времени (SNTP), чтобы обеспечить синхронизацию часов для менее мощных компьютеров, где сложность NTP не требуется.
 Набор протоколов SNTP 
 SNTP основан на наборе протоколов TCP / IP. Это протокол времени прикладного уровня, часть базового протокола сетевого времени. Наряду с NTP, SNTP обменивается данными с использованием протокола пользовательских дейтаграмм (UDP). По умолчанию используется порт 123 UDP.
 Распространенный недостаток новых установок SNTP заключается в том, что порт UDP должен быть оставлен открытым в любом брандмауэре, чтобы разрешить передачу данных. Если клиент не может синхронизироваться с сервером, убедитесь, что порт 123 UDP открыт в конфигурации брандмауэра.
 SNTP может работать в сетях IPv4 и IPv6 и определен в RFC 4330.
 Как работает SNTP 
 Протокол SNTP - это протокол клиент-сервер, основанный на обмене пакетами информации о времени.
 Обычно клиенты работают в одноадресном режиме. Через определенные промежутки времени, обычно примерно каждые 64 секунды, клиент SNTP отправляет запрос на сервер NTP, ссылаясь на его IP-адрес. Сервер обычно синхронизируется с аппаратными эталонными часами, такими как GPS.
 При получении ответа от сервера клиент может вычислить системное смещение времени между своими внутренними часами и часами сервера. Улучшенная синхронизация достигается за счет расчета задержек передачи пакетов туда и обратно.
 При необходимости SNTP можно настроить в широковещательном или многоадресном режимах. В этом случае сервер непрерывно передает пакеты временных меток через определенные промежутки времени. Клиенты постоянно прослушивают пакеты и при получении соответствующим образом корректируют свои системные часы.
 Протоколы NTP и SNTP полностью совместимы.
 Любой клиент SNTP может синхронизироваться с любым сервером NTP. Это в первую очередь потому, что обмениваемые пакеты информации идентичны.
 Различия между протоколами заключаются не в обмене информацией, а в том, что алгоритмы фактически делают с информацией для достижения синхронизации.
 Различия между NTP и SNTP 
 Основные различия между NTP и SNTP содержатся в приложении.
 NTP разработал сложные статистические алгоритмы с методами калибровки, нацеленные на фильтрацию небольших расхождений для достижения очень высокой степени синхронизации часов.
 Точная настройка времени выполняется путем настройки «тика» системных часов главного компьютера. NTP пытается без проблем вносить корректировки времени, искажая корректировки времени, чтобы избежать ступенчатых изменений.
 Избыточность реализуется путем непрерывного контроля нескольких эталонных значений времени. Сложные алгоритмы выбора определяют наиболее надежные и стабильные. Можно отслеживать несколько источников времени, включая сочетание аппаратных часов и сетевых источников времени, что способствует повышению надежности.
 В NTP также реализован ряд функций безопасности.Безопасная аутентификация клиент-сервер достигается за счет реализации криптографии с симметричным ключом. Это позволяет клиенту быть уверенным в происхождении полученных отметок времени, что предотвращает спуфинг.
 Напротив, SNTP использует гораздо более простой подход к синхронизации сетевых часов. Многие сложности алгоритмов NTP были удалены или упрощены.
 Многие клиенты SNTP не искажают время, а шагают по времени. Однако время шага может вызвать проблемы с упорядочением событий. Например, если время между генерацией двух транзакций сдвинуто назад, у них не будет правильно упорядоченного порядка.
 SNTP также не имеет возможности отслеживать и фильтровать множественные временные ссылки. Как правило, протокол можно настроить только для работы с одним источником времени. Это не лучший выбор, если реализовано несколько резервных источников времени.
 Для простоты многие клиенты SNTP не реализуют безопасные методы аутентификации, которые могут сделать системы уязвимыми для атак злоумышленников.
 Современные мощные компьютерные системы могут легко справиться с дополнительными накладными расходами, требуемыми NTP, без значительной потери производительности.Следовательно, NTP следует использовать для всех приложений синхронизации, если только большая площадь и требования к ресурсам не являются реальной проблемой.
 Где можно использовать SNTP вместо NTP 
 Простой протокол сетевого времени (SNTP) позволяет компьютерам с меньшей вычислительной мощностью реализовать синхронизацию часов.
 Обычно он используется небольшими сетевыми устройствами, такими как IP-камеры, цифровые видеорегистраторы, IP-телефоны, маршрутизаторы и потребительские устройства.
 Ряд операционных систем для небольших компьютеров и рабочих станций также используют протокол SNTP для простоты, а также из-за меньшей занимаемой площади и меньших требований к ресурсам.
 По сути, SNTP предлагает решение для синхронизации времени гораздо более низкого качества, чем NTP. Однако он идеален, когда требования точного времени, безопасности и надежности не являются приоритетными и важно иметь приложение, которое использует меньше ресурсов.
 NTP необходимо использовать там, где синхронизация часов имеет решающее значение, например, при обработке финансовых транзакций и управлении воздушным движением.
 Сводка 
 Simple Network Time Protocol был разработан для небольших компьютеров и микроконтроллеров с ограниченной памятью и вычислительной мощностью.
 Обеспечивает синхронизацию часов для приложений, не требующих точности полноценного NTP.
 NTP лучше подходит для синхронизации больших кластеров компьютеров, например корпоративных сетей. Надежность его алгоритмов калибровки помогает более крупным компьютерным системам надежно поддерживать точную синхронизацию времени.
 Требуется ли вашей организации точная синхронизация часов компьютеров и сетевой инфраструктуры? Если это так, ознакомьтесь с ассортиментом TimeTools, где используются серверы GPS и Multi-GNSS NTP.
  Об Эндрю Шинтоне 
  Эндрю Шинтон является соучредителем и управляющим директором TimeTools Limited. Имеет степень бакалавра (с отличием) в области компьютерных наук. Эндрю имеет более чем 20-летний опыт работы с системами GPS и сетевым протоколом времени (NTP) в индустрии времени и частоты.
 Что такое NTP? (Протокол сетевого времени) Упрощено в 5 точках 
 Введение 
 Операционные процессы, связанные с бизнесом / ИТ, в основном зависят от времени и происходят в их собственных сетях.Даже приложения, поддерживающие предприятия и процессы электронного бизнеса, зависят от времени, поскольку они осуществляют свои операции и функции через Интернет. Следовательно, время должно быть глобально синхронизированным фактором. Что такое NTP - это именно то, что делает сервер NTP, чтобы облегчить это требование.
  Что такое NTP-сервер? 
  Почему мне следует синхронизировать мою сеть? 
  Что важно при выборе сетевого сервера времени? 
  Что такое ACTS? 
  Что такое протокол сетевого времени? 
 1.
 Что такое NTP-сервер? 
 Что такое протокол NTP? «Сетевой сервер времени» - это общее описание программного обеспечения на сервере протокола сетевого времени NTP, которое работает на любой серверной / компьютерной платформе. Он применяется к сетевому устройству (подставка, стойка и т. Д.), Которое получает и использует время от внешнего источника для поддержания времени в пределах своих локальных внутренних часов, а затем предоставляет время своей подключенной сети. Это достигается с помощью NTP или протокола сетевого времени.
 2.
 Зачем мне синхронизировать мою сеть? 
 Приложения имеют метку времени от 1 миллисекунды до 1 секунды, и часто ее точность отражает цепочку событий или порядок их возникновения. В современном технологически развитом мире недопустима разница даже в одну миллисекунду. Метки времени в том, что такое NTP, следовательно, точно обеспечивают порядок событий и происшествий и, следовательно, необходимость синхронизации сервера NTP и его сети пула NTP.
 Все операции в сети, требующие высокой точности, обычно имеют временную метку порядка 1-10 миллисекунд.Используя синхронизацию NTP для синхронизации сервера NTP, можно использовать его общую встроенную базу времени для точной регистрации времени и, следовательно, избежать дорогостоящих проблем с простоями. Примером транзакции, требующей точной обработки времени на порту сервера NTP, является восстановление сети и диагностика неисправностей при разработке программного обеспечения.
 3. 
 Что важно при выборе сетевого сервера времени? 
 При выборе услуги или продукта необходимо понимать, что такое NTP-сервер, и изучать важные особенности сетевых серверов времени, позволяющие NTP иметь огромное значение.Их:
  Несколько портов NTP:  Использование сервера времени, который предоставляет несколько портов NTP, поддерживает синхронизацию современных и сетевых слоев NTP с использованием такого порта протокола NTP с сервером времени в безопасной среде, способствующей обновлению.
  Обновление атомных часов:  Серверы времени, использующие сигналы GPS для адреса сервера NTP, должны использовать внутренний атомный осциллятор Rubidium, который предотвращает потерю точности при заглушении или потере сигнала GPS, сохраняя при этом точное время на сервере времени клиента NTP.
  Резервные источники времени:  Сеть должна быть синхронизирована с выделенным сетевым сервером времени с источником опорных часов, чтобы избежать избыточности и гарантировать, что сеть отображает точное время.
  Перекрестная проверка времени:  Должна включать автоматическую проверку системных часов по часам сторонних производителей. Когда сервер синхронизации времени NTP выходит за установленные пределы, он изменяет время на лучшее эталонное значение, уведомляя пользователя через SNMP.
  Точность NTP и пропускная способность запросов:  В больших сетях NTP есть возможность синхронизировать несколько клиентов и обрабатывать совпадающую пиковую нагрузку запросов NTP.
  Простота использования:  Клавиатуры просты в настройке и использовании, а поддержка протокола SNMP обеспечивает быстрые уведомления, а интерфейс браузера обеспечивает интуитивно понятный удаленный доступ.
  Односпутниковая / оконная антенна Синхронизация:  В городских условиях, где доступ к крыше ограничен или где видимость спутников может ухудшаться или ограничиваться, предоставление автоматического режима синхронизации одного спутника на сервере NTP поддерживает точное время даже при прерывистые спутниковые сигналы и использование антенн, установленных на окне, для отслеживания спутников.
 4. 
 Что такое ACTS? 
 ACTS - это аббревиатура от Automated Computer Time Service. Услуга предоставляется Национальным институтом стандартов и технологий штата Колорадо, расположенным в Боулдере. Используя эту службу, серверы NTP могут выполнять связанные с телефоном передачи времени NIST / UTC через службу коммутируемого доступа. Серверы NTP S300 / S350 со встроенным модемом сервера времени являются примером службы ACTS в том, что такое NTP. Япония, многие европейские страны предоставляют такие услуги коммутируемого доступа.
 5. 
 Что такое протокол сетевого времени? 
 NTP расшифровывается как аббревиатура Network Time Protocol и является протоколом UDP для IP-сетей. Он используется для синхронизации часов клиентских машин с часами сетевого сервера времени. NTP, являющийся протоколом, требует отдельных серверных и клиентских приложений для его реализации.
  Как работает NTP:  Доктор Дэвид Миллс из Университета Делавэра по контракту с DARPA разработал бесплатный протокол с открытым исходным кодом.Программное обеспечение NTP работает в режиме сервера или клиента или в обоих режимах и использует программное обеспечение демона NTP. Как синхронизировать время с NTP-сервером? Цель NTP - использовать локальные часы сервера времени для относительного выявления и установки смещения локальных часов клиента. Клиент-сервер отправляет пакет запроса времени UDP на сервер NTP времени хоста, который получает отметку времени и затем возвращается клиенту. Затем клиент-сервер вычисляет смещение локальных часов на нем, используя временную метку сервера времени, чтобы внести коррективы.Надежный алгоритм NTP довольно сложен и имеет такие функции, как приоритезация нескольких серверов, самовосстановление и регулировка задержек в сети. Версия 1 была выпущена в 1985 году.
  Как проверить NTP-сервер в Linux ? В примере того, как NTP реализуется сервером, клиентское приложение, работающее на рабочих станциях Linux или Windows, использует пакеты NTP для обмена данными временных меток между сервером и клиентскими серверами времени. Таким образом, сервер времени устанавливает часы клиента на машине клиент-сервер очень точно по времени сервера времени в процессе, называемом синхронизацией.
  Какая польза от сервера NTP?  Обратите внимание, что цель NTP - ТОЛЬКО выявить смещение на клиентских часах, а НЕ доставить время. За время доставки отвечает ОС-операционная система. Прикладная программа NTP на клиент-сервере имеет сложные процессы для вычисления смещения во времени и последующей настройки часов на клиент-сервере. Аппаратная реализация протокола и компьютерных часов различаются на разных компьютерах. Большинство сторонних компьютеров используют серверы NTP со встроенными часами.Если система не поддерживает NTP, тогда потребуется загрузить и установить протокол NTP или NTP UNIX, который требует технических инструкций и лучше всего выполняется профессионалом.
 Точность NTP :  Точность зависит от количества переходов между сервером и клиентом, а также факторов задержки сети. В WAN или глобальных сетях это может составлять от 1 до 10 миллисекунд. В LAN-локальной сети оно варьируется от 0,5 до 2 миллисекунд. При использовании GPS точность внутренних часов составляет менее 50 наносекунд.С сигналами GPS, поступающими на NTP, точность отметки времени порта NTP составляет менее 14 микросекунд по сравнению с NTP.
 Различия между клиентами NTP и SNTP: что такое SNTP? SNTP - простой протокол сетевого времени, основанный на сервере SNTP RFC 1361/2030, который получает время с определенного предварительно установленного сервера времени машины. Его протокол нельзя изменить или перенастроить для получения отметок времени от другого сервера времени, когда основной сервер времени не работает. Следовательно, ее также называют короткой версией клиентского программного обеспечения NTP.Протокол сетевого времени NTP использует встроенные алгоритмы для настройки, получения и распределения сетевого времени с точностью 0,5–3 миллисекунды. Его алгоритм можно настроить для получения отметок времени от альтернативного сервера времени в случае, если исходный сервер не синхронизирован или выходит из строя.
  Что такое конфигурация NTP:  Если операционная система имеет встроенный NTP, можно включить возможность с помощью демона NTP в системе * nix. Для этого не нужно запускать компьютер NIX, а использовать клиентское программное обеспечение NTP для синхронизации сервера времени.Современные версии серверов времени, такие как Symmetricom, используют программное обеспечение NTP, которое предоставляет программное обеспечение Domain Time II для мониторинга, управления и синхронизации клиентов времени. Последнюю версию NTP можно загрузить по адресу http: /www.ntp.org/. Демон NTP для систем * nix можно загрузить по адресу http: /www.ntp.org.
 Заключение 
 В заключение, точность, безопасность, простота использования и надежность выделенного сетевого сервера времени очень важны для того, что такое NTP и сервер времени NTP.
 Если вы заинтересованы в карьере в области Data Science, наш 11-месячный очный курс  Postgraduate Certificate Diploma in Data Science  может очень помочь вам стать успешным профессионалом в области Data Science.
 ТАКЖЕ ПРОЧИТАЙТЕ 
 NTP: что такое протокол сетевого времени? 
 Хотя NTP считается во всем мире стандартом синхронизации времени, он не безупречен, особенно с точки зрения безопасности. Например, поскольку он основан на протоколе UDP без установления соединения, хакер может отправлять пакеты на сервер NTP с поддельными адресами отправителя посредством IP-спуфинга.В качестве адреса отправителя выбирается адрес целевой системы. Сервер отправляет свой ответ, который значительно превышает запрос, отправленный злоумышленником, обратно предполагаемому отправителю - целевой системе. Если злоумышленник теперь делает это в больших масштабах, отправляя большое количество таких управляемых запросов, он может перегрузить целевую систему - подробнее об этом можно узнать в следующей статье: DoS и DDoS.
 В результате несколько проектов были сосредоточены на разработке альтернативных, более безопасных решений, которые можно использовать вместо NTP:
  tlsdate:  tlsdate было закодировано Джейкобом Аппельбаумом в 2012 году и опубликовано на GitHub.Вместо UDP tlsdate использует протокол TCP для передачи данных. Служба шифрует установление соединения через TLS, чтобы предотвратить манипуляции с пакетами данных. Кроме того, tlsdate использует функции TLS «ServerHello» и «ClientHello» для синхронизации времени. Однако альтернатива NTP работает только с TLS 1.1 и 1.2.
  Ntimed:  Ntimed уделяет особое внимание безопасности и производительности. Для этого был оптимизирован программный код ntpd, на котором основан Ntimed.Программный пакет, состоящий из файлов клиента, сервера и мастер-файлов, доступен бесплатно в официальном каталоге Ntimed на GitHub.
  NTPsec:  NTPsec также является вариантом классической службы ntpd. Однако было сохранено более 175 000 строк кода по сравнению с оригиналом. Кроме того, группа разработчиков заменила ряд небезопасных строковых функций, таких как «strcpy», «sprint» или «gets», на безопасные аналоги. Эти и другие отличия можно подробно увидеть на официальном сайте проекта с открытым исходным кодом.
 Помимо программных альтернатив протокол точного времени (PTP) также предлагает альтернативу. В отличие от сетевого протокола времени, этот сетевой протокол для систем Linux уделяет особое внимание высокой точности синхронизации. Скорость синхронизации с PTP также снижается до наносекунды, что даже превосходит точность NTP. Кроме того, протокол требует минимальной мощности процессора и полосы пропускания сети, что делает его идеальным для простых и экономичных устройств.
 Использование NTP для настройки времени 
 NTP (сетевой протокол времени) - это стандартный протокол, который используются системными часами для обеспечения точности времени.Устройства, использующие NTP, стараются получить время как можно ближе к UTC (всемирное координированное время), стандартной шкале времени, используемой во всем мире. NTP использует UDP (протокол пользовательских дейтаграмм) на порту 123 для связи между клиентами и серверами.
 NTP основан на иерархии, в которой эталонные часы находятся наверху. Эталонные часы используют различные методы, такие как специальные приемники или спутниковые системы, для синхронизации своего времени с UTC. Серверы NTP на первом уровне иерархии синхронизируют свое время с эталонными часами и также обслуживают время для клиентов.Каждый уровень иерархии - это пласт; stratum-0 - это эталонные часы. Серверы Stratum-1 синхронизируют свои часы с эталонными часами. Серверы Stratum-2 синхронизируют свои часы с серверами stratum-1 и так далее. Номер страты указывает количество уровней между сервером NTP и эталонными часами. Более высокий номер страты может указывать на большее расхождение между NTP-сервером и эталонными часами. 
 Вы можете настроить устройство NIOS для работы в качестве клиента NTP, который синхронизирует свои часы с сервером NTP.Для получения дополнительной информации см.  Устройства NIOS как клиенты NTP . Клиенты NTP обычно используют информацию о времени как минимум из трех различных источников, чтобы гарантировать надежность и высокую степень точности. В Интернете есть несколько общедоступных серверов NTP, с которыми устройство NIOS может синхронизировать свои часы. Список этих серверов можно найти на  http://www.ntp.org . Когда NTP настроен, он прослушивает все интерфейсы, включая интерфейс обратной связи на устройстве NIOS.
 В сетке мастера сети и ее члены могут функционировать как клиенты NTP, которые синхронизируют свои часы с внешними серверами NTP. Они, в свою очередь, могут функционировать как серверы NTP для других устройств в сети. Для получения дополнительной информации см.  Устройства NIOS как серверы NTP . Обратите внимание, что когда Grid Master функционирует как NTP-сервер, он синхронизирует свои локальные часы со своими NTP-клиентами и не синхронизирует время с любым другим внешним NTP-сервером. Это позволяет развернуть несколько серверов NTP для обеспечения точного и надежного времени в сети.Чтобы настроить Grid Master и участников Grid в качестве клиентов NTP, необходимо сначала включить службу NTP и настроить внешние серверы NTP на уровне Grid. Затем вы можете настроить Grid Master и Grid members, чтобы переопределить NTP-серверы уровня Grid и использовать их собственные внешние NTP-серверы. Обратите внимание, что член Grid не будет работать как клиент NTP, если вы не включите службу NTP на уровне Grid. Участник сети синхронизирует свои часы с мастером сети, если вы не настроили его для использования внешних серверов NTP.
 В случае вставки секунды координации Infoblox Grid обрабатывает секунды координации в течение определенного периода времени вместо выполнения одноразовой корректировки. Другими словами, при использовании Grid в качестве NTP-сервера он следует стандартному процессу восстановления NTP, переключаясь на определенный период времени при обработке дополнительной секунды. Поэтому процесс поворота может вызвать проблемы синхронизации среди клиентов NTP. Состояние рассинхронизации обычно разрешается, когда все клиенты NTP догоняют сервер. 
  Рисунок 8.1  иллюстрирует, как устройства NIOS (Grid Master и члены Grid) в Grid функционируют как NTP-сервер или NTP-клиент, в зависимости от вашей конфигурации NTP.
 Примечание
 Служба NTP поддерживает сети как IPv4, так и IPv6.
 
  Рисунок   8.1   Infoblox   Устройства   as   NTP   Серверы 
 Чтобы предотвратить вмешательство злоумышленников в службы времени в вашей сети, вы можете аутентифицировать связь между общедоступным устройством и NIOS. Сервер NTP, а также между устройством NIOS и внешними клиентами NTP.Связь NTP внутри сети проходит через зашифрованный туннель VPN, поэтому вам не нужно включать аутентификацию между участниками сети. 
 NTP использует криптографию с симметричным ключом, где сервер и клиент используют один и тот же алгоритм и ключ для вычисления и проверки MAC (кода аутентификации сообщения). MAC - это цифровой отпечаток сообщения, который получатель использует для проверки подлинности сообщения. 
 Как показано на рисунке ниже, администратор клиента NTP должен сначала получить информацию о секретном ключе от администратора сервера NTP.Сервер и клиент должны иметь одинаковый идентификатор ключа и данные. Следовательно, когда вы настраиваете устройство NIOS в качестве клиента NTP и хотите использовать аутентификацию, вы должны получить ключевую информацию от администратора внешнего сервера NTP и ввести информацию на устройстве NIOS. Когда вы настраиваете устройство NIOS в качестве сервера NTP, вы должны создать ключ и безопасно отправить информацию о нем клиентам. Ключ состоит из следующего:
 Номер ключа: положительное целое число, идентифицирующее ключ.
 Тип ключа: Определяет формат ключа и алгоритм, используемый для вычисления MAC (кода аутентификации сообщения) сообщения.
 M: Ключ представляет собой строку ASCII из 1-31 символов с использованием MD5 (дайджест сообщения).
 S: ключ представляет собой 64-битное шестнадцатеричное число в формате DES (стандарт шифрования данных). 7 битов высокого порядка каждого октета образуют 56-битовый ключ, а бит младшего разряда каждого октета получает значение, так что октет поддерживает нечетную четность. Вы должны указать ведущие нули, чтобы ключ состоял ровно из 16 шестнадцатеричных цифр и сохранял нечетную четность.
 A: Ключ - это ключ DES, записанный в виде строки ASCII из 1–8 символов.
 N: ключ представляет собой 64-битное шестнадцатеричное число в формате NTP. Он аналогичен формату S, но биты в каждом октете повернуты на один бит вправо, поэтому бит четности находится в старшем разряде октета. Вы должны указать ведущие нули и нечетную четность.
 Строка ключа: ключевые данные, используемые для расчета MAC. Формат зависит от выбранного вами типа ключа.
 Когда клиент NTP инициирует запрос служб времени к серверу NTP, он создает MAC, используя согласованный алгоритм для сжатия сообщения, а затем шифрует сжатое сообщение (которое также называется дайджестом сообщения) с секретом. ключ.Клиент добавляет MAC к сообщению, которое он отправляет на сервер NTP. Когда NTP-сервер получает сообщение от клиента, он выполняет ту же процедуру с сообщением - он сжимает полученное сообщение, шифрует его секретным ключом и генерирует MAC. Затем он сравнивает созданный MAC с полученным MAC. Если они совпадают, сервер продолжает обрабатывать сообщение и отвечать на него. Если MAC-адреса не совпадают, получатель отбрасывает сообщение.
 В следующей таблице показано поведение клиентского сервера NTP в различных сценариях:
 Сценарий
 Поведение
 Нет аутентификации как на клиенте NTP, так и на сервере
 Клиент NTP будет синхронизироваться с клиентом NTP. сервер
 Аутентификация на сервере NTP, без аутентификации на клиенте NTP
 Клиент NTP будет синхронизироваться с сервером
 Аутентификация как на сервере NTP, так и на клиенте
 Клиент NTP будет синхронизироваться с сервером
 Нет аутентификации на сервере NTP, аутентификация на клиенте
 Клиент NTP не синхронизируется с сервером
  NTP   Клиент   Администратор   Получение   Секрет   Ключ   от   NTP   S erver   Administrator 
 Вы можете настроить независимое устройство NIOS, Grid Master или любой член Grid в Grid в качестве клиента NTP, который синхронизирует свои системные часы с внешним сервером NTP.
 Примечание
 Вы можете настроить устройство NIOS как NTP-клиент в сетевой среде IPv4, IPv6 или двойном режиме (IPv4 и IPv6).
 Когда вы разрешаете устройству NIOS функционировать в качестве клиента NTP, вы должны указать по крайней мере один сервер NTP, с которым устройство может синхронизировать свои часы. Infoblox рекомендует указать несколько серверов NTP, которые синхронизируют свое время с разными эталонными часами и имеют разные сетевые пути. Это увеличивает стабильность и снижает риск отказа сервера.Список общедоступных серверов NTP можно найти на  www.ntp.org . 
 Когда вы указываете несколько серверов NTP, демон NTP на устройстве определяет лучший источник времени, вычисляя время приема-передачи, сетевую задержку и другие факторы, влияющие на точность времени. NTP периодически опрашивает серверы и регулирует время на устройстве, пока оно не будет соответствовать лучшему источнику времени. Если разница между устройством и сервером составляет менее пяти минут, устройство постепенно корректирует время до тех пор, пока время часов не совпадет с показателем NTP-сервера.Если разница во времени составляет более пяти минут, устройство немедленно синхронизирует свое время, чтобы оно соответствовало времени сервера NTP. 
 Чтобы защитить связь между устройством NIOS и сервером NTP, вы можете аутентифицировать обмен данными между устройством и сервером NTP. При настройке аутентификации необходимо получить информацию о ключе от администратора сервера NTP и ввести ключ на устройстве. Для получения дополнительной информации см.  Аутентификация NTP . 
 В Grid вы можете настроить Grid Master и Grid members для синхронизации их часов с внешними NTP-серверами.Когда вы включаете службу NTP в Grid, Grid Master автоматически функционирует как NTP-сервер для участников Grid. Участник сети может синхронизировать свое время с мастером сети, внешним сервером NTP или другим участником сети. Когда участники Grid синхронизируют свое время с Grid Master, Grid Master и его участники отправляют сообщения NTP через зашифрованный VPN-туннель, как показано на следующем рисунке. Когда член Grid синхронизирует свое время с другим членом Grid, сообщения NTP не отправляются через VPN-туннель.
 Примечание
 Участник сети не может выступать в качестве сервера NTP для мастера сети.
 
  Grid   Master   as   NTP   Client 
 В сети Grid Master и ее участники могут синхронизировать свои часы с внешними серверами NTP. Затем они пересылают время другим устройствам в сети. Точно так же в независимой паре HA активный узел напрямую связывается с внешним сервером NTP. Затем пассивный узел синхронизирует свои часы с активным узлом.
 В сети необходимо сначала включить службу NTP и настроить внешние серверы NTP на уровне сети, прежде чем настраивать мастер сети и ее члены в качестве клиентов NTP. 
 Чтобы настроить Grid Master в качестве клиента NTP, выполните следующие задачи:
 Если вы хотите включить аутентификацию между участниками Grid и серверами NTP, вы должны указать ключи аутентификации перед включением службы NTP. Вы можете указать ключи аутентификации на уровне сетки и участников. Для получения дополнительной информации см.  Добавление ключей аутентификации NTP.
 Включите службу NTP в сети и укажите один или несколько внешних серверов NTP. Для получения дополнительной информации см.  Синхронизация сети с внешними серверами NTP .
 
  Добавление   NTP   Аутентификация   Ключи  
 Чтобы включить аутентификацию между устройством и серверами NTP, добавьте ключи аутентификации перед включением службы NTP в сети. Вы можете указать ключи аутентификации на уровне сетки и участников.
 Чтобы добавить ключи аутентификации NTP:
  Grid:  На вкладке  Grid  выберите вкладку  Grid   Manager , разверните панель инструментов и щелкните  NTP  ->  NTP   Grid   Config  Config . 
  Элемент:  На вкладке  Grid  выберите вкладку  Grid   Manager  ->  Members  tab ->  Grid_member  check box. Разверните панель инструментов и щелкните  NTP  ->  NTP   Member   Config .
 Чтобы переопределить унаследованное свойство, щелкните  Переопределить  рядом с ним и заполните соответствующие поля.
 Щелкните значок «Добавить» в разделе «Ключи NTP» и введите следующую информацию.
  Ключ   Число:  Положительное целое число, идентифицирующее ключ.
  Тип:  Определяет формат ключа и алгоритм, используемый для вычисления MAC (кода аутентификации сообщения) сообщения.
  MD5   в формате   ASCII     (M):  Ключ представляет собой строку ASCII из 1-31 символов с использованием MD5 (дайджест сообщения).
  DES   в формате   шестнадцатеричном формате     (S):  Ключ представляет собой 64-битное шестнадцатеричное число в формате DES (стандарт шифрования данных). 7 битов высокого порядка каждого октета образуют 56-битовый ключ, а бит младшего разряда каждого октета получает значение, так что октет поддерживает нечетную четность. Вы должны указать ведущие нули, чтобы ключ состоял ровно из 16 шестнадцатеричных цифр и сохранял нечетную четность.
  DES   в формате   ASCII     (A):  Ключ представляет собой ключ DES, записанный в виде строки ASCII из 1–8 символов.
  DES   в формате   NTP     (N):  Ключ представляет собой 64-битное шестнадцатеричное число в формате NTP. Он аналогичен формату S, но биты в каждом октете повернуты на один бит вправо, поэтому бит четности находится в старшем разряде октета. Вы должны указать ведущие нули и нечетную четность.
  Строка:  Ключевые данные, используемые для расчета MAC. Формат зависит от выбранного вами типа ключа.
 Нажмите  Сохранить , чтобы сохранить запись и оставить редактор открытым, чтобы вы могли разрешить Grid синхронизировать свое время с внешними серверами NTP.
 Обратите внимание, что если вы вводите новый ключ, устройство проверяет, существует ли этот ключ в списке ключей. Если ключ существует, но тип ключа или строка ключа не совпадают, устройство NIOS отправляет сообщение об ошибке. 
 После ввода ключа аутентификации его можно изменить или удалить. Обратите внимание, что вы не можете удалить ключ, на который ссылается сервер NTP.Вы должны сначала удалить все серверы NTP, которые ссылаются на этот ключ, а затем удалить ключ.
 Синхронизация сети с внешними серверами NTP 
 Чтобы включить синхронизацию времени сети с внешними серверами NTP:
 На вкладке  Grid  выберите вкладку  Grid   Manager , разверните панель инструментов и нажмите  NTP  ->  NTP   Сетка   Конфигурация .
 На вкладке  General  в редакторе  Grid   NTP   Properties  выберите  Synchronize   the   Grid   with   these   External   NTP  .
 Щелкните значок Добавить, чтобы добавить внешние серверы NTP, и введите следующую информацию в диалоговом окне  Добавить   NTP   Сервер :
  NTP   Сервер   (FQDN   или   IP   адрес ):  Введите IP-адрес или разрешаемое имя хоста NTP-сервера. Записи могут быть адресами IPv4 или IPv6. Вы можете просмотреть список общедоступных серверов NTP на ntp.isc.org. Чтобы проверить, может ли DNS-сервер разрешить имя хоста NTP-сервера, нажмите  Разрешить   Имя .У вас должен быть настроен преобразователь имен DNS. Для получения дополнительной информации см.  Включение разрешения DNS .
  Включить   Аутентификация:  Выберите эту опцию, чтобы включить аутентификацию связи NTP между внешним сервером NTP и устройством NIOS (главным устройством сети или членом сети в сети, независимым устройством NIOS или активным узлом в сети). независимая пара HA).
 Примечание
 Чтобы предотвратить вмешательство злоумышленников в службы времени в вашей сети, вы можете аутентифицировать обмен данными между участником Grid и внешним сервером NTP, а также между участником Grid и внешними клиентами NTP.Связь NTP внутри сети проходит через зашифрованный туннель VPN, поэтому вам не нужно включать аутентификацию между мастером сети и участниками сети.
  Аутентификация   Ключ:  Выберите ключ, который вы ранее ввели, из раскрывающегося списка.
 Нажмите  Добавить , чтобы добавить сервер NTP в список, или  Отмена , чтобы отменить операцию. В таблице вы можете настроить некоторые из следующих параметров:
  Предпочтительный : выберите этот параметр, чтобы отметить внешний сервер NTP в качестве предпочтительного сервера NTP.Вы можете выбрать только один сервер в качестве предпочтительного сервера NTP. NIOS использует ответы от этого предпочтительного сервера вместо ответов от других внешних серверов NTP. Ответ предпочтительного сервера будет отклонен, если он значительно отличается от ответов других серверов. Infoblox рекомендует выбрать в качестве предпочтительного сервера NTP-сервер, который известен своей высокой точностью, например, со специальным оборудованием для мониторинга времени. Обратите внимание, что этот параметр доступен только в том случае, если вы установили флажок  Синхронизировать   сетку     с   этими   Внешними   NTP   Серверами .
  Сервер : отображает полное доменное имя или IP-адрес добавленного вами NTP-сервера.
  Аутентификация : при включении аутентификации в этом столбце отображается  Да . В противном случае отображается  № .
  Ключ   Число : отображает выбранный вами ключ аутентификации.
  BURST : Установите этот флажок, чтобы настроить клиент NTP для отправки пакета из восьми пакетов, если внешний сервер NTP доступен и доступен действительный источник синхронизации.Клиент NTP передает каждый пакет с регулярным интервалом в две секунды. После добавления сервера NTP и сохранения конфигурации устройство включит этот параметр по умолчанию. Когда вы снимаете этот флажок, клиент отправляет один пакет на сервер только один раз.
  IBURST : Установите этот флажок, чтобы настроить клиент NTP для отправки пакета из восьми пакетов, если внешний сервер NTP недоступен, когда клиент отправляет первый пакет на сервер. Клиент NTP передает каждый пакет с регулярным интервалом в две секунды.После добавления сервера NTP и сохранения конфигурации устройство включит этот параметр по умолчанию. Когда вы снимаете этот флажок, клиент отправляет один пакет на сервер только один раз. 
 Для получения дополнительной информации о добавлении ключей аутентификации NTP см.  Добавление ключей аутентификации NTP. 
 Сохраните конфигурацию и нажмите  Перезагрузить , если он отображается вверху экрана.
 После настройки члена сети на использование внешнего сервера NTP убедитесь, что служба NTP включена на уровне сети.В противном случае член Grid не будет работать как клиент NTP. Для получения дополнительной информации см.  Синхронизация сети с внешними серверами NTP . 
 Чтобы настроить элементы сети для синхронизации своего времени с внешними серверами NTP:
 На вкладке  Grid  выберите вкладку  Grid   Manager  tab ->  Members  tab ->  Grid_member  check box.
 Разверните панель инструментов и щелкните  NTP  ->  NTP   Member   Config .
 На вкладке  General  редактора  Member   NTP   Properties  выполните следующие действия:
  Включите     NTP   Server   на   this   Member: установите этот флажок, чтобы настроить Grid Master или участника Grid в качестве NTP-сервера. Если вы настроили на устройстве произвольную передачу DNS, она может отвечать на запросы NTP через произвольный IP-адрес.
  Synchronize   this   Member   only   with   the   Grid   Master : Установите этот флажок, чтобы разрешить этому элементу сетки синхронизировать свое время с мастером сетки.Это значение по умолчанию.
  Синхронизировать   этот   Участник   с   другими   NTP   Серверы : Установите этот флажок, чтобы разрешить этому участнику сети использовать внешние серверы NTP. Когда вы устанавливаете этот флажок, вы должны ввести как минимум один внешний сервер NTP для участника.
  Exclude   the   Grid   Master   as   an   NTP   Server : Установите этот флажок, если вы хотите исключить Grid Master из одного из источников времени.По умолчанию устройство автоматически настраивает Grid Master в качестве резервного сервера NTP для члена Grid. Когда участник не может связаться ни с одним из настроенных серверов NTP, он использует Grid Master в качестве сервера NTP. Устройство не отображает Grid Master в списке внешних серверов NTP. Для мастера сетки этот флажок не имеет значения.
  Внешний   NTP   Серверы : щелкните  Переопределить , а затем щелкните значок  Добавить . В диалоговом окне  Add   NTP   Server  введите следующую информацию:
  NTP   Server   (FQDN   или   IP   Address) : введите IP-адрес или разрешаемый имя хоста NTP-сервера.Вы можете просмотреть список общедоступных серверов NTP на ntp.isc.org. Чтобы проверить, может ли DNS-сервер разрешить имя хоста NTP-сервера, нажмите  Разрешить   Имя . У вас должен быть настроен преобразователь имен DNS.
  Включить   Аутентификация : Установите этот флажок, чтобы включить аутентификацию NTP-коммуникаций между внешним сервером NTP и устройством NIOS (главным или членом сети в сети, независимым устройством NIOS или активным узлом в сети). независимая пара HA).
 Примечание
 Чтобы предотвратить вмешательство злоумышленников в службы времени в вашей сети, вы можете аутентифицировать обмен данными между участником Grid и внешним сервером NTP, а также между участником Grid и внешними клиентами NTP. Связь NTP внутри сети проходит через зашифрованный туннель VPN, поэтому вам не нужно включать аутентификацию между мастером сети и участниками сети.
  Аутентификация   Ключ : выберите ключ, который вы ранее ввели, из раскрывающегося списка.Обратите внимание, что вы должны ввести ключи аутентификации на уровне сети, когда вы настраиваете Grid Master или член Grid для использования внешних серверов NTP.
 Нажмите  Добавить , чтобы добавить сервер NTP в список, или  Отмена , чтобы отменить операцию. В таблице щелкните  Переопределить  в таблице, чтобы отменить настраиваемые параметры. Чтобы унаследовать те же свойства, что и у сетки, нажмите  Наследовать .
  Предпочтительный : Выберите этот параметр, чтобы отметить внешний сервер NTP как предпочтительный сервер NTP.Вы можете выбрать только один сервер в качестве предпочтительного сервера NTP. NIOS использует ответы от этого предпочтительного сервера вместо ответов от других внешних серверов NTP. Ответ предпочтительного сервера будет отклонен, если он значительно отличается от ответов других серверов. Infoblox рекомендует выбрать в качестве предпочтительного сервера NTP-сервер, который известен своей высокой точностью, например, со специальным оборудованием для мониторинга времени. Обратите внимание, что этот параметр доступен, только если вы установили флажок  Синхронизировать   этот   Член   с   другими   NTP   Серверами .
  Сервер : отображает полное доменное имя или IP-адрес добавленного вами NTP-сервера.
  Аутентификация : при включении аутентификации в этом столбце отображается  Да . В противном случае отображается  № .
  Ключ   Число : отображает выбранный вами ключ аутентификации.
  BURST : Установите этот флажок, чтобы настроить клиент NTP для отправки пакета из восьми пакетов, если внешний сервер NTP доступен и доступен действительный источник синхронизации.Клиент NTP передает каждый пакет с регулярным интервалом в две секунды. После добавления сервера NTP и сохранения конфигурации устройство включит этот параметр по умолчанию. Когда вы снимаете этот флажок, клиент отправляет один пакет на сервер только один раз.
  IBURST : Установите этот флажок, чтобы настроить клиент NTP для отправки пакета из восьми пакетов, если внешний сервер NTP недоступен, когда клиент отправляет первый пакет на сервер. Клиент NTP передает каждый пакет с регулярным интервалом в две секунды.После добавления сервера NTP и сохранения конфигурации устройство включит этот параметр по умолчанию. Когда вы снимаете этот флажок, клиент отправляет один пакет на сервер только один раз.
 Примечание
 Члены NTP наследуют свойства NTP от сети. Щелкните  Override  в мастере  Member   NTP   Properties , чтобы переопределить настраиваемые параметры. Чтобы унаследовать те же свойства, что и у сетки, нажмите  Наследовать . 
 Для получения дополнительной информации о добавлении ключей аутентификации NTP см.  Добавление ключей аутентификации NTP . 
 Сохраните конфигурацию и нажмите  Перезапустить , если он отображается вверху экрана.
 Управление внешними серверами NTP 
 Вы можете указать несколько серверов NTP для аварийного переключения. Устройство NIOS пытается подключиться к серверам NTP в том порядке, в котором они перечислены. Член Grid использует Grid Master в качестве NTP-сервера, когда он не может связаться ни с одним из своих внешних NTP-серверов. 
 Вы можете изменить порядок в списке, выбрав сервер NTP и перетащив его на новое место, или щелкнув стрелки вверх и вниз.Вы можете добавлять и удалять серверы, а также изменять их информацию.
 После того, как вы включите NTP в сети, члены сети, включая мастер сети, могут работать как серверы NTP для клиентов в различных сегментах сети. Точно так же после того, как вы включите NTP на независимом устройстве или паре HA, и оно синхронизирует свое время с сервером NTP, вы также можете настроить его для работы в качестве сервера NTP. Когда вы настраиваете произвольную адресацию DNS на элементе Grid и используете его в качестве сервера NTP, этот член может отвечать на запросы NTP от других клиентов NTP через произвольный IP-адрес.
  Grid   Участники   as   NTP   Серверы 
 Чтобы настроить устройство NIOS в качестве сервера NTP, выполните следующие задачи:
 Включите устройство в качестве сервера NTP.
 Включите аутентификацию между устройством и его клиентами NTP.
 При необходимости укажите, какие клиенты могут получить доступ к службе NTP устройства.
 При необходимости укажите, какие клиенты могут использовать ntpq для запроса устройства.
 Вы можете сконфигурировать член Grid, включая Grid Master, или независимое устройство или пару HA для работы в качестве NTP-сервера. Когда вы разрешаете устройству NIOS функционировать как сервер NTP, вы можете включить аутентификацию между устройством NIOS, функционирующим как сервер NTP, и его клиентами NTP. При включении аутентификации необходимо указать ключи, которые устройство и его клиенты должны использовать для аутентификации. В сетке вы можете ввести ключи аутентификации NTP на уровне сетки, чтобы все участники могли использовать их для аутентификации своих клиентов.Вы также можете 
 ввести ключи на уровне элемента, если вы хотите, чтобы этот член использовал ключи, отличные от тех, которые установлены на уровне сетки. После ввода ключей вы можете загрузить файл ключа и распространить его среди клиентов NTP. 
 На члене высокой доступности служба NTP работает на активном узле. При отказе HA служба NTP запускается автоматически после того, как пассивный узел становится активным, и трафик NTP использует порт HA на одном из узлов из пары HA вместо порта LAN1.Вы можете получить сообщение об ошибке, указывающее, что NTP не синхронизирован. Во время другого аварийного переключения HA текущий пассивный узел снова становится активным, и трафик NTP использует порт LAN1, а NTP снова синхронизируется. Для получения дополнительной информации см.  About   HA   Pairs . 
 Чтобы включить устройство в качестве сервера NTP и аутентифицировать трафик NTP между устройством NIOS и клиентом NTP, выполните следующие задачи:
 Включение устройства в качестве сервера NTP 
 Чтобы включить устройство в качестве сервера NTP и добавить ключи аутентификации :
 На вкладке  Grid  выберите вкладку  Grid   Manager  -> вкладка  Members  -> флажок  Grid_member .
 Разверните панель инструментов и щелкните  NTP  ->  NTP   Member   Config .
 На вкладке  General  редактора  Member   NTP   Properties  выполните следующие действия:
  Включите     NTP   Сервер   на   этот   Элемент   Выберите   Member этот параметр для настройки мастера сети или члена сети в качестве сервера NTP. Если вы настроили на устройстве произвольную передачу DNS, она может отвечать на запросы NTP через произвольный IP-адрес.
 Щелкните  Override  в разделе NTP Keys, чтобы ввести ключи аутентификации NTP на уровне участника. Член использует эти ключи, выступая в качестве сервера NTP и аутентифицируя запросы от клиентов NTP. Снимите флажок, чтобы использовать ключи проверки подлинности на уровне сетки.
 Щелкните  Добавить  в разделе «Ключи NTP». Для получения дополнительной информации см.  Добавление ключей аутентификации NTP .
 Сохраните конфигурацию и нажмите  Перезагрузить , если он отображается вверху экрана.
 После ввода ключей аутентификации вы можете загрузить файл ключа (обычно называемый ntp.keys) и передать его клиентам NTP следующим образом:
  Сетка:  На вкладке  Сетка  выберите Сетка    Диспетчер  таб. 
  Элемент:  На вкладке  Grid  выберите вкладку  Grid   Manager  ->  Members  tab ->  Grid_member  check box.
 Разверните панель инструментов и щелкните  NTP  ->  Загрузить   NTP   Ключи .
 В диалоговом окне  Открытие   ntp.keys  сохраните файл и нажмите  ОК .
 Передайте это клиентам NTP, используя безопасный транспорт.
 Определение управления доступом NTP 
 Список управления доступом NTP указывает, какие клиенты могут использовать устройство NIOS в качестве сервера NTP. Если вы не настраиваете управление доступом, тогда устройство NIOS разрешает доступ всем клиентам. Вы можете настроить контроль доступа на уровне сети NTP и переопределить его на уровне участника.
 Кроме того, устройство NIOS может принимать запросы от клиентов, используя ntpq, стандартную служебную программу, используемую для запроса серверов NTP об их состоянии и рабочих параметрах. Вы можете указать, от каких клиентов устройству NIOS разрешено принимать запросы ntpq. По умолчанию устройство не принимает запросы ntpq от любого клиента. 
 Вы можете использовать существующий именованный ACL (список управления доступом) или несколько ACE (записи управления доступом), чтобы контролировать, какие клиенты могут использовать устройство NIOS в качестве сервера NTP, а также тех клиентов, от которых устройство может принимать запросы с помощью ntpq.Дополнительные сведения об управлении доступом см. В разделе  Настройка управления доступом .
 Чтобы указать, какие клиенты могут получить доступ к службе NTP устройства NIOS и от каких клиентов устройство NIOS может принимать запросы ntpq, а также для включения или отключения KoD, выполните следующие действия:
  Grid:  From the  Grid  выберите вкладку  Grid   Manager , разверните панель инструментов и щелкните  NTP  ->  NTP   Grid   Config .
  Элемент:  На вкладке  Grid  выберите вкладку  Grid   Manager  ->  Members  tab ->  Grid_member  check box. Разверните панель инструментов и щелкните  NTP  ->  NTP   Member   Config . 
 Чтобы переопределить унаследованное свойство, щелкните  Переопределить  рядом с ним и заполните соответствующие поля.
 На вкладке  Access   Control  таблицы  Grid  или  Member   NTP   Properties Редактор  выберите один из следующих вариантов, чтобы настроить контроль доступа NTP:
  Нет : Выберите это, если вы делаете не хочу настраивать контроль доступа для службы NTP.Когда вы выбираете  Нет , устройство разрешает всем клиентам доступ к службе NTP. Выбрано по умолчанию.
  Использовать   Именованный   ACL   для   Время  только :  Выберите это и щелкните  Выберите   Именованный   ACL , чтобы выбрать именованный ACL, который содержит только IPv4-адреса и сети. Запросы NTP не поддерживают ACE на основе ключа TSIG. При выборе этого параметра устройство позволяет клиентам, имеющим разрешение  Разрешить  в названном ACL, использовать его службу NTP.Запросы NTP от указанных здесь именованных записей ACL отклоняются. Вы можете нажать  Очистить , чтобы удалить выбранный именованный ACL, и устройство будет принимать запросы ntpq от этих клиентов NTP.
  Использовать   Именованный   ACL   для   Время   +   NTP   Элемент управления   (NTPQ):  Выберите это и щелкните  Выберите   Именованный ACL выберите   Именованный ACL  9028 который содержит только IPv4-адреса и сети.Запросы NTP не поддерживают ACE на основе ключа TSIG. При выборе этого параметра устройство позволяет клиентам, имеющим разрешение  Разрешить  в названном ACL, использовать его службу NTP, а также принимать запросы ntpq от этих клиентов. Вы можете нажать  Очистить , чтобы удалить выбранный именованный ACL.
  Использовать   этот набор     из   ACE : Выберите это, чтобы настроить отдельные ACE. Щелкните значок  Добавить  и выберите один из следующих вариантов в раскрывающемся списке.В зависимости от выбранного вами элемента Grid Manager либо добавляет строку для выбранного элемента, либо разворачивает панель, чтобы вы могли указать дополнительную информацию о добавляемом элементе, а именно:
  IPv4   Адрес:  Выберите это, чтобы добавить адрес IPv4. Щелкните поле  Value  и введите IPv4-адрес. Разрешение по умолчанию -  Разрешить , что означает, что устройство разрешает доступ к этому клиенту IPv4 и от него. Вы не можете изменить разрешение по умолчанию.В поле  Service  выберите  Time   only , чтобы разрешить этому клиенту использовать службу NTP на устройстве; или выберите  Time   +   NTP   Control   (NTPQ) , чтобы также принимать запросы ntpq от этого клиента.
  IPv4   Сеть:  Выберите это, чтобы добавить сеть IPv4. Щелкните поле  Value  и введите сеть IPv4. Разрешение по умолчанию -  Разрешить , что означает, что устройство разрешает доступ к этой сети IPv4 и из нее.Вы не можете изменить разрешение по умолчанию. В поле  Service  выберите  Time   only , чтобы разрешить этой сети использовать службу NTP на устройстве; или выберите  Time   +   NTP   Control   (NTPQ) , чтобы также принимать запросы ntpq из этой сети.
  IPv6   Адрес:  Выберите это, чтобы добавить IPv6-адрес. Щелкните поле  Value  и введите IPv6-адрес. Разрешение по умолчанию -  Разрешить , что означает, что устройство разрешает доступ к этому клиенту IPv6 и от него.Вы не можете изменить разрешение по умолчанию. В поле  Service  выберите  Time   only , чтобы разрешить этому клиенту использовать службу NTP на устройстве; или выберите  Time   +   NTP   Control   (NTPQ) , чтобы также принимать запросы ntpq от этого клиента.
  IPv6   Сеть:  Выберите это, чтобы добавить сеть IPv6. Щелкните поле  Value  и введите сеть IPv6. Разрешение по умолчанию -  Разрешить , что означает, что устройство разрешает доступ к этой сети IPv6 и из нее.Вы не можете изменить разрешение по умолчанию. В поле  Service  выберите  Time   only , чтобы разрешить этой сети использовать службу NTP на устройстве; или выберите  Time   +   NTP   Control   (NTPQ) , чтобы также принимать запросы ntpq из этой сети.
  Любой   Адрес / Сеть:  Выберите этот параметр, чтобы разрешить доступ ко всем адресам и сетям IPv4 и IPv6. Разрешение по умолчанию -  Разрешить , что означает, что устройство разрешает доступ ко всем клиентам IPv4 и IPv6 и от них.Вы не можете изменить разрешение по умолчанию. В поле  Service  выберите  Time   only , чтобы разрешить клиентам использовать службу NTP на устройстве; или выберите  Time   +   NTP   Control   (NTPQ) , чтобы также принимать запросы ntpq от всех клиентов. 
 После добавления записей управления доступом вы можете сделать следующее:
 Выберите ACE, которые вы хотите объединить, и поместить в новый именованный ACL.Щелкните значок Создать новый именованный ACL и введите имя в диалоговом окне  Преобразовать   в   Именованный   ACL . Устройство создает новый именованный ACL и добавляет его в панель  Named   ACL . Обратите внимание, что ACE, которые вы настраиваете для этой операции, остаются неизменными.
 Измените порядок списка ACE, используя стрелки вверх и вниз рядом с таблицей.
 Выберите ACE и щелкните значок «Изменить», чтобы изменить запись.
 Выберите ACE и щелкните значок «Удалить», чтобы удалить запись.Вы можете выбрать несколько ACE для удаления.
  Включить   KoD : при установке этого флажка устройство (при работе в качестве сервера NTP) отправляет пакет KoD (Kiss-o'-Death) клиенту NTP, если клиент превысил ограничение скорости. Пакет KoD содержит поле stratum, установленное на ноль, и строку ASCII в поле Reference Source Identifier, установленную на RATE, что указывает на то, что пакеты, отправленные клиентом, были отброшены сервером. Когда вы снимаете этот флажок, NTP-сервер отбрасывает пакеты, но не отправляет никаких пакетов KoD клиенту.По умолчанию этот флажок не установлен. Дополнительные сведения о KoD см. В разделе  Включение поцелуя смерти для NTP .
 Сохраните конфигурацию и нажмите  Перезапустить , если он отображается вверху экрана.
 Когда сервер NTP отказывает в обслуживании клиенту NTP, который превысил предел скорости, он обычно отбрасывает пакеты без уведомления клиента. В этом случае клиент, не подозревая о ситуации, продолжает передавать пакеты.Чтобы уведомить клиента о том, что он либо замедляет, либо останавливает передачу пакетов, вы можете разрешить устройству NIOS (когда он действует как сервер NTP) передавать пакет KoD (Kiss-o'-Death). Этот пакет содержит поле stratum, которое установлено в ноль, что означает, что отправленный пакет был недопустимым, и строку ASCII, которая содержит RATE в поле идентификатора ссылки, указывающую состояние переданного пакета и управление доступом. Когда клиент получает пакет KoD, он может снизить скорость передачи или остановить передачу пакета на сервер.Дополнительные сведения о KoD см. В RFC 5905  (Сеть   Время   Протокол   Версия   4:   Протокол   и   Алгоритмы   Спецификация) . Вы можете включить KoD на уровне сетки и переопределить его на уровне участника. Для получения дополнительной информации о включении KoD см.  Определение контроля доступа NTP .
 Когда вы разрешаете Grid синхронизировать свое время с внешними серверами NTP, вы можете отслеживать состояние службы NTP, проверяя значки состояния NTP на панели  Member   Services .Чтобы получить доступ к панели, на вкладке  Grid  выберите  Grid   Manager  tab ->  Members  tab ->  Grid_member  check box, а затем выберите значок Manage Member Services на панели инструментов таблицы участников. таб. 
 Ниже приводится описание значков состояния NTP на панели  Members   Services . Тип информации, которая может отображаться в столбце  Описание , соответствует сообщениям ловушек SNMP.Для получения информации о ловушках SNMP Infoblox см.  Настройка SNMP .
3 9284
3 
  Значок 
  Цвет 
  Значение 
 правильно.
 
 Желтый
 Служба NTP включена, и устройство синхронизирует свое время.
 
 Красный
 Служба NTP включена, но не работает должным образом или не синхронизирована.
 
 Серый
 Служба NTP отключена.
 
 После обновления Grid до 6.6.x или более поздней версии цвет значка состояния Grid изменяется в зависимости от следующего:
 Если вы активируете внешнюю синхронизацию или запускаете службу NTP с помощью Grid Manager или не настраивайте внешние серверы NTP, кроме локальных, то поведение NTP останется прежним, и на устройстве NIOS значок состояния сети отобразится зеленым цветом.
No related posts.