И снова здравствуйте, дорогие любители синхронизации и те, кого просто принудили. Протокол PTP хорошо настоялся в темном чулане за 20 лет, свободные диапазоны частот в мобильной сети кончаются, LTE TDD шагает по стране широкой поступью, на подходе 5G, так что никуда вы, милые мои, не денетесь от прочтения всего цикла статей. Не сегодня завтра жизнь все равно заставит всех через одного уметь в синхру на пакетных сетях. Наслаждайтесь и приятного аппетита.
Синхронизируй то. Акт I: SyncE
Синхронизируй то. Акт II: базовый PTPv2
Синхронизируй то. Акт III: PTPv2 G.8275.1
По традиции начнем душно, сначала будет сложно, потом совсем мрак. Как говорилось в предыдущем акте, протокол PTPv2 в чистом виде (Default profile) - это лишь общие красивые бла бла бла. Далее на сцену выходят рабочие группы, которые придумывают, как его правильно приспособить к реальным условиям телекоммуникаций, энергетики, телевидения, финансов, дата-центров и прочего. G.8275.1 является адаптацией для пакетных сетей, ориентированных на передачу данных в мобильных сетях. Разработчики на берегу определили следующие ключевые параметры:
полная поддержка со стороны сети. Никаких унылых компромиссов в виде ACR или ATR. Каждый девайс по дороге обязан иметь на борту специализированный чип. Только так можно достигнуть точности в наносекунды;
типы устройств T-BC, T-GM, T-TSC, T-TC;
работа поверх l2 методом multicast-вещания (forwardable 011B-1900-0000 или non-forwardable 0180-C200-000E – это важный момент, об который можно долго тупить);
использование VLAN запрещено (а значит нет поля 802.1p => нет QoS);
межвендорная совместимость;
возможность адекватной работы с lag’ами;
полная независимость от загрузки линков и QoS (временнАя метка якобы ставится после выхода пакета из очереди, т.е. время задержки в буфере исключено из расчетов);
зарезервированы номера доменов от 24 до 43;
запрещено изменять значение Prioriry1 у любого элемента (защита от кривых рук в BMCA);
5 сигнальных сообщений: Sync, Delay_Req, Delay_Resp, Follow_Up, Announce;
все вычисления с помощью Delay-cообщений. Никаких Pdelay (о них я не рассказывал);
нормальный G.8275.1 частоту берет из SyncE, а фазу из сообщений PTP – это режим Hybrid.
Пойдем по порядку. По сравнению с дефолтным профилем введены новые названия сетевых элементов:
BC теперь T-BC – Telecom Boundary Clock;
OC – T-TSC – Telecom Time Slave Clock (видать тоже не оценили «обычные» часы);
GM – T-GM – Telecom GrandMaster;
TC – T-TC - Telecom Transparent Clock (по факту не используется).
Режимы портов не изменились (Master/Slave/Passive). Схема распространения синхронизации hop-by-hop на основе STP BMCA
Примитивные настроечки
В минимальном варианте, чтобы запустить протокол на железке, его нужно включить глобально и прибить к портам.
Глобальный блок на Huawei оформляется тремя кнопками
ptp profile g-8275-1 enable | выбираем профиль g.8275.1 |
ptp enable | запускаем ptp |
ptp device-type t-bc | выбираем режим устройства T-BC |
Далее с закрытыми глазами развешиваются настройки на физические порты
interface GigabitEthernet0/2/1 | |
ptp notslave disable | разрешаем порту работать в режиме slave/master. Иначе будет только master. Логично иметь команду только на uplink-портах, откуда можно увидеть GM |
ptp mac-egress destination-mac 0180-c200-000e | необязательная команда. Но в рамках одной мультивендорной сети желательно прямым текстом указывать тип мак-адреса, чтобы не было сюрпризов |
ptp enable | разрешаем обработку ptp на интерфейсе |
И все великолепно заработает. Если, конечно, SyncE включен (но об этом в следующий раз). В отличие от SyncE здесь расставлять приоритеты руками не нужно, ведь есть BMCA, который сам построит наилучшую топологию.
На джуне свой
set protocols ptp clock-mode boundary | режим железки T-BC |
set protocols ptp profile-type g.8275.1 | профиль g.8275.1 |
set protocols ptp phy-timestamping | простановка временных меток t1, t2, t3, t4 на входе/выходе из интерфейса |
set protocols ptp slave hybrid | гибридный режим работы (частоту берет из SyncE, фазу из PTP) |
А вот на интерфейсах начинаются грабли
set protocols ptp master interface ge-1/0/8.1 multicast-mode transport ieee-802.3 link-local set protocols ptp master interface xe-2/0/0.1 multicast-mode transport ieee-802.3 set protocols ptp stateful interface xe-3/0/0.0 multicast-mode transport ieee-802.3 link-local
Во-первых, настройки применяются к юнитам. Если порт тегированный, то сперва нужно сделать юнит с native-vlan-id
set interfaces ge-1/0/8 native-vlan-id 1 set interfaces ge-1/0/8 unit 1 vlan-id 1
Если порт сразу нетегированный, то лишних телодвижений не требуется.
Во-вторых, крайне важна команда link-local. Она указывает на тип мак-адреса, с которым кадр улетает в сеть.
forwardable 011B-1900-0000
non-forwardable 0180-C200-000E (link-local)
Juniper и базовые станции Huawei относятся к этому крайне нервно, и при несовпадении типов с двух сторон пакеты будут игнорироваться. Маршрутизаторы Huawei при этом работают с любым маком, даже, если с разных сторон они не совпадают.
В-третьих, важно запомнить, что ptp-порты на Juniper бывают в трех режимах:
master – с него рассылаются сообщения нижестоящим железкам;
slave – через него виден источник синхронизации;
stateful – может быть или master, или slave, в зависимости от топологии (аналог ptp notslave disable на Huawei).
И тут действуют следующие ограничения при настройке:
чтобы конфигурация применилась, минимум один порт должен быть в master, и минимум один в slave/stateful. Нельзя настраивать по частям. Если
замахнулся - бейсобрался настраивать PTP, нече сопли размазывать, будь мужиком, иди до конца;slave и stateful вместе на одной железке быть не могут.
Изи епта.
Надо отметить, что в PTPv2 G.8275.1 нет никаких средств аутентификации соседей (они появились в PTPv2.1). Поэтому чем меньше портов в режиме slave/stateful/ptp notslave disable, тем лучше. Моя бесценная рекомендация: вниз по топологии все порты делать только master, аплинки slave/stateful. Т.о. диджитал хулиган не сможет воздействовать более, чем на одно кольцо.
Еще из важных особенностей, заложенных в профиль G.8275.1, стоит отметить адекватную работу с lag’ами. Как известно, объединение портов призвано решить две основные задачи:
резервирование;
увеличение пропускной способности с помощью балансировки ECMP.
Резервирование достигается как разносом трафика на разные порты (и разные платы), так и прохождение оптики разными трассами. А это как раз приводит к разной односторонней задержке. Так в одном линке пакет может лететь 1мс, а в другом 20мс. Это означает, что t2-t1 ≠ t4-t3. Это приведет к некорректным расчетам параметра Offset.
Благо, разработчики хорошо подумали и дали нам возможность указывать руками, какие порты из лага участвуют в ptp, и какой из них главнее. Например, так
set protocols ptp stateful interface ae1.0 multicast-mode transport ieee-802.3 link-local set protocols ptp stateful interface ae1.0 primary xe-4/0/0 set protocols ptp stateful interface ae1.0 secondary xe-4/0/1
На хуавее это, кстати, происходит автоматически, и отдельно для lag’а настраивать ничего не требуется.
Еще, при желании, можно задать номер домена. По умолчанию он выставлен 24.
Диагностика
В целом, что хотели из основных параметров - настроили. Пришло время посмотреть, как у нас все круто завелось. На хуавее это умещается в вывод одной команды display ptp all
Кратенько пробежимся по самым интересным полям
Самое желанное — железка залочилась;
С возрастом бывает, не получается донести мысль с дивана до кухни. Так вот, для подзабывших что мы там настроили, показывает, что работаем в режиме PTPv2 G.8275.1;
мак GrandMaster’а, чтобы с первой ноты знать, кто сегодня батя;
порт, с которого синхронизируемся;
блок характеристик, прилетающих в Announce от GM;
статусы портов. Точно знаем, где рабы, где господа.
Как правило, этого достаточно для решения практически всех проблем на сети. Лично я, чтобы разобраться во всем и сразу, смотрю в 1, 3, 4, 6. Но, если что-то не взлетает, можно дополнительно посмотреть статистику. Для нормального master-порта она будет выглядеть примерно так
Есть блоки Recv и Send. Со своей стороны мы усиленно отправляем пакеты Announce с характеристиками GM и Sync c меткой времени t1. Ведомая железка после получения каждого Sync тут же бежит узнавать время односторонней задержки и шлет нам Req. Мы отвечаем на него своим Resp. Когда все работает хорошо, количество пакетов Req=Resp. А вот количество Sync и Announce может быть значительно меньше. Частота их отправки, при желании, регулируется на порту
[HUAWEI-GigabitEthernet4/0/0]ptp ? announce-interval Configure announce message interval min-delayreq-interval Configure delayreq message interval sync-interval Configure sync message interval
На всякий случай освежу, как вся эта статистика выглядит в пакетах
Дюже детальнее
Что интересного в этом дампе. Во-первых, посмотрите на dst mac у Sync и Delay_Req кадра — они разные. Это как раз к слову о том, что маршрутизаторы Huawei на такие условности внимания не обращают (в отличие от Juniper).
Далее, зеленой нитью через всю сигнализацию проходит номер домена по умолчанию 24. Это система свой-чужой на минималках.
В G.8275.1 в пакетах передаются только метки времени t1 и t4. Метки t2 и t3 локальны для ведомой железки.
Значение поля sequenceId попадает в счетчики на интерфейсе. Через него же производится связь запроса Delay_Req с ответом Delay_Resp.
На джуне все это же самое размазали по множеству команд. Но, как правило, самое интересное можно увидеть в show ptp lock-status detail.
Именно в поле Lock State отображается все самое волнительное из блок-схемы процесса синхронизации
Бонусом получаем информацию о текущем Offset’е, а также порту и маке GM.
Можно посмотреть статистику переданных и принятых пакетов.
С ключом detail информация примет исчерпывающий, но нечитаемый вид. Даже приводить не хочется.
Для искушенной публики
В целом, вся информация выше - для бегиннеров, и она перекрывает 99% потребностей по запуску и какому-никакому траблшутингу. Но мы же задроты продолжающие, поэтому разберем еще пару фокусов.
Как много раз говорилось, все, что хочется увидеть в системах синхронизации — статус Lock (Phase Aligned). Ровно в этот момент со стороны инженера падает либидо всякий интерес к железке, и он идет заниматься своими делами. Хотя тут есть на что еще подсмотреть в замочную скважину. Это значение тех самых параметров Offset и t1,t2,t3,t4. Ябпосмотрел. На Juniper с этим крайне туго.
Зато на Huawei сколько угодно
Собственно, здесь можно своими глазами увидеть все, о чем было так скучно читать в прошлой главе. Рассказывать про t1, t2, t3, t4 еще раз неинтересно. А вот про Offset и Pathdelay интересно. Измеряются в наносекундах.
В принципе Pathdelay примерно равно (t2-t1) или (t4-t3). Но что это дает? А то, что мы без рефлика можем с неплохой точностью узнать длину линии. У DWDM’щиков подглядел, что у них принято, что свет в оптике проходит 1м примерно за 5нс.
А вот так в PTP выглядит метровый патч-корд
Time Performance Statistics(ns): Slot 2 Port 0 ------------------------------------------------------------------------------ Realtime(T2-T1) :9 Pathdelay :0 Max(T2-T1) :21 Min(T2-T1) :1
Сделает ли это знание нас более конкурентными в эволюционном отборе или борьбе за сердце прекрасной самки? Не уверен, но закинуть эндорфинчиков в эго все равно приятно.
А вот параметр Offset надо понимать. Напомню формулку
![Offset = ([t2 - t1] - [t4 - t3]) / 2](https://habrastorage.org/getpro/habr/formulas/6/63/638/6383809e1da79dbf5e35113169d5f522.svg)
Offset - это всего лишь навсего смещение ведомых часов от ведущих. Та самая фаза, за которую мы тут третий акт рубимся. В примере выше ведомые убежали вперед на 1нс, это нестрашно и вообще хорошо.
Бывает, что между соседями не такая доброжелательная атмосфера, и это надо бы починить.
<Huawei>dis ptp all | i Offset Offset from master:-235
Именно для таких случаев крайне полезно знание о значении офсета. На самом деле тайный смысл в том, что Offset это разница фаз между двумя соседними устройствами. Смещение в масштабах всей сети между GrandMaster-батей, куда приходит GPS, и условной базовой станцией, на которую мы доставляем синхронизацию, будет равно сумме Offset’ов на всех железках по дороге. А там могут набираться неплохие числа.
Скрытый текст
Это в простейшем виде. На самом деле, и это еще не все условия, там все сильно сложнее и зависит в первую очередь от стабильности и одинаковости частоты по всей трассе. В конце, где DWDM, увидим, как легко все рушится.
Помните еще, что для LTE TDD нужна точность фазы ±1500нс? Наша задача сделать сеть такой, чтобы сумма офсетов по дороге до любой точки сети вписывалась в этот бюджет.
Для решения этой задачи не все хуавеи одинаково полезны. Есть бесполезные. Почти все. На всех старых софтах вплоть до V8R23 разработчики почему-то решили, что нам значение offset’а вообще знать ни к чему, и не показали
<старый дряблый Huawei>dis ptp all state | b Perfo Time Performance Statistics(ns): Slot 2 Port 26 ------------------------------------------------------------------------------ Realtime(T2-T1) :27015 Pathdelay :0 Max(T2-T1) :319552 Min(T2-T1) :26945
Из t2-t1 мы примерно будем знать Pathdelay, который тут поленились заполнить каким-то значением. А offset решили вообще не показывать. Льстят нам, дескать, не царское это дело в таких мелочах разбираться. Но нам-то прижало, мы у мамы
Ворвемся без стука туда, где нас не ждали — в диагностический режим. Само собой проигнорируем все предупреждения, ведь от нас веет апаснастью
<старый дряблый Huawei>sys Enter system view, return user view with return command. [~старый дряблый Huawei]diag Warning: Enter diagnose view, return user view with Ctrl+Z. Info: The diagnose view is used to debug system hardware and software. Misuse of certain commands in this view may affect system performance. Therefore, use these commands with the guidance of Huawei engineers.
Есть че по новым командам?
[~старый дряблый Huawei-diagnose]display ptp ? all Display all ptp information bits Bits signal interface Display an interface information timestamps Show ptp timestamps utc Display utc time
Вон че есть
[~старый дряблый Huawei-diagnose]dis ptp timestamps PTP timestamps ****************************PTP timestamps information begin***************************** Idx T1(s) T1(ns) T2(s) T2(ns) CF(s) CF(ns) CF. ------------------------------------------------------------------------------- 0 1776937990 440633010 1776937990 440668770 +0 8395 0 1 1776937990 503023282 1776937990 503059322 +0 9035 0 2 1776937990 565413554 1776937990 565449640 +0 9052 0 3 1776937990 627803826 1776937990 627839891 +0 9050 0 4 1776937990 690194098 1776937990 690230292 +0 9095 0 5 1776937990 752584370 1776937990 752620540 +0 9120 0 6 1776937990 814974642 1776937990 815010788 +0 9105 0 7 1776937990 877364914 1776937990 877401027 +0 9152 0 8 1776937990 939755186 1776937990 939791273 +0 9107 0 9 1776937991 3901106 1776937991 3937250 +0 9145 0 10 1776937991 66291378 1776937991 66327490 +0 9112 0 11 1776937991 128681650 1776937991 128717666 +0 9017 0 12 1776937991 191071922 1776937991 191107988 +0 9065 0 13 1776937991 253462194 1776937991 253498235 +0 9035 0 14 1776937991 315852466 1776937991 315888635 +0 9130 0 15 1776937991 378242738 1776937991 378278884 +0 9140 0 Idx T3(s) T3(ns) T4(s) T4(ns) CF(s) CF(ns) CF. ------------------------------------------------------------------------------- 0 1776937990 400975021 1776937990 401011137 +0 8821 0 1 1776937990 463479168 1776937990 463514937 +0 8798 0 2 1776937990 525986678 1776937990 526022985 +0 8821 0 3 1776937990 588493159 1776937990 588528937 +0 8806 0 4 1776937990 650997672 1776937990 651033545 +0 8813 0 5 1776937990 713504793 1776937990 713540545 +0 8773 0 6 1776937990 776010281 1776937990 776046033 +0 8801 0 7 1776937990 838516488 1776937990 838552329 +0 8878 0 8 1776937990 901021941 1776937990 901057809 +0 8828 0 9 1776937990 963527470 1776937990 963563265 +0 8791 0 10 1776937991 26035311 1776937991 26071089 +0 8791 0 11 1776937991 88540799 1776937991 88576537 +0 8778 0 12 1776937991 151046287 1776937991 151082377 +0 8808 0 13 1776937991 213551074 1776937991 213586849 +0 8813 0 14 1776937991 276056568 1776937991 276092369 +0 8808 0 15 1776937991 338564040 1776937991 338600001 +0 8878 0 Max T2-T1: 0s,840344ns Orig T1: 00000 1776937475s,003901106ns Orig T2: 00000 1776937475s,004749820ns Min T2-T1: 0s,26910ns Orig T1: 00000 1776936210s,440633010ns Orig T2: 00000 1776936210s,440668930ns Real T2-T1: 0s,27006ns Orig T1: 00000 1776937991s,378242738ns Orig T2: 00000 1776937991s,378278884ns Max T4-T3: 0s,28043ns Orig T3: 00000 1776934890s,735124687ns Orig T4: 00000 1776934890s,735161593ns Min T4-T3: 0s,26893ns Orig T3: 00000 1776936759s,472910736ns Orig T4: 00000 1776936759s,472946425ns Real T4-T3: 0s,27083ns Orig T3: 00000 1776937991s,338564040ns Orig T4: 00000 1776937991s,338600001ns ****************************PTP timestamps information end*******************************
Опачки, это что это у нас тут такое интересное? t1, t2, t3, t4 теперь вижу, но offset и pathdelay не вижу, предлагают добывать самим. Несем все это дело в табличный процессор, калякаем формулу для третьеклассников ([t2-t1)-(t4-3])/2
И видим, что я, похоже, в прошлый раз пропиз был немножечко неправ. Когда рассказывал про поле correctionField (CF). Я там на невозмутимых щах свистел, что поле используется только в устройствах типа Transparent Clock, и поэтому в телекоммуникациях оно всегда равно нулю, потому что никому в здравом уме не придет мысль использовать TC.
У меня тут хуавей синхрится с джуна, с платы MPC3E. И, судя по выводам, Juniper придумал на своих многоюнитовых железках использовать CF для уточнения точности. Метка t1 формируется где-то в чипе синхронизации на SCB, а метка CF добавляется где-то на линейной плате ближе к выходу из порта. По CF, кстати, можно судить сколько времени пакет путешествует по кишочкам маршрутизатора. Явно решение не от хорошей жизни, но его нужно учитывать. Точности оно хорошо добавляет, целый порядок. Пишем ([t2-t1-CF)-(t4-3-CF])/2
На Huawei, по крайней мере в одноюнитовых девайсах, correctionField не используется, на Juniper ACX2100, кстати, тоже.
Все-таки приложу похожую табличку, когда хуавей в хуавея смотрит. Абсолютно другой мир стабильности
Объективности ради, на джуновских платах MPC7E с точностью все очень хорошо и ptp работает ровно так, как от него ждешь — как на хуавее).
Так, хорошо, экселичку вспомнили (но далеко убирать не будем), добывать offset научились, давайте еще раз посмотрим на Min и Max значения (t2-t1) в стандартном выводе.
<старый дряблый Huawei>dis ptp all state | b Perfo Time Performance Statistics(ns): Slot 2 Port 26 ------------------------------------------------------------------------------ Realtime(T2-T1) :27015 Pathdelay :0 Max(T2-T1) :319552 Min(T2-T1) :26945
Казалось бы, G.8275.1 из коробки хорош тем, что это аппаратная поддержка на каждой железке, все временные отметки t1 в пакетах PTP Sync ставятся максимально близко к физическому уровню, QoS не нужны, потому что на пакеты не воздействует буферизация и т.д. Знакомьтесь, так выглядит пиздеж чистой воды. Как только в сети возникает какой-нибудь Juniper MX104 или джуновская плата MPC3E, так оказывается, что команда
set protocols ptp phy-timestamping
как бы есть, вот только метки ставятся нифига не на выходе из интерфейса, а где-то еще до процесса буферизации и никакой режим Two-step с Follow_Up это исправить не позволяет. В итоге мы получаем разбег значений (t2-t1) от 26000 до 320000нс.
Max(T2-T1) :319552 Min(T2-T1) :26945
Естественно, в таких условиях фаза плавает, и на пользу делу это не идет.
Приколы от Juniper ACX2100
Juniper ACX2100 в этом плане оказался более честен. Там команда set protocols ptp phy-timestamping как бы применяется, но сразу говорит, что что-то с ней не так. Казалось бы, аппаратная поддержка, все дела, а у нас между соседями смещение такое, что в деле явно виден почерк тракториста
<Huawei>dis ptp all | i Offset Offset from master:300
Не мало времени прошло прежде, чем у меня появилось желание разобраться, как это починить. Оказалось, что какие-то шутники конкретно для ACХ изобрели свою команду
set protocols ptp e2e-transparent
Не очень понятно как именно это работает, потому что на хуавее конкретно дампы для протокола PTP никак снять не получается. Зато это реально та редкая команда, которая работает линейно по принципу
Я, конечно же, побежал проверять. Нашел, где у меня хуавей граничит с ACX2100, и давай жать на одну кнопку. Хуавей (который на V8R23) обновляет на экране значения offset’а раз в секунду. 15 минут (900 раз) понажимал скриптом (вот в такаксе, наверное, удивились моему усердию), получил что-то типа такого
<Huawei>dis ptp all | i Offset from master Offset from master:-4 <Huawei>dis ptp all | i Offset from master Offset from master:68 <Huawei>dis ptp all | i Offset from master Offset from master:227 <Huawei>dis ptp all | i Offset from master Offset from master:240 <Huawei>dis ptp all | i Offset from master Offset from master:42 <Huawei>dis ptp all | i Offset from master Offset from master:32 <Huawei>dis ptp all | i Offset from master Offset from master:25 <Huawei>dis ptp all | i Offset from master Offset from master:11 <Huawei>dis ptp all | i Offset from master Offset from master:12
Потом это дело в эксельку, нажать ПКМ и ЛКМ, создать график, все как в институте учили. По оси абсцисс
у нас отсчеты в секундах (этих секунд 900 на графике), по оси ординат это offset в наносекундах.
Мэджик, не иначе. Счастью своему не поверил, попросил донов из мобилы запустить тесты на базовых станциях. И там победа побед.
Так невзначай полечился LTE TDD в целом городе, где фанатеют за ACX2100.
А мы своими глазами увидели, чем отличается программная простановка временных меток от настоящей аппаратной.
Но и это не все, что надо знать про ACX2100. Знаете, как примерно прикинуть что-нибудь к носу и узнать частоту процессора маршрутизатора? Я преисполнился в наблюдениях за ACX2100. Там на некоторых узлах offset всегда отображается кратный 8 нс: 0, 8, 16, 24, 32 и т.д
ACX2100> show ptp lock-status | match Phase Phase offset : 0.000000008 sec ACX2100> show ptp lock-status | match Phase Phase offset : 0.000000016 sec ACX2100> show ptp lock-status | match Phase Phase offset : 0.000000024 sec ACX2100> show ptp lock-status | match Phase Phase offset : 0.000000048 sec
Я подумал-подумал и придумал, что это зависит от частоты процессора 125МГц. Длина его такта как раз
В итоге имеем, что на ACX2100 несмотря на всю аппаратную поддержку (даже настоящую), гарантированная минимальная погрешность составляет ±8нс. Десяток таких девайсов в цепочке - это сразу ±80нс только из-за медленного процессора. На них уж точно пикосекундных точностей не добиться, для 5G придется модернизировать.
Анализатор
За ламповыми разговорами про offset’ы мы стали напрочь забывать, что синхронизацию нужно доставить с GrandMaster’а на базовую станцию с точностью не хуже ±1500нс. Но как измерить что мы там надоставляли? Если бы речь шла про SDH и частоту, то там был бы прибор, к нему специальный сертифицированный году в 1999 человек, который ездил бы на узлы и че-нить измерял. Для фазовой синхронизации такой прибор тоже изобрели, схема его применения довольно простая: GM берет время с GPS, прибор-анализатор тоже берет время с GPS. Втыкаемся тестером на узле и сравниваем, что нам пришло из космоса, и что пришло из сети по PTP. Разница фаз как раз и составит общесетевой offset.
Но у нас тут вам не SDH, это пакетные сети, у нас всем на все насрать, как-то заработало да и ладно
Поэтому тестеров (приборов и людей) никто в глаза не видел (я точно), и скорее всего даже не слышал. Но узнать-то хочется, и их есть у меня.
Для таких как мы, чуваки из хуавея, придумали задействовать порт Passive, который стоит без дела в середине кольца, просто разрывая петлю. Не выяснял на сколько это протокольная штука, но у джунипера с 23 версии софта этот функционал тоже заявлен. На картинке BMCA построил зеленое и красное дерево. Железки на границе друг с другом не взаимодействуют, одна порт перевела в Master, другая в Passive.
Заходим на девайс, как обычно смотрим что там насинхрилось.
Видим offset от соседней железки 5нс с порта Gi0/2/0. Видим, что число шагов до GrandMaster у нас 9 (это просто для понимания как далеко GM). Еще видим, что на этом девайсе у нас есть порт Gi0/2/1 в passive. И видим некую функцию Passive measure в enable — это как раз оно. Берем в оборот
Passive offset = -44ns это фактически реализованный функционал встроенного тестера. Он показывает, на сколько различаются фазы на устройствах, которые берут синхру с разных ветвей дерева. Нюанс, который надо учитывать - измеряется разница фаз от ближайшей общей точки, и совсем не факт, что это будет GrandMaster. На схемке выше это всего 3 узла, расстояния смешные в пару километров. А смещение между ветвями целых 44нс - это все заслуга ACX2100, которых там несколько штук, и они вносят свою неустранимую погрешность из-за медленных процессоров.
Давайте поймем, как это работает. Смотрим статистику пакетов. В разделе Discard мы видим, что надропано 19296 пакетов Sync. Все верно, пакеты получаем, но просто отбрасываем их за ненадобностью, т.к. мы берем синхру с другого порта. Но иногда порт начинает пропускать пакеты Sync, слать Delay_Req и получать в ответ Delay_Resp. Их таких 420 штук набралось. Как раз в ходе этих запусков происходит сравнение разницы фаз на Slave и Passive портах. Гениально. Фича запускается примерно раз в 5 минут.
Кстати, эта же измерялка умеет гадить в логи немного странным сообщением
Apr 23 2026 19:36:53+00:00 Huawei %%01PTP/4/hwPtpPassiveFiberLengthChange(l):CID=0x80f90457;The fiber length of the passive port changed. (hwPtpCurrentIfIndex=6, hwPtpPortName=GigabitEthernet0/2/1, hwPtpPortRingFiberLengthChangeValue=211, hwPtpPortRingFiberLengthChangeValueFlag=1) Apr 23 2026 19:31:24+00:00 Huawei %%01PTP/4/hwPtpPassiveFiberLengthChange(l):CID=0x80f90457;The fiber length of the passive port changed. (hwPtpCurrentIfIndex=6, hwPtpPortName=GigabitEthernet0/2/1, hwPtpPortRingFiberLengthChangeValue=208, hwPtpPortRingFiberLengthChangeValueFlag=1)
Уж не знаю, почему они решили это назвать изменением длины оптического провода, когда дело всего-навсего в переменчивости частот на разных ветвях дерева. Длину провода они зачем-то измеряют в наносекундах - числа 208 и 211. В целом, задача сообщения - простимулировать нас пойти разобраться и починить. Но делать этого мы, конечно же, не будем.
PTSF
Звучит как БДСМ, только для PTP. Вроде все было хорошо, а потом раз и на железке отваливается синхра. Все порты в статусе master. Чтобы хоть один из них превратить в slave, нужно дернуть протокол. В общем, PTSF - packet timing signal fail, это такая фича, которая обнаруживает падение или ухудшение качества синхросигнала, а точнее увеличение offset’а до 500нс (по другой версии до 1,1мкс) на протяжении некоторого промежутка времени. Далее порт помечается плохим, запускается BMCA, выбирается новый порт. Функционал хороший, правильный, на хуавее запускается
ptp source-switch ptsf enable ptp ptsf enhanced-mode
Но есть нюанс. Если использовать только первую команду, то со временем маршрутизатор пометит все порты «плохими» и хорошие в конце концов закончатся. Как раз тот случай, когда заходишь на железку, а там одни только master’а остались. Вторая команда позволяет сбрасывать флаг «плохости» с порта и дает возможность когда-нибудь потом ему заново поучаствовать в BMCA. Но тут выплывает моментик: не во всех софтах есть вторая команда)
В логах примерно вот так бывает.
Aug 15 2025 08:36:29 Huawei %%01PTP/4/hwPtpClockSourceChange(l):CID=0x805803f7;The time source is switched. (hwPtpOldMasterClockId=001122fffe333344, hwPtpCurrentMasterClockId=021335fffe9f718b, hwPtpPortIfIndex=0, hwPtpPortOldSourcePortNum=3, hwPtpPortSourcePortNum=0, hwPtpOldPortName=GigabitEthernet0/2/26, hwPtpPortName=local) Aug 15 2025 08:36:29 Huawei %%01PTP/3/hwPtpPortPtsf_active(l):CID=0x80f90457-alarmID=0x00f103a0;The ptsf alarm of the ptp port occurs. (hwPtpPortIfIndex=31, hwPtpPortName=GigabitEthernet0/2/26, hwPtpPortPtsfReason=2) Aug 15 2025 07:32:44 Huawei %%01PTP/3/hwPtpTimeOffsetSumOver_active(l):CID=0x805803f7-alarmID=0x00f1006b;The ptp time offset sum is abnormal. (hwPtpTimeOffsetSumP2P=520, hwPtpAlarmThresholdOffsetSum=500)
Хроматическая дисперсия и групповой показатель преломления
Сейчас будет тема дискуссионная, в которой я не до конца уверен, а DWDMщики вообще говорят, что это не так работает. Может я и не прав, но сеть показывает что показывает.
При отсутствии наличия лишних волокон некоторые линки могут выполняться на одноволоконных трансиверах. В этом случае прием ведется на одной длине волны, передача на другой. Например, 1270/1330нм или 1490/1550нм. Во всех книжках говорят, что свет разной длины волны летит одно и то же расстояние разное время, это называется хроматической дисперсией. Есть у меня сегмент сети, где WDMных линков вагон и маленькая тележка, и расстояния приличные. Здесь только часть нарисована
Так вот, встроенный в Huawei тестер показывает на пассивном линке offset в 40нс, чего я ничем кроме дисперсии объяснить не могу (в аналогичных кольцах без WDM значение в пределах 10нс)
<Huawei>dis ptp int gi0/2/1 Port State :passive Port Clock ID :5544c1fffe082242 Port Number :8705 Port Precision Capability :High precision clock Port Precision Work Mode :High precision clock Passive Offset :41 ns
Доны из DWDM говорят, что хроматическая дисперсия это про другое, типа про уширение исходного импульса
но я смотрю на другие картинки, и в них одна длина волны устраивает гонки с другой.
Не знаю кто прав, но без нормального тестера тут ничего не доказать. Могу только гадать по ITU-T-G.652. Там есть график коэффициента дисперсии D(λ) в зависимости от длины волны
А еще есть график
и таблица с групповым коэффициентом преломления, который рассказывает на сколько тормозится свет определенной длины волны в среде распространения по отношению к скорости света
Если брать таблицу, то длина волны 1500нм пройдет 60км за
t(1500 нм) = (60 км / 300000 км/с) * 1,4623 = 200000 нс *1,4623 = 292460 нс
А длина волны 1600нм
t(1600 нм) = (60 км / 300000 км/с) * 1,4629 = 200000 нс *1,4629 = 292580 нс
Т.о. разница в прохождении пакета между прямым и обратным направлением в одноволоконном WDM линке может составить аж 292580-292460=120нс. Мне не удалось найти точных значений для длины 1490 и 1550 нм, но очень похоже, что те 40нс смещения фазы, что намерились в хуавее на passive линке как раз в основном заслуга WDM линка 1490/1550нм. Для длин 1270/1330нм смещение минимальное и, вероятно, на результат особо не влияет.
В общем, привлекайте к расчетам тех, кто волокет в оптических делах.
Так или иначе, разработчики позаботились и об этом: есть возможность вручную скорректировать асимметрию в обе стороны.
[Huawei-GigabitEthernet0/2/0]ptp asymmetry-correction ? negative Negative correction value positive Positive correction value
Делается на ведомой железке на slave-порту. Делать желательно либо после измерения прибором, либо на основе точного знания длины прямого и обратного волокна. Мы в пакетных сетях по этому вопросу, естественно, выберем классический вариант: положить с прибором.
PTP over DWDM
Это та часть протокола, про которую вразумительно сказать ничего не могу. Только промычать что-то, что DWDM OTN точно ломает точность PTP. По какой причине это происходит не знаю, может mapping виноват, может некая задержка в DSP-процессоре
Но вот показать могу крайне красноречиво.
Есть такая реальная топология. У Router1 и Router2 общий GrandMaster, а значит измерения встроенного в хуавей тестера покажут нам очень честные фазовые смещения относительно GM.
Router1 у нас имеет два линка до GM по разным трассам и, возможно даже, по системам DWDM разных производителей. Основной линк проходит через красную линию DWDM, резервный через зеленую. Соответственно, на одной железке находятся slave и passive порты. И разница между ними аж 185нс. И это в трассе, где нет никаких других маршрутизаторов.
Но это ладно. Router2 имеет прямой линк до GM по темной оптике и вторым линком смотрит в Router1. Смотрим, что оно нам покажет
1817нс! И это в кольце из двух железок. Очевидно, что проблема в DWDM. Но там слишком много не тех дверей, в которые можно было войти. Подозреваю, что основная проблема с SyncE (передается не в BMP-маппинге), мы ведь помним из второго акта, что обязательным условием фазовой синхронизации является единая частота? Если железки синхрятся от одного источника, но по дороге частота уплывает, то ни о какой фазе речь идти не может. Как раз наш случай. Наверняка, на всех трех линках до GM возникла своя частота. Router2 получает истинную частоту, а Router1 синхрится от XFP на DWDM (см. акт I где Synce over DWDM). Простым решением в данном конкретном случае может стать использование корректировки асимметрии, благо все замерено довольно точно. Сложным и правильным решением является переделка на DWDM: SyncE засунуть в BMP, PTP пустить по выделенному каналу OSC (т.е. фактически заставить DWDM синхриться от того же источника).
В целом, ситуация неприятная, но не критичная. Маршрутизаторы находятся друг от друга на большом расстоянии и базовые станции LTE TDD друг друга не видят, поэтому взаимных помех не возникает.
Разговаривать разговоры можно было бы еще долго. Про то, что у хуавея функционал ptp лицензируемый за денюжки, у джуна не все платы одинаково хороши, у хуавея можно в рамках одной железки запускать g.8275.1 и g.8725.2 (ptp-adaptive). MX104 великолепно работает с SyncE и PTP на SFP+ портах и тяп-ляп на SFP и XFP. А еще есть стойкое ощущение, что BMCA на джуне и хуавее работают немного по-разному, но доказать не могу. А еще крайне важно настраивать сеть так, чтобы BMCA строил топологию точно также, как построено дерево SyncE. И т.д. и т.п. Но на сегодня, наверное, хватит. В следующей и заключительной главе останется понять, почему нормальный 8275.1 без SyncE шняга шняжная. Встретимся в сетях.
