Всем привет, на проводе снова я и опять буду донимать всех своей синхронизацией. В этом цикле статей предлагаю хорошенечко разобраться в фазовой синхронизации на основе протокола PTPv2 G.8275.1 и его верном спутнике технологии частотной синхронизации Synchronous Ethernet. Изучать будем от и до: физический уровень, для интереса заглянем в осциллограммку, посмотрим на сигнальный обмен, расковыряем дампы, посчитаем параметры, проведем пару сеансов разоблачения, узнаем почему QoS’ы нафиг не нужны, как линчевание негров и повесточка изменили PTP, поиграемся в хроматическую дисперсию, увидим какие данные можно выжать с Huawei и Juniper, а также узнаем особенности их работы и где можно неудачненько влететь. К концу пьесы выясним, почему PTP без SyncE пиво без водки деньги на ветер. Информации миллиард и на удивление почти вся по делу. Наберитесь терпения, постепенно все станет ясно. Сегодня разговор о SyncE.
Synchronous Ethernet (SyncE) описан в нескольких бумагах:
G.8261 — определяет аспекты архитектуры и характеристики дрейфа тактовой частоты сетей SyncE.
G.8262 — предусматривает тактовые частоты синхронного Ethernet, совместимые с тактовыми сигналами SDH.
G.8264 — устанавливает требования к каналу обмена сообщениями синхронизации Ethernet (ESMC).
На этом хотелось бы закончить с душным официозом. Попробуем поговорить простыми словами. Начать стоит с того, что технология SyncE по факту полная копия системы частотной синхронизации SDH. Разработчики SyncE не стали мудрствовать лукаво, а просто взяли из SDH всё и внедрили в Ethernet. Когда я говорю всё, это буквально означает архитектуру и топологию, сигнальные сообщения и коды, схему резервирования и предотвращения петель, полную совместимость систем. Более того, некоторые производители плоскогубцами выдрали чип ФАПЧ (PLL) с частотой 19,44 МГц и припаяли в свои Ethernet-маршрутизаторы и -коммутаторы.
Откуда есть пошла синхронизация или основы SDH
Давайте пару слов о прародителе — SDH. Еще лет 20 назад была безумно популярная технология. Synchronous Digital Hierarchy или Синхронная Цифровая Иерархия — это TDM система, в которой все элементы обязаны действовать синхронно.
Благодаря этому свойству каждый мультиплексор в сети знает, что только что пришедший бит относится, например, вот к этому виртуальному контейнеру VC-12 и его нужно выделить из общего потока уровня STM-1. Синхронность работы всех мультиплексоров позволяет выполнить магию мультиплексирования/демультиплексирования с картинки, которая так завораживала в институтские годы со страниц учебника Олиферов.
Синхронность достигается благодаря наличию в сети единого источника синхронизации частоты ПЗГ или ПЭГ (первичный задающий или эталонный генератор) или ВЗГ (вторичный задающий генератор). Крутость и стоимость источника, а также место в пищевой цепочке определяется его характеристиками стабильности и точности. У ПЗГ частота не должна уплывать на 10-11, а у ВЗГ на 10-8.
Эта опорная частота поступает от ПЗГ или ВЗГ на один из центральных мультиплексоров SDH, например, в виде электрического сигнала 2МГц. Мультиплексор подстраивает частоту своей микросхемы ФАПЧ (фазовая автоподстройка частоты) или на английском PLL (Phase-Locked Loop) под пришедшую частоту, после чего начинает вещать в такт задающему генератору на любых информационных скоростях от STM-1 до STM-256. Попутно в заголовки мультиплексорных секций (это один из видов служебных заголовков в SDH, типа как у нас Eth, VLAN и MPLS) помещаются информационные сообщения SSM (Synchronization Status Message), которые сообщают о качестве передаваемого сигнала. Нижестоящие мультиплексоры получают потоки с данными на свои порты, в заголовках смотрят содержимое SSM, смотрят свои собственные настройки (можно ли синхронизироваться от этого порта) и, если звезды сошлись, то подстраивают свои ФАПЧ/PLL под частоту пришедшего потока (вот прям под синусоиду). После чего начинают вещать нижестоящим мультиплексорам. Таким макаром единая частота распространяется по всей сети. В больших сетях время от времени необходимо ставить выделенные устройства ВЗГ, чтобы очистить и восстановить качество синхросигнала. В целом получается примерно такая схема синхронизации (ГСЭ на картинке — это генератор сетевого элемента)
Ну и для общего развития еще несколько занимательных моментов. Частота, на которой работает ФАПЧ/PLL мультиплексора SDH, равняется 19,44 МГц. Почему? Да потому что скорость минимального потока уровня STM-1 = 155,52 Мбит/с. А внутри мультиплексора биты в байте, видимо, обрабатываются параллельно, благодаря чему случается магия умножения герц на биты: 19,44МГц*8бит = 155,52 Мбит/с. Далее домножая на 4, 16, 64, 256 получается STM-4, STM-16, STM-64, STM-256. А заодно и WAN-PHY в Ethernet. К чему это было вообще? Да к тому, что когда все посыпется и вы на маршрутизаторе Juniper увидите в логе строчку типа
craftd[10980]: %DAEMON-4: Major alarm set, CB 0 19.44 MHz clock failure
то, по крайней мере, сможете провести коллективу краткий экскурс в историю этой частоты и рассказать, к чему примерно оно относится. А починится как-нибудь само)
Еще из занимательных фактов стоит отметить, что единая частота в рамках сети SDH обязательно нужна для работоспособности внутри одного сферического оператора в вакууме. Если разные операторы SDH между собой не взаимодействуют на уровне STM, то синхриться об одинаковую частоту им нет никакой нужды. Они прекрасно сделают это в асинхронном плезиохронном режиме на уровне потоков E1, которые относятся к PDH (некий аналог Opt. A для пакетных сетей). А уже при вводе потока E1 в иерархию STM будет произведена буферизация и бит-стаффинг для выравнивания скоростей/частот.
Но если операторы все же взаимодействуют на уровнях STM, то здесь должна возникнуть иерархия систем сихронизации, нужно выбрать чья система будет главной, а чья подчиненной. Насколько я понял, самая главная сеть - у Ростелекома, все остальные при желании могут засинхриться об него (не знаю бесплатная ли это услуга). Кроме того, есть вариант установить ПЗГ у оператора с получением частоты от GPS/Глонасс, которая, правда, нынче не везде доступна.
И всё это большой синхромир со своими законами, лезть в который не очень-то и хочется.)
Виды синхронизации
Синхронизацию можно описать как процесс приведения задающих генераторов разных устройств к единой частоте/фазе, дополнительно можно задать время суток. Если хотите, заставить биться железные сердца в унисон. Приводить к единому знаменателю можно все параметры, а можно выборочные. Так, например, протокол NTP в меру возможностей устанавливает одинаковое время суток (ToD – time of day), протокол SyncE работает только над унификацией частоты, а PTP умеет вообще все: передавать время суток, выравнивать как частоту (не очень хорошо), так и фазу (очень хорошо). Когда мы говорим о синхронизации в сетях, то в первую очередь речь идет о синхронизации частоты и фазы.
В несинхронных сетях, коими по определению являются Ethernet, длительность импульсов отправляемых в сеть разными устройствами разная, просто потому что их тактовые генераторы работают с разной погрешностью и ничего друг о друге не знают. 1Гбит/с на двух разных устройствах никогда не будут равны ровно 1Гбит/с: условно, на одном это будет 1,00001 Гбит/с, а на другом 1,00002 Гбит/с. Потребителям, например, базовым станциям или потокам E1, которым единая частота необходима как воздух, это категорически не подходит.
Задачу выравнивания частоты (или длины волны) сигналов помогут решить протоколы частотной синхронизации (SyncE или PTP). Понятно, что на 1Гбит/с и 10Гбит/с длительность импульса будет отличаться, но их соотношение в рамках всей сети должно стать одинаковым и постоянным. Самому Ethernet’у от синхронизация в масштабах сети по-прежнему ни тепло, ни холодно, но благодаря синхронности всех маршрутизаторов мы можем баловать нуждающихся в этом потребителей.
В живой природе большинству потребителей достаточно именно частотной синхронизации (SDH, PDH, базовые станции FDD, фиксированная телефония и пр). Но есть страждущие, которые требуют, чтобы не только совпадала длительность, но и начало импульса. Это называется фазовая или временная синхронизация. С ней блестяще справляется протокол PTP. Более того, он может бонусом доставить на каждое устройство еще и время суток.
Есть разные потребители фазовой синхронизации. В мобильных сетях это базовые станции LTE TDD, 5G. В финансах это биржи. В телевидении это синхронизация камер сопровождающих спортивные мероприятия, когда режиссеру нужно показать повтор момента со всех ракурсов.
И еще важный момент, в иностранной литературе все эти генераторы называются емким словом clock. У них это часы. Ну и в разрезе синхронизации фаза=время≠время суток.
Synchronous Ethernet или SyncE
Как говорилось выше, SyncE - это калька с SDH, адаптированная для Ethernet. Главный смысл в том, чтобы заставить все маршрутизаторы и коммутаторы в сети вещать на одной частоте. Для нас, пакетных сетевиков, технология SyncE состоит из двух основных компонентов: сигнальных сообщений, передаваемых протоколом ESMC (Ethernet Synchronization Messaging Channel), и самого по себе синхросигнала. Чуть позже рассмотрим суть обмана технологии, как этим пользоваться в своих интересах и где можно прилипнуть.
Итак, начнем. Пакетная сеть должна строиться по тем же лекалам, что и SDH. Должен быть источник синхронизации (желательно выделенный), в длинных цепочках могут быть ВЗГ (для очистки сигнала от jitter и wander) и, конечно, есть сетевые элементы. Желательно соблюдать ограничение на количество элементов в линии без ВЗГ не более 20 штук для обеспечения качества синхросигнала. Ниже на картинке изображена преемственность архитектуры в православных сетях SDH, пиндосьих SONET и лучших в мире SyncE.
Кратенько о типах элементов:
PRC (Primary Reference Clock) – первичный задающий генератор. Как правило стоит в ядре сети. Получает время со спутника, крайне стабилен.
SSU (Synchronization supply unit) – вторичный задающий генератор. Если есть, то стоит где-нибудь на крупном узле и занимается восстановлением синхросигнала. Также как и PRC является специализированным устройством с очень точными параметрами.
EEC (Ethernet equipment clocks)/SEC (SDH Equipment Slave clock) – непосредственно маршрутизаторы Ethernet или мультиплексоры SDH/SONET.
В реальных Ethernet сетях схема будет иметь скорее вырожденный вид и в ней будут присутствовать PRC/SSU и EEC. Ну хотя бы потому, что не только лишь все в пакетных сетях понимают, что делают, для чего это нужно, а главное строят сети по наитию, а не под чутким руководством специализированных вендоров, обложившихся ГОСТами и приборами для измерения. И будут правы... До тех пор, пока ГРЧЦ не выдаст в одном регионе одну частоту под LTE TDD или 5G двум операторам. Вот тогда-то все и запрыгают)
Давайте еще глянем на важную картинку сравнения обычного Ethernet и SyncE.
Как видим, устройства в ламповом Ethernet работают от внутренних генераторов, точность которых ±100ppm. А те же самые маршрутизаторы, но с поддержкой SyncE, работают, во-первых, в такт единому источнику частоты PRC, а, во-вторых, делают это с точностью ±4,6ppm. Что означают эти ppm? Фактически, это аналог процентов. Только проценты - это сотые доли, а ppm — миллионные (part per million). Для лучшего понимания давайте посчитаем насколько убегут или отстанут часы за сутки, если в них будут генераторы частоты аналогичной точности.
100ppm = 100 / 1000000 = 0,0001 4,6ppm = 4,6 / 1000000 = 0,0000046
В сутках у нас
60 секунд * 60 минут * 24 часа = 86400 секунд
Для 100ppm за сутки часы ошибутся на
86400 * 0,0001 = 8,64 секунды (убегут на минуту всего за неделю)
Для 4,6ppm за сутки часы ошибутся на
86400 * 0,0000046 = 0,4 секунды (чтобы убежать на минуту, им потребуется почти полгода)
Чтобы быть ближе к нашим сетям, давайте посчитаем, что означает точность 100ppm для 1G линка:
1 000 000 000 бит/с * 0,0001 = 100000 бит/с
Т.е. точность передачи случайно взятого коммутатора на гиговом линке 1Гбит/с ± 100 кбит/с. Этак за сутки при полной загрузке может набежать ±8640 Мбит.
Кстати, именно эта математика лежит в основе любых наручных часов. Например, умным часам не особо требуется иметь в своем составе хороший тактовый генератор: они постоянно подключаются по блюпупу к телефону и берут точное время оттуда. А вот Rolix обязаны иметь такой генератор, иначе их придется часто подводить.
В отличие от узлов EEC/SEC для PRC и SSU точность измеряется в ppb – частях на миллиард. И это намного круче.
Физический уровень SyncE
Давайте посмотрим на схему работы SyncE.
Из картинки не очень понятно, но маршрутизатор с поддержкой SyncE (EEC) имеет на борту отдельный чип (ФАПЧ/PLL), который синхронизируется от PRC (на картинке Master) и так далее по цепочке, как в SDH. Данные о частоте он берет из приходящего сигнала. Т.е. сигнал от соседа несет не только информационный поток (обычные кадры и пакеты), но и данные о частоте. И вот тут наступает волнительный момент срывания покровов... Нам всё врут!1!!1 Никакого такого волшебного Synchronous Ethernet на физическом уровне не существует! Нет никаких особенных синусоид и сигналов. Маршрутизатор или коммутатор берет пришедшую от соседа частоту несущей и тупо синхрится об нее. Ну т.е. буквально на порт пришел какой-то кадр Eth/IP/UDP/VXLAN. Он его передает по стеку вверх на обработку с PHY на MAC, LLC, IP-подуровни (синяя линия на картинке) и в то же время заворачивает эту же несущую c PHY на ФАПЧ/PLL, которые выполняют постоянную подстройку под пришедшую частоту. Эта частота становится задающей для исходящих портов, и все порты начинают работать с опорой на эту частоту. Изменилась частота выдаваемая PRC — изменится частота работы всех маршрутизаторов в сети. Собственно, так и выполняется синхронизация на физическом уровне. И это прекрасно! Синхронизация берется не из пакета с данными на канальном уровне, а из частоты несущей на физическом уровне. Данный вид синхронизации никак не зависит от нагрузки и наличия/отсутствия трафика в линии, от QoS – вообще ни от чего. Лишь бы линк горел.
Почему-то не так просто найти в интернете картинку, а как же выглядит логическая схема внутри маршрутизатора. Вот самое близкое из простого, что удалось отыскать.
Тут и SyncE, и PTP. Слева на вход поступает сигнал SyncE, дальше оно залетает в черный чип, отвечающий за синхронизацию, откуда уже растекается по маршрутизатору обратно на порты, а также на отдельные служебные выходы 125МГц и 1PPS.
Отсюда же вытекает крайне важное ограничение — все устройства в сети, через которые нужно передать SyncE, должны его поддерживать. Нельзя посредине воткнуть коммутатор или релейку и надеяться, что все заработает. У каждой железки должен быть специализированный чип, который отвечает за синхронизацию устройства. Его наличие нужно узнавать в спецификации. Там же можно отыскать информацию, требуется ли лицензирование этого функционала. Например, у хуавея требуется, а у джуна не очень.
Лично до меня момент с отсутствием отдельной волшебной частоты под SyncE дошел далеко не сразу, потому что были устаревшие знания в одном вопросе: а как же происходит синхронизация, когда в канале не передаются пакеты? Ну т.е. в линии тишина. Обо что синхриться, когда нет несущей? Последний раз, когда я детально интересовался физическим уровнем, лет 15-20 назад, в ходу еще были Half-Duplex, 10Base-T и куча проблем с ними. В 10Base-T, когда пакеты в линию не передаются, возникает состояние IDLE и тишина, лишь изредка нарушаемая сигналами проверки целостности линии NLP (Normal Line Pulse) – этакий железный heartbeat или keepalive.
Все хорошо, но в моменты передачи и тишины возникает переменная частота, что рушит и так хрупкую картину мира. Для устранения белого пятна пришлось посмотреть, что же произошло дальше. А там оказалось, что уже в 100Base-TX (и во всем, что выше: 1000Base, 10G и пр.) состояние IDLE предусмотрительно превратили в непрерывно отправляемый служебный символ IDLE, который выглядит как «11111». Т.е. сейчас в линии нет молчания. Как только закончилась передача пакета, сразу же начинает лететь символ IDLE. А об это уже можно синхронизироваться сколько влезет (а вот 10Base остался непригоден для этого).
Для пущей надежности попросил ребят подключить осциллограф к медному гиговому линку, чтобы посмотреть, как же это выглядит на практике. Действительно, никакого молчания, всегда какая-то IDLE-движуха на линке без трафика.
Так что с физикой вопрос оказался почти закрыт. Остается уточнить пару моментиков про среду передачи. А именно, нужно учитывать, что SyncE великолепно передается через оптические модули и поддерживается всеми вендорами. Лазер светит в волокно, на другом конце фотодиод детектирует луч, отсюда легко восстанавливается несущая. А вот с медью есть какие-то проблемы. Например, на вполне современных девайсах Huawei, как минимум, на прием SyncE не поддерживается на медных портах. Пример диагностического вывода с хуавеины, в котором порт Gi0/2/31 как раз медный и в работе SyncE как будто не участвует, хотя сигнальные пакеты (Out-SSM) в него якобы уходят.
<Huawei>display clock source System trace source State: lock mode into pull-in range Current system trace source: GE0/2/0 Current 2M-1 trace source: system PLL Frequency lock success: yes Master board Source Pri(sys/2m-1) In-SSM Out-SSM State Ref ------------------------------------------------------------------------------ GE0/2/2 2 /--- dnu prc normal * yes GE0/2/0 1 /--- prc dnu normal yes GE0/2/24 ---/--- dnu prc abnormal(ssm) no GE0/2/31 ---/--- dnu prc abnormal(phy) no
Еще бают, что работоспособность SyncE возможна только на специализированных медных модулях SFP с поддержкой этого функционала. Интернет отказался доступно для неспециалистов в электронике объяснить причины этого явления. Упоминаются разные факторы, как то: одновременный прием и передача сигнала по 4 жилам, вычитание исходного сигнала, необходимость согласования основного и ведущего порта на линке и пр. вещи, которые сложно связать воедино слабо подкованному в тематике уму. Очевидно, нужна помощь зрительного зала для детального установления истины в этом вопросе.
Насколько мне удалось понять, на входном порту маршрутизатора находится чип, который восстанавливает частоту исходного сигнала — CDR (Clock and Data Recovery). Частота, полученная CDR, улетает в PLL. Вот прям как на картинке
Но в случае с медными SFP функционал CDR вынесен с порта внутрь модуля и что-то там не срастается. Точно также, возможно, могли бы возникать проблемы с модулями XFP, ведь в них тоже встроен функционал CDR. Вот, например, ломающая сознание статья об особенностях режимов WAN/LAN для XFP-плат Juniper.
Логический уровень SyncE
С физической частью больмень разобрались. Запомнили, что для SyncE желательно использовать оптические модули; что ведомое устройство синхронизируется об тот же самый сигнал, в котором передаются данные; и, что неплохо бы соблюдать ограничения из стандарта на длину цепочки в 20 маршрутизаторов. Но у технологии есть и вторая сторона — логическая. Она отвечает за распространение сигнальной информации об источниках синхронизации, их качестве и его изменении, поломках в сети и разрыве петель синхронизации. Встречайте — протокол ESMC - Ethernet Synchronization Message Channel. У него две главные функции:
рассылка сообщений SSM - Synchronization Status Message, в которых передается информация об источнике;
отслеживание отсутствия сообщений SSM, чтобы исключить источник даже при наличии несущей (если, например, на удаленной стороне отключили протокол).
Данные протокола ESMС передаются на канальном уровне на мультикастовый мак-адрес 01-80-C2-00-00-02. Естественно, для такого узкоспециализированного протокола своего кода в Ethertype предусмотрено не было и его завернули в Slow Protocols (наравне с LACP и OAM). Но и там ему места не досталось и его инкапсулировали в OSSP — Organization Specific Slow Protocol. Формат сообщений имеет простейший и, как всегда в этих схемах, нечитаемый вид
Поэтому мы не будем ломать глаза и сразу посмотрим на пару дампов с сети. Почему-то Wireshark тот же самый пакет может показать предельно понятно
Разворачиваем начинку и видим идеальный протокол, который фактически переносит только одно значение — информацию о качестве получаемого синхросигнала.
В данном случае девайс сообщает, что он вещает с качеством EEC/SEC, т.е. находится на внутреннем источнике. Все остальные поля значения не имеют, т.к. не меняются. Хотя, на самом деле можно выпендриться, включить поддержку Extended QL TLV и тогда полетят не только TLV 1 типа, но и TLV 2 типа, которые понесут расширенную информацию.
Применения им в своей практике я пока не нашел, поэтому особо не интересовался, но знаю, что там появились дополнительные интересные поля, например:
SyncE ClockId - информация об источнике;
Сascaded EECs - информация позволяющая бдить за количеством EEC в цепочке, чтоб не надрываться и не считать количество элементов на пути через traceroute. На самом деле функция может быть довольна полезной для техподдержки. Например, когда оператор уверяет, что у него в цепочке 5 L2 коммутаторов, но «ниче не работает». Traceroute не запустишь, схемы ни у кого нет, доступ тоже не дают. И чтобы не верить на слово можно просто снять дамп и показать, что у вас в цепочке не 5, а 25 коммутаторов, поэтому качество и страдает.
Если возвращаться к нашим реалиям, то нас должно интересовать только поле SSM Code с информацией о качестве сигнала. У него весьма скромное количество значений, которое берется из таблички.
Табличка отсортирована по мере падения качества получаемого синхросигнала. Вверху самое высокое, внизу самое низкое. В левой колонке список кодов, а столбцы Option-I и Option-II делят эти коды между системами SDH и SONET. Фактически, например, QL-PRS и QL-PRC это одно и тоже — синхронизация от ПЭГ, но чтобы не было пересечений между системами, им расписали отдельные коды. SyncE без разницы с какой кодировкой работать. Но в наших широтах всегда используется Option-I. Это обязательная настройка, дабы девайс мог понять, на какой фене ему ботать в какой системе координат ему жить. А значит коды, которые могут встретиться на практике, - это QL-PRC, QL-SSU-A, QL-SSU-B, QL-SEC/QL-EEC1, QL-DNU. Чтобы убедиться воочию, вот такой коллаж из дампов вашему вниманию
Сразу хотелось бы предупредить, что если начальник покажет на вас пальцем, и вы после этого резко превратитесь в ценного специалиста по синхронизации, то отсидеться в своей пакетной песочнице не удастся: скорее всего возникнет необходимость общения с SDHыми людьми, ведь именно к их ПЭГ или ВЗГ вы будете подключать свой SyncE. И вот когда будете меряться качествами синхры, и они будут вам говорить про какие-то g.811, а вы им в ответ про PRC, знайте — это все одно и тоже, просто разными словами. Чтобы быстрее прийти к общему знаменателю используйте табличку
С кодами примерно понятно, но есть один самый важный — QL-DNU (1111) или Do Not Use. Благодаря ему производится разрыв петель синхронизации. В общем виде настройки на железке выглядят следующим образом: мы руками указываем с каких портов можно принять синхру и на какие ее отдать. «Принять и отдать» в разрезе SyncE означает прием и отправку пакетов ESMC. Как правило, на прием+передачу настраиваются аплинковские порты (те же, где и mpls). Это логично, ведь только через них можно попасть к ядру сети, где стоит источник. И только на отдачу настраиваются все остальные порты с потребителями. А в случае с Juniper есть удобная настройка — отдавать ESMC на все порты, чтобы больше не вспоминать об этом вопросе.
set chassis synchronization source interfaces et-1/1/1 priority 1 set chassis synchronization source interfaces et-1/1/2 priority 2 set chassis synchronization esmc-transmit interfaces all
Можно, конечно, руками перечислить в какие порты отдавать синхру, а в какие нет (на хуавее так), но на джунах всем лень и смысла в этом кроилове никакого. Ну разве что не дать какому-нибудь абоненту на халяву засинхриться от вашей сети)
На практике такая настройка могла бы означать, например, что через порт et-1/1/1 мы получили качество QL-PRC, засинхрились об него и начали рассылать во все порты свое сообщение c качеством QL-PRC, в т.ч. в порт et-1/1/1. Естественно, в этом случае возникает петля синхронизации. Вышестоящая железка может решить, что вот он сигнал, которого я ждала всю жизнь, и засинхриться об него.
Чтобы предотвратить развитие такой ситуации, можно было бы вообще перестать слать в порт, избранный источником, сообщения ESMC. Но разработчики избрали другой путь. Согласно стандарту система шлёт в этот порт код QL-DNU, который прямо запрещает использовать его для синхронизации.
Фактически мы видим классический метод расщепления горизонта. Рассылаем информацию о великолепном качестве во все порты
кроме того, с которого его приняли. Туда шлем QL-DNU – не использовать. Петли нет, мы победили.
Немного конфигов и диагностики
Давайте уже на что-то более реальное посмотрим. Возьмем топологию с небольшим колечком, настроим его на использование SyncE и посмотрим на коды SSM, которые разлетаются по сети. Держать в тайне не буду, все сразу на схеме.
Router1 по задумке автора подключен к самому главному источнику PRC. На нем на прием настроен только один порт. Минимальная достаточная глобальная конфигурация для любой железки на хуавее состоит из пары строчек:
clock ethernet-synchronization enable | включаем SyncE глобально (запускаем в работу ФАПЧ/PLL) |
clock ssm-control on | включаем обработку сообщений протокола SSM (SyncE может работать и без SSM, но об этом попозже) |
У джуна на пару кнопок сложнее:
set chassis synchronization network-option option-1 | выбираем коды SSM а-ля SDH |
set chassis synchronization selection-mode received-quality | доверяем качеству в кодах SSM в полученных ESMC |
set chassis synchronization clock-mode auto-select | включаем возможность выбора внешнего источника (подключаем ФАПЧ/PLL) |
set chassis synchronization quality-mode-enable | включаем выбор источника на основе лучшего QL |
set chassis synchronization esmc-transmit interfaces all | включаем рассылку пакетов ESMC на все порты |
Ну и дальше остается вколотить одну-две настройки на портах и все зажужжит. На хуавее:
interface GigabitEthernet0/9/2 | |
clock synchronization enable | включаем посылку ESMC на порту |
clock priority 1 | включаем прием ESMC и назначаем приоритет порта |
На джуне достаточно указать только порты, с которых будем синхриться:
set chassis synchronization source interfaces xe-3/1/3 priority 1
Поздравляю, повторив подобные настройки на остальных маршрутизаторах, скорее всего на этом моменте у вас все заработало, теперь вы батя SyncE. На самом деле есть еще довольно много функций типа задержки возврата к предыдущему источнику после пропадания, минимально допустимое качество, ожидаемое качество, контроль качества, мапинг качества на свое усмотрение, но это все второстепенное и должно привязываться к условиям конкретной сети.
Также крайне важно понимать, что наша железка может засинхириться об какое угодно качество, если оно выше нашего. А в ручном режиме нет и этой условности. Т.е. QL-PRC – это хорошее пожелание, но QL-SSU не особо-то и хуже — ПЗГ и ВЗГ это специализированные девайсы, которыми управляют специальные синхролюди и они плохого не пришлют (ну почти). А вот синхриться об SEC/EEC смысла нет — это примерно такой же маршрутизатор, который не видит специализированного источника, но и такая опция вполне доступна.
И ещё из действительно важного — вам необходимо уметь правильно расставлять приоритеты в жизни сети и работать с лагами. Все-таки, несмотря на возможность разрывать петли, протокол требует ручного планирования, как минимум для того, чтобы трассы SyncE и будущего PTP совпадали и шли кратчайшими путями. Вернемся к нашей картинке сети, выдернем кусочек и посмотрим на приоритеты.
Чем ниже priority, тем более высокоранговый самецприоритетный порт. Router2 и Router4 синхрятся с портов слева с Pri1, в ответ шлют туда QL-DNU для разрывания петли. Друг в друга же они смотрят с настройкой priority 2 и кидаются качеством QL-PRC, но эти сообщения никуда дальше не улетают, их просто принимают к сведению «ваш звонок очень важен для нас».
Но, как только, например, Router2 перестанет получать QL-PRC слева, как правило из-за обрыва, он начнет синхронизироваться об Router4 и схема синхронизации и сигнализации участка сети изменится
Процесс выбора источника в общем случае состоит из трех шагов:
выбрать соседей с лучшим доступным качеством (PRC/SSU/SEC);
из соседей c лучшим качеством выбрать соседа с наименьшим приоритетом;
среди одинаковых приоритетов выбирается наименьший номер порта.
Если хочется быть чуточку более научным, то общая процедура выбора источника и синхронизации изображена вот туточки (в Reference Selector режим Mode 2).
А давайте-ка еще посмотрим, как эта вся писанина выглядит в жизни. Что приятно, команда для диагностики всего SyncE, как правило, одна. На хуавее это
<Huawei>display clock source System trace source State: lock mode into pull-in range Current system trace source: GE0/2/0 Current 2M-1 trace source: system PLL Frequency lock success: yes Master board Source Pri(sys/2m-1) In-SSM Out-SSM State Ref ------------------------------------------------------------------------------ GE0/2/15 2 /--- prc prc normal * yes GE0/2/0 1 /--- prc dnu normal yes GE0/2/1 3 /--- dnu prc normal * yes GE0/2/2 ---/--- dnu prc normal * no GE0/2/3 ---/--- dnu prc normal * no GE0/2/4 ---/--- dnu prc normal * no GE0/2/5 ---/--- dnu prc normal * no GE0/2/6 4 /--- dnu prc normal * yes GE0/2/16 ---/--- dnu prc abnormal(ssm) no GE0/2/17 ---/--- dnu prc abnormal(ssm) no GE0/2/18 ---/--- dnu prc abnormal(ssm) no GE0/2/19 ---/--- dnu prc abnormal(ssm) no GE0/2/20 ---/--- dnu prc abnormal(ssm) no GE0/2/21 ---/--- dnu prc abnormal(ssm) no GE0/2/22 ---/--- dnu prc abnormal(ssm) no GE0/2/23 ---/--- dnu prc abnormal(ssm) no GE0/2/24 ---/--- dnu prc abnormal(ssm) no GE0/2/25 ---/--- dnu prc abnormal(ssm) no GE0/2/8 ---/--- dnu prc initial no GE0/2/27 ---/--- dnu prc normal * no GE0/2/7 ---/--- dnu prc normal * no GE0/2/14 ---/--- prc prc normal * no GE0/2/31 ---/--- dnu prc abnormal(phy) no
Это реальная железка, повидавшая всякое дерьмо к которой подключено много всего — маршрутизаторов и базовых станций. В колонке State светятся разные значения:
abnormal (ssm) – значит, что оттуда не приходят пакеты ESMC и там, вероятно, живет потребитель;
normal – значит оттуда какие-то ESMC прилетают;
initial – порт лежит;
abnormal(phy) — SyncE не поддерживается, т.к. порт медный.
Портам с ненулевым значением Pri мы назначили приоритеты и следовательно включили прием ESMC от соседей. Как видим из колонки In-SSM, качество PRC приходит на 3 порта: Gi0/2/0, Gi0/2/15, Gi0/2/14. Они прошли первый этап отбора. Далее выбираем порт с меньшим Pri. У порта Gi0/2/14 priority не задан, в дальнейших выборах он не участвует, поэтому давай до свидания. Из двух оставшихся победителем оказался Gi0/2/0. Это можно увидеть в начале вывода «Current system trace source: GE0/2/0», ну или определить по колонке Out-SSM — это единственный порт, куда мы шлем DNU. Во все остальные рассылается PRC. Кстати, видите в колонке In-SSM почти со всех портов летит DNU? В совокупности со state = normal становится понятно, какие соседские железки засинхирились об нас. Единственное исключение — сосед на порту Gi0/2/14 - он берет синхру откуда-то из другого места.
На джунах диагностика тоже не особо сложная.
Juniper>show chassis synchronization Current clock status : Locked Clock locked to : Primary SNMP trap status : Disabled Configured sources: Source Configured Interface Configured Configured Name Priority Status Quality bundle xe-2/0/0 3 n/a PRC xe-2/0/1 2 Primary PRC
Расширенный вывод детально показывает, что происходит с портами-источниками.
Juniper>show chassis synchronization extensive Current clock status : Locked Clock locked to : Primary SNMP trap status : Disabled Configured sources: Interface : xe-2/0/0 Status : n/a Index : 185 Clock source state : n/a Priority : 3 Configured QL : PRC ESMC QL : DNU Clock source type : ifd Clock Event : n/a Wait-to-restore : 5 min Hold-off : 1000 ms Interface State : Up,ESMC TX(QL PRC/SSM 0x2), Ineligibility reason: Undefined/invalid QL, Interface : xe-2/0/1 Status : Primary Index : 186 Clock source state : Clk qualified Priority : 2 Configured QL : PRC ESMC QL : PRC Clock source type : ifd Clock Event : Clock locked Wait-to-restore : 5 min Hold-off : 1000 ms Interface State : Up,pri,ESMC Rx(QL PRC/SSM 0x2),ESMC TX(QL DNU/SSM 0xf)
Вот и вся диагностика. Хотя нет, само главно-то забыл. Все делается ради одной единственной цели — увидеть заветное слово LOCK. Оно означает, что источник выбран, и наша железка засинхрилась. Вообще для простоты будем считать, что у синхронизируемых девайсов есть три состояния:
Free-run – железка живет на внутреннем генераторе и никогда не видела ничего другого. Девайс будет слать в соседей качество не выше EEC/SEC.
Lock – самое желанное состояние. Железкин чип ФАПЧ/PLL прошел подстройку и полностью выровнял свою частоту с соседом. Об этом состоянии часто говорят «залочился» и это равносильно «синхронизировался». Термин пришел из электроники, поэтому нам он может резать слух. Его надо просто смиренно принять. Именно в этом состоянии девайс сможет слать соседям качество QL-PRC (и любое другое), об которое он засинхрился.
Holdover – режим удержания. Сосед потерялся, и железка снова работает на внутреннем генераторе. Как правило, она переходит к рассылке качества EEC/SEC.
Конечный автомат перехода между состояниями выглядит примерно так
Теперь про лаги. Как говаривал, кажется, Борис Бритва: «лаги — это хорошо, лаги — это надежно». Возьмем вот такую схему
У Router1 отломился источник с Priority 1. И он резко засинхрился об источник с Priority3, т.к. оттуда прилетало качество QL-PRC. Петля во всей красе. На практике она может и не произойдет, т. к. момент потери текущего источника детектируется, и внутри чипа начинается процесс переключения на новый источник. Но логически это однозначно проблема. Чтобы побороть эту ситуацию, обозначим принадлежность порта к лагу внутри процесса SyncE. Тогда девайс Router2 будет понимать, что за этим портом тот же самый источник, и будет слать ему QL-DNU, вместо QL-PRC.
Настройки под это дело выглядят несложно
set chassis synchronization source interfaces xe-1/0/0 priority 1 set chassis synchronization source interfaces xe-1/0/0 aggregated-ether ae1 set chassis synchronization source interfaces xe-1/0/1 priority 3 set chassis synchronization source interfaces xe-1/0/1 aggregated-ether ae1 set chassis synchronization source interfaces xe-2/0/2 priority 2
На джуне точно нужно учитывать нюансик при расстановке приоритетов. В качестве источника синхры маршрутизатор умеет назначать основной и «квалифицированный» резервный порт. Точно не знаю что означает «квалифицированный» с т.з. PLL, возможно измеряется стабильность частоты (если кто подскажет - добавлю в статью). При падении основного источника переключение на квалифицированный, по наблюдениям, производится очень быстро. А вот переключение между квалифицированным и неквалифицированным (3 приоритет и далее) производится уже долго (секунды). Т.о. если основной и квалифицированный порты будут в одном лаге и он упадет, то получим нежелательный перерывчик. И таки выгоднее иметь квалифицированный порт вне лага. В настройках выше порты xe-1/0/0 и xe-1/0/1 находятся в одном лаге, но у одного из них приоритет ниже, чем у постороннего xe-2/0/2.
Глянем диагностику этого момента. В сжатом виде можно увидеть только то, что мы правильно наконфигурили
Juniper> show chassis synchronization Current clock status : Locked Clock locked to : Primary SNMP trap status : Disabled Configured sources: Source Configured Interface Configured Configured Name Priority Status Quality bundle xe-1/0/0 1 Primary PRC ae1 xe-1/0/1 3 n/a PRC ae1 xe-2/0/2 2 Secondary PRC
В расширенном виде информации значительно больше
Juniper> show chassis synchronization extensive Current clock status : Locked Clock locked to : Primary SNMP trap status : Disabled Configured sources: Interface : xe-1/0/0 SyncE Bundle: ae1 Status : Primary Index : 295 Clock source state : Clk qualified Priority : 1 Configured QL : PRC ESMC QL : PRC Clock source type : ifd Clock Event : Clock locked Wait-to-restore : 5 min Hold-off : 1000 ms Interface State : Up,pri,ESMC Rx(QL PRC/SSM 0x2),ESMC TX(QL DNU/SSM 0xf), Interface : xe-1/0/1 SyncE Bundle: ae1 Status : n/a Index : 296 Clock source state : n/a Priority : 3 Configured QL : PRC ESMC QL : PRC Clock source type : ifd Clock Event : n/a Wait-to-restore : 5 min Hold-off : 1000 ms Interface State : Up,ESMC Rx(QL PRC/SSM 0x2),ESMC TX(QL DNU/SSM 0xf), Interface : xe-2/0/2 Status : Secondary Index : 298 Clock source state : Clk qualified Priority : 2 Configured QL : PRC ESMC QL : PRC Clock source type : ifd Clock Event : Clock qualified Wait-to-restore : 5 min Hold-off : 1000 ms Interface State : Up,sec,ESMC Rx(QL PRC/SSM 0x2),ESMC TX(QL PRC/SSM 0x2),
Порты xe-1/0/0 и xe-2/0/2 в поле Clock Event помечены основным и квалифицированным. Порты xe-1/0/0 и xe-1/0/1 помечены принадлежностью к одну лагу и, как говорилось выше, железка шлет в оба порта одного лага QL-DNU, разрывая потенциальную петлю.
На хуавее логика такая же. Обратите внимание, что номер eth-trunk (5) и clock bundle (6) могут быть разными, это ни на что не влияет. Типы, что кодили софт для SyncE, были не в курсе за кусок кода для eth-trunk. Короче eth-trunk нумеруются с нуля, а clock bundl’ы с единицы) Поэтому нумерация сбивается.
interface GigabitEthernet0/3/12 eth-trunk 5 clock synchronization enable clock priority 1 clock bundle 6 interface GigabitEthernet0/3/13 eth-trunk 5 clock synchronization enable clock priority 1 clock bundle 6 <Huawei>display clock source System trace source State: lock mode into pull-in range Current system trace source: GE0/3/12 Current 2M-1 trace source: system PLL Frequency lock success: yes Master board Source Pri(sys/2m-1) In-SSM Out-SSM State Ref ------------------------------------------------------------------------------ GE0/3/12 1 /--- prc dnu normal yes GE0/3/13 1 /--- prc dnu normal * yes
В лаге 2 порта, залочились мы об Gi0/3/12. Оба порта в лаге возвращают назад качество QL-DNU.
SyncE через DWDM
В рамках этой статьи я уже достаточно оттоптался грязными кирзачами по темам, которые мне не близки. Поэтому от меня не убудет, если еще и по DWDM пройдусь)
В современных сетях связь между маршрутизаторами может осуществляться как по т.н. темной оптике (прямые волокна), так и через системы спектрального уплотнения DWDM (это когда в одном волокне живет много независимых потребителей, разнесенных в простейшем случае на разные длины волн, называемые лямбдами). На мой взгляд, можно выделить три вида/поколения DWDM:
«пассивные»
«активные»
OTN
Каждый следующий вид использует все наработки предыдущих.
Пассивные DWDM — это, условно, когда в порты маршрутизатора, подключенного к DWDM, вставлены цветные SFP, сразу излучающие на нужной длине волны. DWDM в этом случае представляет собой набор проводочков и зеркал, которые запихивают (MUX) свет разных длин волн от разных маршрутизаторов в одно воловко, а с другой стороны также выводят (DEMUX). Т.е. в DWDM сразу поступают разноцветные сигналы (лямбды).
Активные DWDM — преобразуют пришедший сигнал в нужную длину волны, после чего точно также запихивают разные лямбды в одно волокно. Т.е. на сей раз в маршрутизатор вставлены самые дешевые модули, светящие на стандартных длинах волн. Точно такие же стоят в DWDM. Вся магия преобразования длины волны осуществляется на устройстве под названием транспондер. Именно оно осуществляет OEO – оптико-электронное-оптическое преобразование и выдает на оптический мультиплексор разные лямбды. В одну лямбду запихивает только один клиентский сигнал. Это может быть 1G, 10G, 100G, STM-1 и пр.
Вершиной развития на сегодняшний день является DWDM OTN. Такое ощущение, что парни, которые занимались SDH, глядя на стремительно удаляющийся в закат Ethernet, в один момент поняли, что такими темпами они скоро останутся не то что без славы, денег и женщин, но даже без работы. По телеку в тот день показывали «Карты, деньги, два ствола». А потом вышли «Джентельмены». И их осенило: если как Гай Ричи снимать один и тот же крутой фильм, то фильм каждый раз будет иметь успех. И они изобрели SDH заново! Только теперь вместо потоков E1 придумали мультиплексировать физические каналы. И назвали это OTN - Optical Transport Network. Чертовски хитро с их стороны!
Сначала эффективно в кучку собирается как можно больше низкоскоростных каналов от абонентов и уже этому групповому сигналу выделяется отдельная длина волны. Таким образом в одну лямбду можно запихнуть не 1 гигабитный канал, а 100 штук от разных абонентов (ну ладно, не 100, а 80). Действительно прорывная технология.
Схема мультиплексирования ничего не напоминает?) На мой взгляд, технология получилась настолько крутой, что мне теперь не совсем понятно, зачем нужны пакетные сети. Но я стараюсь об этом помалкивать, чтобы самому не остаться у разбитого пакетного корыта)
Так вот, применительно к нашим синхронизационным делишкам это может добавить немало сложностей. Если «пассивный» DWDM никаких неприятностей доставить по определению не может, то с «активным» и OTN могут быть нюансики. И имя им — 3R и OTN mapping.
3R это:
Re-Amplification — восстановление амплитуды;
Re-Shaping — восстановление формы;
Re-Timing — восстановление синхронизации.
Именно последняя “R” ломает нам синхру, когда пришедший сигнал проходит ресинхронизацию на базе внутреннего источника мультиплексора.
В пассивной системе мы получаем от маршрутизатора готовый луч света на нужной длине и просто направляем его в общий световой пучок. В активной системе транспондером выполняется OEO-преобразование, в ходе которого выполняется 3R – восстановление амплитуды, формы и частоты сигнала. Ну в целом оно и логично — на больших расстояниях все параметры уплывают. Но маршрутизатор от мультиплексора может стоять в нескольких метрах, нет смысла использовать мощные алгоритмы восстановления, как на дистанциях в сотни километров. В этом случае можно обойтись 2R – амплитудой и формой. Такой режим вроде бы называется Transparent и в нем передача SyncE осуществляется абсолютно прозрачно.
Когда речь заходит об OTN – это гарантировано проблемы. Мультиплексор OTN занимается тем, что помещает биты клиентской нагрузки в контейнеры. Эти контейнеры имеют строго заданные места размещения в структуре кадра OTU.
Структура в развернутом виде, мягко говоря, внушает
Если расслабиться и довериться транспондеру, то он будет подавать контейнеры под загрузку на основе собственного внутреннего тактового генератора. Если частота канала абонента не особо совпадает с частотой транспондера, то будет выполняться процедура байт-стаффинга (подпихивание дополнительных бит или передача пустоты), которая будет искусственным образом выравнивать частоты маршрутизатора и транспондера. После передачи через DWDM на удаленном конце клиентский канал будет точно также изъят из кадра OTU, преобразован в нужную длину волны и отдан абоненту. И вот здесь наступает развязка. Фактически мы потеряли исходную частоту SyncE на входе в DWDM OTN и синхронизируемся теперь от модуля XFP в составе транспондера на удаленной стороне. Какую частоту он выделил из потока, такую мы и получим. И это совсем не то, что мы ждем от SyncE. При этом на канальном уровне пакеты ESMC как ходили так и ходят — DWDM прозрачен для данных.
Для решения этой проблемы в рукаве есть пара козырей. Можно, например, наладить синхронизацию элементов DWDM по служебному каналу OSC (Optical Supervisory Channel). В первую очередь он интересен для передачи PTP, но об нем в следующий раз.
Другим решением является правильный выбор метода отображения клиентской нагрузки. В OTN вводить нагрузку в структуру кадра можно разными способами:
BMP (Bit-Synchronous Mapping)
AMP (Asynchronous Mapping)
GMP (Generic Mapping Procedure)
Познания мои в этом вопросе крайне скудны, но практика показывает, что для 10G линков сохранить частоту может BMP. Каким образом в этом случае осуществляется синхронизация скоростей маршрутизатора и транспондера OTN остается загадкой. Видимо они должны быть засинхронизированы от одного источника. Вот здесь и здесь дядечка кратко поясняет за BMP, через слово упоминая стандарт G.709 на 290 страниц. Читать все мы, конечно же, не будем, но поиском попытать счастье по ключевым словам 10GBase, BMP, ODU2e стоит.
Логическая цепочка выстраивается примерно такая. Стандарт рекомендует отображать 10G в контейнеры ODU2e и делать это методом BMP.
Частота модуля OTN, ответственного за подачу контейнеров OPU2e/ODU2e, должна быть выровнена с клиентским сигналом. Разница в информационных скоростях компенсируется заполнителем фиксированной длины.
Выравнивать скорости предлагается загнав клиентскую частоту в транспондер.
В общем какая-никая база для баттлов совместной продуктивной работы с DWDMщиками есть, можно пробовать, успехов вам и хорошего настроения)
Баги, фичи и тайны
Ну и в оконцовке хочется еще раз пробежаться по ключевым параметрам и аспектам в понимании протокола.
Самое главное: инженер, помни, физически никакого SyncE не существует! Берется сигнал с одного из линков и об него производится синхронизация. За автоматический поиск источников, построение структуры сети, обеспечение резервирования отвечает протокол ESMC. Тем не менее, ряд параметров нужно задать в ручную, самый главный — указать доверенные порты-источники.
Но, как мы видели на примере DWDM, передаваемая протоколом ESMC информация о качестве (SSM) фактически никак не связана с реальностью, творящейся на физическом уровне. Если соединить два маршрутизатора через релейки, настроенные в режиме туннелирования (сквозной пропуск трафика без коммутации), то сообщения ESMC спокойно пролетят сквозь них. А вот исходная частота передана не будет. Т.е. удаленный маршрутизатор благодаря ESMC будет думать, что ему присылают эталонный сигнал. Но вместо этого он будет синхриться об внутренний генератор дальней релейки, который наверняка имеет характеристику ±100ppm, вместо требуемых ±4,6ppm. Внимательнее с промежуточной трансмиссией. Все устройства на пути должны поддерживать протокол, иначе всё зря!
С другой стороны, не только лишь все знают, что SyncE на узле можно запустить в полностью ручном режиме на основе приоритетов, игнорируя показания ESMC. Не хочется учить вас плохому, но иногда это крайне необходимо. На хуавее для этого достаточно на порту подменить качество получаемого сигнала.
interface GigabitEthernet0/3/13 clock synchronization enable clock priority 1 clock ssm ssub <Huawei>dis clo source System trace source State: lock mode into pull-in range Current system trace source: GE0/3/13 Current 2M-1 trace source: system PLL Frequency lock success: yes Master board Source Pri(sys/2m-1) In-SSM Out-SSM State Ref ------------------------------------------------------------------------------ GE0/3/13 1 /--- ssub dnu normal yes GE0/3/11 ---/--- dnu ssub abnormal(ssm) no
Более того, удаленная сторона может вообще быть не в курсе про SyncE и никаких ESMC не присылать. В данном случае мы просто в ручном режиме синхримся об частоту с любого порта. На джуне так тоже можно сделать.
На хуавее важно знать о глобальной команде и не использовать ее, если она не нужна.
<Huawei>clock input-threshold ? dnu DNU eprc G.811.1 eprtc G.8272.1 esec G.8262.1 prc G.811 prtc G.8272 sec SDH ssua G.812 tranfer node clock ssub G.812 local node clock
Она управляет минимально допустимым уровнем качества от источника синхры. Если выставить PRC, то железка будет синхриться только от портов с уровнем PRC. Если таких портов не будет, то девайс уйдет в Holdover. А, например, протокол PTP это не устроит. С другой стороны, она гарантирует, что качество синхронизации в сети будет не хуже определенного уровня. На джуне есть такая же команда и работает примерно также.
На хуавее есть фича clock freq-deviation-detect enable. Детектирование стабильности частоты источника. Позволяет, например, находить глючные модули, у которых от перегрева, замерзания или вообще по жизни уплывает частота. Правда делает это по-варварски через падение синхры. Чтобы функционалом воспользоваться, появляется вторая диагностическая команда. Обычно вывод выглядит примерно так
<Huawei>display clock source freq-deviation Frequency deviation detect: enable Source Freq-deviation-value ---------------------------------------------------------- GE0/2/16 --- * GE0/2/0 0.05ppm(normal)
Но если много и усердно повторять команду, то можно увидеть это
<Huawei>display clock source freq-deviation Frequency deviation detect: enable Source Freq-deviation-value ---------------------------------------------------------- GE0/2/16 --- * GE0/2/0 -1638.34ppm(abnormal)
Наблюдаем, что в нормальной жизни частота источника после синхронизации расходится с нашей на 0,05ppm, это норма. Но бывают всплески до 1600ppm (это капец как много, больше похоже на какие-то замирания или выключения модуля). В этот момент источник помечается некачественным и железка уходит в Holdover. При этом SSM в ESMC стабильно идут о высочайшем качестве PRC. Если функцию отключить, то подобные выбросы будут игнорироваться, и все будет нормально работать. Потому что PLL умеет фильтровать такие штуки, и сам по себе физический процесс подстройки частоты занимает какое-то время. Как говорится, меньше знаешь, крепче спишь) На джуне такой команды нет и уровень кортизола инженерам эксплуатации ничто не повышает.
Вообще, несмотря на внешнюю предельную простоту технологии, на практике могут встретиться довольно много нюансов в аппаратной части. Дело в том, что это не классический пакетный протокол, а фактически отдельный чип от неких поставщиков, который присрали припаяли к плате и с горем пополам реализовали какую-никакую работоспособность. И вот как его адаптировали, так оно и работает с множеством подводных камней. У хуавея попроще и получше. Видимо, сказывается, что львиная доля бизнеса у них связана с мобильной сетью, где это категорически необходимо и они хорошо понимают, зачем это делают. У джуна все значительно сложнее и хуже, и выглядит так, что сделано на отъестань.
Особую осторожность нужно проявлять при работе с многоюнитовыми устройствами, у них довольно много особенностей. Например, у Juniper распространенная плата MCP3D-16GE вроде научилась раздавать SyncE, но не работает с PTP. На каких-то платах основной и квалифицированный порты должны жить либо на четных, либо на нечетных портах одного MPC. На разных поколениях SCB разные подходы реализации и т.д. и т. п. Чтобы все заработало как надо, придется обложиться документацией)
Ну все, хватит уже. Когда я начинал статью, то рассчитывал в этот объем уместить SyncE и все виды PTP. И уж точно никак не мог подумать, что фантомный протокол с одним простейшим сигнальным сообщением затянется на 30 страниц. Не обессудьте, встретимся в следующей части про PTPv2 с упором на G.8275.1. Постараюсь быть а не казаться кратче.
Интересное на почитать
Цискина обзорная статья по синхре
Даташит на какой-то чип синхронизации с картинками
Сайт хуавея
https://support.huawei.com/enterprise/en/doc/EDOC1100367122/f0aeb4e7/clock-and-time-synchronization
Сайт джуна (там много всего написано, замаешься читать)
Полная панамка ограничений для джуна
Учебник по современному SDH
https://books.ifmo.ru/file/pdf/1362.pdf
Короткие заметки по OTN
https://sierrahardwaredesign.com/optical-transport-networks/glossary-item-mapping-procedures-otn/
