PTPv2 в корпоративной сети: когда NTP уже мало и как синхронизировать к микросекундам

Семёнов Евгений Сергеевич, директор АйТи Фреш. Раз в несколько месяцев приходит клиент с одной из трёх жалоб: «каналы записи камер расходятся», «биржевая касса выдаёт timestamp mismatch», «журнал аудита ФСТЭК валится — время скачет на секунды». Схема всегда одна. NTP работал, но недостаточно точно. Для обычного офиса он вполне справляется. Но когда нужна точность меньше миллисекунды — нужен PTP. Расскажу, кому он реально нужен и как его поднять без переплаты за enterprise-решения типа Cisco PTP4K.

Когда NTP мало

NTP (Network Time Protocol) по умолчанию выдаёт точность 1-50 мс в локальной сети и 10-100 мс через интернет. Для 95% корпоративных задач этого хватает: Windows-логи совпадают, журналы 1С читаются, аудит работает. Но есть сценарии, где такая погрешность уже становится реальной проблемой:

• Видеонаблюдение с мультикамерным треком. Камеры снимают один и тот же момент, но на записи кадры расходятся на 200-500 мс — собрать нормальную раскадровку по инциденту просто невозможно.
• Биржевая/POS-касса с законом ФЗ-54. ФНС допускает погрешность timestamp до 5 секунд, однако если у кассы большой drift и NTP не успевает подстроиться — штраф. Банки и НКО-брокеры работают уже в диапазоне микросекунд.
• Корпоративная телефония с несколькими серверами. В кластере Asterisk/FreeSWITCH SIP-запросы маршрутизируются по времени — и уже при расхождении в десятки миллисекунд начинаются сбои.
• Аудио-оборудование (AV over IP). Конференц-залы и студии с Dante или Livewire+ требуют синхронизации в пределах 50 мкс — иначе слышны щелчки и разрывы.
• Log correlation в SIEM. Когда Wazuh или ArcSight собирает логи с 50 серверов, расхождение в 100-200 мс превращает реально одновременные события в корреляцию с lag'ом. Расследовать инциденты становится значительно сложнее.
• Сертифицированные ФСТЭК системы защиты информации. Классы К1-К2 требуют миллисекундную точность в логах — и её надо подтвердить протоколом, а не просто декларировать.

PTPv2 (IEEE 1588-2008) даёт точность 100 нс — 10 мкс в типовом бизнес-сегменте. Три порядка разницы с NTP — это не маркетинг, это физика протокола.

Как это работает в двух словах

PTP состоит из трёх типов устройств:

• Grandmaster — главный источник времени. Обычно сервер с GPS-антенной или с атомными часами на борту. В сети их может быть несколько — BMCA-алгоритм сам выберет лучший.
• Slave — клиент, который тянет время от grandmaster. Это серверы, камеры, кассы и всё остальное.
• Boundary clock / transparent clock — управляемые свитчи, которые корректируют задержку на каждом переходе. Без них точность теряется на 50-200 мкс на каждом свитче в цепочке.

Протокол гоняет Sync, Delay_Req, Delay_Resp пакеты с точными timestamp. Если сетевая карта умеет hardware timestamping — метки времени ставит ASIC прямо в момент отправки или приёма, минуя ОС. Это даёт наносекундную точность. Без поддержки hardware timestamping остаётся software-режим с погрешностью 100-500 мкс.

Требования к оборудованию

На практике у большинства клиентов «оптимум» — это недостижимая роскошь. Мы работаем с «минимумом»: Linux + USB GPS, управляемые свитчи с хоть какой-то приоритизацией PTP-трафика, серверные карты I350/I210, камеры с включённым PTP через веб-интерфейс. Итоговая точность — 100-500 мкс. Уже на два порядка лучше NTP, и для большинства бизнес-задач этого достаточно.

Grandmaster на Linux — минимальная конфигурация

Берём Debian 12, сервер с сетевой картой Intel I350. Подключаем USB GPS-модуль — популярный вариант u-blox NEO-M8, около 2500 руб, антенну выводим на крышу с открытым небом.

# Ставим пакеты
apt install linuxptp gpsd gpsd-clients chrony ntpsec

# Включаем GPS
systemctl enable --now gpsd
gpsmon  # проверяем, что GPS видит спутники

# Настраиваем chrony как источник времени от GPSD для PHC
cat > /etc/chrony/chrony.conf <<EOF
refclock SHM 0 refid GPS precision 1e-1
refclock SHM 1 refid PPS precision 1e-9
driftfile /var/lib/chrony/chrony.drift
makestep 1.0 3
rtcsync
hwtimestamp *
EOF
systemctl restart chronyd

# ptp4l — основной демон PTP
cat > /etc/linuxptp/ptp4l.conf <<EOF
[global]
twoStepFlag             1
slaveOnly               0
priority1               128
priority2               128
domainNumber            0
logAnnounceInterval     1
logSyncInterval         0
logMinDelayReqInterval  0
network_transport       L2
time_stamping           hardware
tx_timestamp_timeout    10

[eth0]
EOF

# phc2sys — синхронизирует PHC с системным clock (который от chrony)
cat > /etc/default/phc2sys <<EOF
OPTS="-s CLOCK_REALTIME -c eth0 -w -m"
EOF

systemctl enable --now ptp4l phc2sys

После запуска сервер становится grandmaster clock. Точность привязки к GPS — порядка 100 нс в секунду. Все slave-устройства в сети начнут получать время от него по PTP.

Slave на Linux-серверах

# Slave-конфиг ptp4l
cat > /etc/linuxptp/ptp4l-slave.conf <<EOF
[global]
slaveOnly               1
priority1               255
priority2               255
domainNumber            0
network_transport       L2
time_stamping           hardware
[eth0]
EOF

systemctl start ptp4l@slave
systemctl start phc2sys@slave

# Проверка
pmc -u -b 0 "GET CURRENT_DATA_SET"
# Смотрим на offsetFromMaster — должно быть в пределах 100 нс — 10 мкс

Camera / Cisco switch / Eltex — настройка

Cisco Catalyst 9300 (boundary clock):

ptp mode boundary
ptp priority1 128
ptp priority2 128
interface Gi1/0/1
 ptp role master
 ptp enable
interface Gi1/0/2
 ptp role slave
 ptp enable

Eltex MES5324:

ptp mode boundary
interface gi0/1
 ptp enable
 ptp role master
exit
show ptp port gi0/1

AXIS / Hikvision IP-камеры: включаем PTP в System → Date & Time → Protocol → PTP, прописываем VLAN с grandmaster. Через 5-10 минут offset уходит в наносекунды — это видно прямо в веб-интерфейсе камеры.

Кейс: синхронизация камер для ресторана

В марте 2026 к нам пришёл клиент — сеть ресторанов премиум-сегмента. Четыре зала, 26 камер в каждом, итого 104 IP-камеры на объект. Задача: собирать раскадровку конфликта клиент-официант с 4-5 камер в одной временной шкале, допустимое расхождение — не более 40 мс (один кадр при 25 fps).

До нас на сервере регистратора стоял chrony, камеры ходили за временем по NTP. Разбежка между самыми дальними камерами доходила до 800 мс. Раскадровка получалась сдвинутой, и разобраться по ней в спорной ситуации было практически невозможно.

Что мы сделали за 6 рабочих дней:

1. Поставили на сервере регистратора ptp4l с GPS-антенной на крышу ресторана (u-blox NEO-M8, около 4800 руб с доставкой и монтажным комплектом).
2. Перевели Cisco Catalyst 9300 в режим boundary clock — PTP на нём был включён, но простаивал без дела.
3. Включили PTP на всех 104 камерах Hikvision через массовый экспорт и импорт конфига.
4. Проверили offset: все камеры уложились в 5-50 мкс от grandmaster — в 10-16 тысяч раз точнее, чем было с NTP.
5. Обновили софт регистратора — включили опцию использования timestamp из RTP-заголовков, а не из внутренних часов регистратора.
6. Проверили на тестовом кейсе: 5 камер, один удар мяча по стакану, раскадровка — расхождение между кадрами 0-30 мс, один-два кадра максимум.

Стоимость проекта — 115 000 руб. Раскадровка теперь идеально синхронная. Был и неожиданный бонус: ptp4l вскрыл, что один из свитчей в большом зале имел аномальную задержку — переполнялся JTS-буфер. После замены свитча общая latency сети упала на 30%.

Кейс: точная синхронизация для финтеха

Второй клиент — НКО-брокер, 45 рабочих мест, ежедневный оборот 8-12 млрд руб. Требование по 719-П ЦБ: точность timestamp в журнале транзакций — не хуже 100 мкс, с протоколом подтверждения. До нас использовался NTP на Windows Server с ntpd.conf — по факту 30-60 мс, в отчёте писали «не хуже 100 мс» наобум.

Проект занял 3 недели:

1. Закупили Meinberg LANTIME M200 с GPS-модулем и резервной антенной — 280 000 руб через партнёра.
2. Установили в серверной, подключили к двум uplink-свитчам Huawei CE6800 в режиме boundary clock.
3. Развернули ptp4l на всех 12 торговых серверах — сетевые карты Intel X710 с поддержкой hardware timestamping.
4. Настроили мониторинг offsetFromMaster в Grafana, алерты в Slack при превышении 10 мкс.
5. Обновили приложение: timestamp в журналах теперь берётся из clock_gettime(CLOCK_REALTIME) с nanosecond-точностью и пишется в лог в явном виде.
6. Прошли испытания с ФСТЭК-аудитором: offsetFromMaster стабильно в пределах 500 нс — 2 мкс, протокол подписан без замечаний.

Стоимость проекта — 680 000 руб. включая железо. ЦБ-проверка прошла чисто, без единого замечания.

Проблемы и грабли

• Множественные VLAN. Если PTP-трафик идёт по одной VLAN, а клиенты сидят в разных — boundary clock на свитче должен проксировать между ними. Часть свитчей этого не умеет: старые Eltex MES-2208 именно так и подвели. Пришлось поднять отдельную management-VLAN специально под PTP.
• QoS-приоритеты. PTP-пакеты должны ходить в самой верхней очереди. Используем DSCP EF или CS7. Без этого при малейшей нагрузке на сеть offset начинает гулять на 50-100 мкс.
• GPS-антенна. Нужно стабильное видение минимум 4-6 спутников. В центре Москвы среди высотных зданий сигнал периодически пропадает — лучше ставить резервную антенну на другую сторону крыши.
• Firewalls и VLAN-тегирование. PTP работает через multicast 224.0.1.129/130 — убедитесь, что IGMP snooping не режет эти группы.
• Hardware timestamping. Поддерживают не все карты. Intel I219, встроенные в большинство десктопов, — не поддерживают. I210, I350, X550 — поддерживают. Проверяйте до покупки.
• Windows-клиенты. Windows Server 2019/2022 поддерживает PTP лишь для Hyper-V guest и с серьёзными ограничениями. Для полноценной работы понадобится сторонний софт — Domain Time II или Microsemi TimeProvider. Часто проще вынести timestamping целиком на Linux-сервер.

Мониторинг

# Grafana-дашборд берёт из pmc:
pmc -u -b 0 "GET CURRENT_DATA_SET" | \
  awk '/offsetFromMaster/ {print "ptp_offset_from_master_ns " $2}'

# Алерт: если offset > 10000 (10 мкс) — telegram уведомление

FAQ — PTPv2 в корпоративной сети

Разве NTP не хватает бизнесу?

Для большинства задач — хватает. NTP даёт точность 1-50 мс. PTPv2 нужен когда требуется меньше 1 мс: журналы финансовых транзакций, аудит-логи со временем к микросекунде, синхронизация камер видеонаблюдения кадр-в-кадр, координация АТС с несколькими серверами, требования ФСТЭК по точности логов.

Что такое grandmaster clock?

Grandmaster — главный источник времени в PTP-сети. Обычно это устройство с GPS-антенной или attached к атомным часам. В сети может быть несколько, PTP-алгоритм BMCA сам выбирает лучший. Для среднего бизнеса достаточно одного grandmaster с GPS и резервного из NTP.

Как проверить, что PTP работает?

На Linux с ptp4l и phc2sys команда pmc -u -b 0 GET CURRENT_DATA_SET показывает offsetFromMaster. Стабильное значение меньше 1 мкс — отлично. Для визуализации есть grafana-дашборды с метриками ptp4l. На Cisco показывает show ptp clock.

Нужны ли специальные сетевые карты?

Для точности до микросекунд — нужны карты с hardware timestamping (Intel I210, I350, X550+). Без них точность останется на уровне 100-500 мкс, что может быть достаточно для бизнес-задач, но не для аудио или видео синхронизации. Mellanox ConnectX-4/5 тоже поддерживают hardware timestamping.

Сколько стоит PTPv2 для офиса 50 рабочих мест?

Зависит от уровня точности. Базовая инсталляция с одним grandmaster на Linux + GPS-антенна + ptp4l на серверах + boundary clock на управляемых свитчах — от 85 000 руб. работа + 35-60 тыс руб на GPS-модуль и антенну. Для критичных систем (финансы, биржа) проект может вырасти до 400-600 тыс руб.