Проприетарный протокол что это

Новое слово: проприетарный

Что означает слово «проприетарный»? Нет ли у него в русском языке адекватного синонима?

Чаще всего это прилагательное вкупе с существительным «проприетарность» используется в околокомпьютерной тематике, по отношению к программным или аппаратным продуктам. Буквально английское proprietary значит «собственнический; частный», от латинского proprius — «владение, собственность». Проприетарность часто противопоставляется открытости, и с одной стороны эти понятия действительно антагонистичны, однако тут нужно сделать важное замечание. Например, широко распространено мнение, будто все программы с открытым кодом, распространяемые бесплатно — не проприетарны. Это большое заблуждение. Существует множество продуктов, права на которые принадлежат вполне определённым лицам, но при этом они вовсе не обязательно платные и с закрытым исходным кодом (хотя большинство из них, не будем лукавить, именно такие).

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

Источник

Свой криптографический протокол — опасная идея

Разработка своей криптографии в чём-то сравнима с созданием собственного авиадвигателя, говорит эксперт по безопасности Руна Сандвик. Фото: Виталий Кузьмин

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

Казалось бы, почему не использовать открытые стандарты типа WebSocket и JSON, зачем собственный закрытый протокол? На это обычно приводят ряд причин. Во-первых, для безопасности, чтобы его было сложнее отреверсить и никто не понял, какие данные вы передаёте. Во-вторых, для эффективности. У нас ведь уникальный случай использования, поэтому стандартные решения — не самые оптимальные. Наш собственный протокол будет работать с меньшими задержками, потреблять меньше трафика и меньше расходовать батарею (на мобильных устройствах). И третья причина — функции. В своём протоколе специально для нашего приложения мы реализуем уникальные возможности, каких нет ни в открытом стандарте, ни у конкурентов.

Это распространённые причины, из-за которых разрабатывают проприетарные протоколы.

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

Поговорим о безопасности.

Любой безопасник скажет, что протокол должен быть закрытым. Это важно для защиты от конкурентов. И от клиентов тоже. Чем меньше клиент знает о протоколе — тем меньше он контролирует систему, приложение. Вся власть остаётся в руках разработчика. Система полностью под контролем производителя, то есть вас. Соответственно, клиент навечно привязан к вам по обслуживанию, он не сможет ничего поломать в аппаратуре или софте. Он вообще побоится туда сунуться, потому что там ничего не понятно. Всё обфусцировано, зашифровано и написано на непонятном языке. Классика.

На Хабре частенько упоминают реверс-инжиниринг протоколов в различных устройствах: автомобили, тракторы, даже машины для производства мороженого. Производители этой техники стараются скрыть технические данные ради безопасности. Чтобы глупые пользователи не совали шаловливые ручки внутрь.

Например, важной частью бизнеса многих компаний является сервис и техническое обслуживание. Поэтому некая компания, скажем, системный интегратор предпочтёт вместо стандартных Open Source решений внедрить клиенту проприетарный софт с собственным закрытым протоколом. И всё. После этого она будет «доить» клиента десятилетиями.

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

В общем, проприетарный протокол кажется очень выгодным для фирмы.

Но жизнь иногда показывает обратное. А именно:

Принцип «безопасность через неясность» не работает в криптографии

Принцип «безопасность через неясность» (security through obscurity) заключается в том, чтобы скрыть внутреннее устройство системы или реализацию для обеспечения безопасности.

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

Сравните с опенсорсными системами, где разработчик специально открывает код, чтобы независимые сторонние эксперты помогли выявить и исправить эти недостатки.

В итоге получается, что собственный проприетарный протокол, максимально закрытый от посторонних глаз и обфусцированный, вовсе не увеличивает безопасность системы, а уменьшает её!

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

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

Собственная криптография

Вопрос «Почему не разработать собственную криптографию?» чем-то похож на вопрос «Почему не спроектировать авиадвигатель?», говорит Руна Сандвик, исследователь по безопасности. Конечно, теоретически мы можем это сделать. Но это чрезвычайно сложно. Гораздо более простой и надёжный вариант — выбрать готовое решение, проверенные и надёжные протоколы и алгоритмы.

Поэтому в сообществе информационной безопасности вызывает большое подозрение, если какая-то компания реализует собственный проприетарный протокол. Например, проприетарный протокол MTProto в Telegram поначалу вызвал массу критических отзывов. Взлом MTProto 1.0 стал одной из самых популярных статей на Хабре в 2013 году: «Безопасен ли Telegram? Или как я искал закладку в MTProto» (спойлер: глупые ошибки в проприетарной криптографии).

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

К тому же, в мессенджере запрещена анонимная регистрация без номера телефона — вероятно, так удобнее коммерческой компании, чтобы блокировать спам и продвигать приложение по адресным книгам. Кто будет думать об анонимности, когда на кону миллиарды долларов прибыли? При этом Telegram изначально позиционировали именно как «безопасный» мессенджер (многие пользователи купились на такую рекламу).

В реальности для обеспечения анонимности нужно регистрироваться по анонимной сим-карте, но не все это понимают. См. также советы «Как защитить свой аккаунт в Telegram» и «Практическое руководство по анонимности в онлайне».

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

Конечно, в опенсорсе есть свои специфические риски. Например, проблемы с сотнями зависимостей, которые вы не контролируете. Например, 20% багов в проектах на GitHub явно внесены в проекты специально, со злым умыслом. То есть вредоносными контрибуторами, которые действовали умышленно. Ещё не забыта история c мейнтейнером ESLint, который 12 июля 2018 года опубликовал вредоносные версии пакетов eslint-scope и eslint-config-eslint в репозитории npm.

Такое может случиться с каждым опенсорсным проектом, потому что мейнтейнеры работают бесплатно, на износ:

Но все проблемы безопасности решаемы. Независимый аудит открытого кода профессиональными экспертами — лучшая гарантия его надёжности.

Кстати, в 2013 году проприетарный софт впервые обогнал опенсорсные проекты по среднему количеству багов на 1000 строк кода.

Источник: Coverity Scan Open Source Report

В прошлом веке считалось, что проприетарный софт пишут профессионалы, а Open Source — любители. Сегодня же профессиональный уровень опенсорсных программ вовсе не уступает проприетарным. Может, даже превосходит их.

Возвращаясь к примеру Telegram. 5 декабря 2020 года двое итальянских математиков Марино Микулан и Никола Витоколонна опубликовали на сайте препринтов arXiv.org исследование «Автоматическая символическая проверка протокола MTProto 2.0 в Telegram» (вторая версия опубликована 30 апреля 2021 года, arXiv:2012.03141v1). Оно подтверждает безопасность обновлённой версии фирменного протокола MTProto 2.0.

Набор протоколов MTProto 2.0 (в голубой рамке) и область покрытия данной научной работы (светло-зелёным цветом). Схема из научной статьи Марино Микулана и Никола Витоколонны, arXiv:2012.03141v1

Статья содержит «полностью автоматизированное доказательство надёжности аутентификации MTProto 2.0, обычного чата, зашифрованного end-to-end чата и механизмов повторного ввода ключей в отношении нескольких свойств безопасности, включая аутентификацию, целостность, конфиденциальность и совершенную прямую секретность», а также «доказывает формальную корректность MTProto 2.0».

Протокол аутентификации MTProto 2.0. Здесь означает асимметричное шифрование открытым ключом . В свою очередь, означает симметричное шифрование общим ключом с вектором инициализации . Схема из научной статьи

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

Эта математическая работа чуть ослабила озабоченность экспертов по поводу проприетарного протокола MTProto 2.0. Редкий случай, когда собственная нестандартная криптографическая система (пока) работает надёжно. В ней ещё не нашли таких фатальных уязвимостей, как в MTProto 1.0.

Неужели разработчики Telegram всё-таки научились — и смогли сделать уникальный «авиадвигатель» без ошибок? Можно только порадоваться за них, ведь все пользователи Telegram участвовали в этом «обучении» как бета-тестеры. В каком-то смысле это наш общий успех.

На правах рекламы

Наша компания предлагает серверы с Linux или Windows. Не экономим на железе — только современное оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить!

Источник

Там, где Wi-Fi не справляется. Применение проприетарных беспроводных технологий в промышленности и не только

Вдохновившись интересом к моему посту по проводным промышленным сетям, хочу продолжить свои изыскания и рассказать о беспроводных технологиях. Существует множество сценариев беспроводных подключений, где самые распространённые технологии – Wi-Fi и LTE не вполне справляются. В этих случаях стоит обратиться к проприетарным беспроводным технологиям. Одним из таких решений под названием Ultra-Reliable Wireless Backhaul недавно обзавелась компания Cisco. Предлагаю в нем разобраться, посмотреть где такие решения применяются – вместо или вместе с стандартными технологиями, и как там устроена передача данных.

Для чего это нужно?

Решение Cisco Ultra-Reliable Wireless Backhaul выросло из продуктов приобретённого компанией Cisco производителя FluidMesh. Оно призвано обеспечить высокоскоростную беспроводную передачу данных на большие расстояния на стационарных и движущихся объектах.
Несмотря на наличие в названии слова Wireless, важно не путать его с привычным Wi-Fi. В сетях Wi-Fi у нас есть точки доступа и стандартизованные клиентские устройства – ноутбуки, смартфоны, планшеты. Бывает, что вместо клиентского устройства подключается ещё одна точка доступа – получается Wi-Fi-мост, из мостов можно составить Mesh-сеть, но это не совсем то, для чего Wi-Fi придуман и не то, где он проявляет себя лучше всего.

В случае с Ultra-Reliable Wireless Backhaul клиентских устройств у нас нет. Есть только устройства, которые умеют принимать и передавать данные по специальной проприетарной технологии. Для того, чтобы подключить клиентское устройство, необходимо использовать Ethernet-коммутатор и/или точку доступа Wi-Fi, подключив их к устройству Ultra-Reliable Wireless Backhaul кабелем.

Проще всего представить, что нам нужно соединить некие локации высокоскоростным кабелем, но протягивать его дорого, сложно или, в случае с подвижными объектами, невозможно. Поэтому мы ставим приёмопередатчики и делаем этот «кабель» беспроводным. Получается опорная сеть, в англоязычной терминологии — Wireless Backhaul.

Примеры использования

Стационарное соединение «точка-точка»

Самый простой пример всё тот же: вам нужно подключить новое здание на территории, скажем, завода к общей сети, а оптику туда прокладывать дорого и долго. Мост, построенный на оборудовании Cisco, позволит быстро и дёшево обеспечить подключение до 500Мбит/с. Если необходимо, можно поставить две пары устройств и получить 1Гбит/с.

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

Стационарное соединение «точка-многоточка»

Здесь хороший пример – подключение камер видеонаблюдения на территории вокруг основного здания – управления завода, торгового центра и т.п. Камеры чаще всего устанавливаются на фонарные столбы, где электропитание уже подведено ради самих фонарей, а вот с подведением Ethernet-кабеля возникает вопрос. Чтобы этого избежать – можно ставить вместе с камерами простейшие устройства Ultra-Reliable Wireless Backhaul и с каждого столба передавать данные на устройства, установленные на здание.

Транспортные средства и другие мобильные объекты

Особенности технологии Cisco Unified Wireless Backhaul, о которых пойдёт речь чуть ниже, позволяют обеспечивать очень высокое качество связи с подвижными объектами.

— На предприятиях, добывающих полезные ископаемые открытым способом с её помощью организуется связь для сбора данных телеметрии и местоположения с карьерной техники. По периметру карьера устанавливаются стационарные устройства Cisco Unified Wireless Backhaul с антеннами, направленными внутрь карьера, а на технике – мобильные с всенаправленными антеннами. Пропускной способности при этом хватает даже для передачи видео с камер, установленных на машинах.

— В шахтах Ultra Reliable Wireless Backhaul может быть использован для организации связи с машинами или поездами, ходящими внутри. Схема аналогичная: ряд стационарных устройств ставится в тоннеле для обеспечения покрытия, а мобильные устойства – на технике. Для шахт могут быть интересны и варианты стационарного использования: раздача Wi-Fi для работников, использующих планшеты, телефоны, радиометки, сбор данных и управление автоматикой – вентиляция, устройства SCADA и т.д.

— Связь между «землёй» и обычным пассажирским поездом: для раздачи Wi-Fi и сбора данных видеонаблюдения в последнем.

— Внутри железнодорожного состава Wireless Backhaul может быть использован для обеспечения связи между вагонами: два устройства устанавливаются в разных вагонах со специальными антеннами, направленными друг на друга.

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

Зачем нужно проприетарное решение?

Кажется, что все описанные выше задачи можно решить с помощью обычного Wi-Fi, а для ситуаций, где необходима передача данных на большие расстояния – LTE. Однако возникает целый ряд проблем:

Как устроено?

Решение Ultra-Reliable Wireless Backhaul не единственное в своём роде в том смысле, что и другие производители предлагают реализации опорных сетей на базе проприетарных протоколов беспроводной передачи данных. В чём особенность Wireless Backhaul?

“Физика” от Wi-Fi

Физический уровень передачи данных реализован на чипах, полностью аналогичных тем, что используются в устройствах Wi-Fi последнего поколения (IEEE 802.11ax). Это значит, что и частоты, и каналы передачи данных используются те же самые, а значит, с точки зрения регулирующих органов, установка устройства FluidMesh выглядит также, как установка точки доступа, вещающей в нелицензируемом диапазоне 5ГГц.
В отличие от обычного Wi-Fi, физика Ultra-Reliable Wireless Backhaul даже на очень больших расстояниях способна обеспечивать MIMO.

«Логика» от операторских сетей связи

На канальном и сетевом уровнях в решении Ultra-Reliable Wireless Bakchaul используется протокол под названием PRODIGY 2.0, основанный на MPLS. MPLS – это технология передачи данных в сетях операторов связи, обеспечивающая высокую производительность и хорошую управляемость таких сетей. Использование такого протокола позволяет обеспечить качество обработки трафика – прежде всего, предсказуемую задержку передачи, которая так важна для аудио, видео и телеметрии реального времени. Для приоритетных приложений обеспечивается задержка меньше 0.3мс.

Пропускная способность

Доступная пропускная способность соединения «точка-точка» — до 500Мбит/с. Устройства Ultra-Reliable Wireless Backhaul умеют выбирать DataRate так, чтобы он не менялся непредсказуемо при изменении расстояния или хендовере, как это происходит в Wi-Fi-сетях.

Действительно бесшовный хендовер

Протокол PRODIGY 2.0 имеет продвинутые механизмы хендовера – переключения с одной базовой станции на другую. В обычном Wi-Fi переключение происходит следующим образом: при падении соотношения шум/сигнал ниже порогового значения клиентское устройство переключается на другую доступную точку доступа с максимальным соотношением шум/сигнал. При этом это клиентское устройство ничего не знает о том, насколько хорошо будет работать связь с новой точкой. Кроме того, как уже говорилось выше, чтобы переключиться на новую точку ему необходимо сначала разорвать соединение с предыдущей, то есть существует промежуток времени, хоть и короткий, в течение которого данные передаваться не могут. Даже при так называемом «бесшовном» хендовере. В протоколе PRODIGY 2.0 на устройствах Ultra-Reliable Wireless Backhaul переключение реализовано иначе: обмениваясь данными с текущей базовой станцией, устройство ищет вторую доступную, устанавливает с ней соединение, тестирует его и только потом переключает в него поток данных.

Перестроение Mesh-сети при отказе

Mesh-сети строятся из некоторого количества беспроводных точек доступа или базовых станций, передающих данные от одной к другой. В случае отказа одного из устройств, его соседи должны оперативно перестроить передачу данных через другие доступные, если это возможно. Сеть Ultra-Reliable Wireless перестраивается менее чем за 500мс.

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

Здесь всё просто: помимо встроенных механизмов шифрования трафика с помощью AES, передача данных с использованием проприетарного протокола остаётся невидимой для анализаторов Wi-Fi. Подменить базовую станцию, чтобы подключиться к вашей сети, у злоумышленника тоже не получится – от этого защищает механизм аутентификации.
От попыток заглушить сеть шумами защищает механизм автоматической смены частот (Frequency Hopping).

Поддержка PROFINET

Ultra Reliable Wireless Backhaul умеет правильно передавать пакеты, относящиеся к работе распространённого протокола промышленной автоматизации PROFINET. Применение технологии допускается и в сетях PROFINET Conformance Class B.

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

С простыми случаями, вроде соединений «точка-точка» всё понятно. Структуру же большой сети Ultra Reliable Wireless Backhaul, проще всего понять по аналогии с Wi-Fi.

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

Шлюзы (Gateway) выполняют агрегацию MPLS трафика и являются его точкой выхода в сеть предприятия. Шлюзы не обязательная составляющая решения, поскольку они не являются беспроводным контроллером в понимании Wi-Fi решений. Каждая базовая станция может выполнять роль шлюза, но ограничена пропускной способностью в 500 Мбит/с. Если необходима суммарная пропускная способность выше 500 Мбит/с, тогда нужна установка шлюза. Шлюзы доступны для пропускной способности 1 Гбит/с и 10 Гбит/с.

Дополнительно ко всему этому прилагается система мониторинга FM-Monitor и система управления RACER – аналог в Wi-Fi – Cisco Prime Infrastructure или DNA Center.

Здесь аналогия с Wi-Fi-заканчивается. В плане взаимодействия точек доступа между собой сеть больше похожа на проводные Ethernet-сети:

Источник

Подробности реализации протоколов RSTP и проприетарного Extended Ring Redundancy

В сети можно найти много материалов про протокол RSTP. В рамках данной статьи я предлагаю сравнить протокол RSTP с проприетарным протоколом от Phoenix Contact – Extended Ring Redundancy.

Подробности реализации RSTP

Время сходимости – 1-10 c
Возможные топологии – любая

Распространено мнение, что RSTP позволяет объединить коммутаторы только в кольцо:

Но RSTP позволяет соединять коммутаторы произвольным образом. Например, с такой топологией RSTP справится.

RSTP сводит любую топологию к дереву. Один из коммутаторов становится центром топологии – корневым коммутатором. Корневой коммутатор пропускает через себя наибольшее количество данных.

Принцип действия RSTP следующий:

Коммутаторы с RSTP обмениваются BPDU-пакетами. BPDU – это сервисный пакет, который содержит информацию RSTP. BPDU бывает двух типов:

После включения все коммутаторы считают себя корневыми. Они начинают передавать пакеты BPDU. Как только коммутатор получает BPDU с меньшим Bridge ID, чем его собственный, он перестает считать себя корневым.

Bridge ID состоит из двух значений – MAC-адрес и Bridge Priority. MAC-адрес мы поменять не можем. Bridge Priority по умолчанию равен 32768. Если не менять Bridge Priority, то корневым станет коммутатор с наименьшим MAC-адресом. Коммутатор с наименьшим MAC-адресом — это самый старый и, возможно, не самый производительный. Рекомендуется вручную определить корневой коммутатор топологии. Для этого на корневом коммутаторе необходимо настроить маленький Bridge Priority (например, 0). Также можно определить резервный корневой коммутатор, задав ему чуть больший Bridge Priority (например, 4096).

Выбор пути до корневого коммутатора

Корневой коммутатор рассылает во все активные порты пакеты BPDU. BPDU имеет поле Path Cost. Path Cost обозначает стоимость пути. Чем выше стоимость пути, тем дольше по нему передается пакет. Когда BPDU проходит через порт, то в поле Path Cost добавляется стоимость. Добавленное число называется Port Cost.

К Path Cost добавляет определенное значение при прохождении BPDU через какой-либо порт. То значение, которое добавляет называется стоимостью порта (Port Cost) и может быть определено как вручную, так и автоматически. Port Cost может быть определено как вручную, так и автоматически.

Когда некорневой коммутатор имеет несколько альтернативных путей до корневого, то он выбирает наиболее быстрый. Он сравнивает Path Cost этих путей. Тот порт, с которого пришел BPDU с наименьшим Path Cost становится корневым (Root Port).

Стоимости портов, которые присваиваются автоматически можно посмотреть в таблице:

Роли и статусы портов

Порты коммутатора имеют несколько статусов и ролей портов.

Статусы портов (для STP):

Статусы портов (для RSTP):

В первую очередь давайте определим, что такое сегмент LAN. Сегмент LAN – это коллизионный домен. Для коммутатора или маршрутизатора каждый порт образует отдельный коллизионный домен. Сегмент LAN – канал между коммутаторами или маршрутизаторами. Если говорить про хаб, то у хаба все порты находятся в одном коллизионном домене.

На один сегмент назначается только один Designated Port.

В случае с сегментами, где уже есть Root Port’ы, все понятно. Второй порт сегмента становится Designated Port.

Но остаются резервные каналы, где будет один Designated Port и один Alternate Port. Каким образом они будут выбираться? Designated Port станет порт с наименьшим Path Cost до корневого коммутатора. Если Path Cost равны, то Designated Port будет тот порт, который размещается на коммутаторе с наименьшим Bridge ID. Если и Bridge ID равны, то Designated Port становится порт с наименьшим номером. Второй порт будет Alternate.

Остался последний момент: когда порту назначается роль Backup? Как уже писалось выше, Backup port используется только в том случае, когда два канала коммутатора подключены к одному сегменту, то есть к хабу. В этом случае Designated Port выбирается точно по тем же самым критериям:

Стандарт IEEE 802.1D не предъявляет строгих требований по количеству устройств в ЛВС с RSTP. Но стандарт рекомендует использовать не более 7 коммутаторов в одной ветке (не более 7 хопов), т.е. не более 15 в кольце. При превышении этого значения начинает увеличиваться время сходимости сети.

Подробности реализации ERR.

Время схождения ERR – 15 мс. При максимальном количестве коммутаторов в кольце и наличии сопряжения колец – 18 мс.

ERR не позволяет свободно объединять устройства как RSTP. ERR имеет четкие топологии, которые можно использовать:

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

Двойное кольцо

Коммутаторы могут быть объединены в двойное кольцо, что значительно увеличивает надежность кольца.

Ограничения двойного кольца:

Сопряжение колец

При сопряжении в сети может быть не более 200 устройств.

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

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

При сопряжении через один коммутатор на устройстве задействуются оба порта. Время схождения в этом случае будет составлять примерно 15-17 мс. При таком сопряжении коммутатор сопряжения будет точкой отказа, т.к. потеряв этот коммутатор, теряется сразу все кольцо. Сопряжение через два коммутатора позволяет избежать этого.

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

Path Control

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

Эта функция позволяет сэкономить на резервном кабеле. Более того всегда будет известна используемая топология для траблшутинга.

Основная топология переключается на резервную за 15 мс. Обратное переключение при восстановлении сети будет занимать около 30 мс.

Принцип работы ERR

Для примера рассмотрим шесть коммутаторов – 1-6. Коммутаторы объединены в кольцо. Каждый коммутатор использует два порта для подключения к кольцу и хранит их статусы. Коммутаторы пересылают статусы портов друг другу. Эти данные устройства используют для установки исходного состояния портов.

У портов всего две роли – Blocked и Forwarding.

Коммутатор с наибольшим MAC-адресом блокирует у себя порт. Все остальные порты в кольце передают данные.

Если Blocked port перестает работать, то следующий порт с наибольшим MAC-адресом становится Blocked.

После загрузки коммутаторы начинают посылать Ring Protocol Data Unit (R-PDU). R-PDU передается с помощью multicast. R-PDU – это сервисное сообщение, как и BPDU в RSTP. R-PDU содержит статусы портов коммутатора и его MAC-адрес.

Алгоритм действий при отказе канала
Когда канал отказывает, коммутаторы посылают R-PDU для уведомления об изменении статуса портов.

Алгоритм действий при восстановлении канала
Когда отказавший канал вводится в работу, коммутаторы посылают R-PDU для уведомления об изменении статуса портов.

Коммутатор с наибольшим MAC-адресом становится новым корневым коммутатором.

Отказавший канал становится резервным.

После восстановления один из портов канала остается заблокированным, а второй переводится в состояние forwarding. Заблокированным портом становится порт с наибольшей скоростью. Если скорости равны, то заблокированным станет порт коммутатора с наибольшим MAC-адресом. Этот принцип позволяет заблокировать порт, который перейдет из состояния blocked в состояние forwarding с максимальной скоростью.

Максимальное количество устройств в сети

Максимальное количество коммутаторов в ERR кольце – 200.

Взаимодействие ERR и RSTP

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

ERR отлично подходит для организации типовых топологий. Например, кольцо или дублированное кольцо.

Подобные топологии часто применяются для резервирования на промышленных объектах.

Более того, при помощи ERR вторую топологию можно реализовать менее надежно, но более бюджетно. Это можно сделать при помощи дублированного кольца.

Но не всегда можно применить ERR. Бывают достаточно экзотические схемы. С одним из наших заказчиков мы тестировали следующую топологию.

В данном случае ERR применить не представляется возможным. Для такой схемы мы использовали RSTP. У заказчика было жесткое требование по времени сходимости – менее 3 с. Чтобы добиться этого времени необходимо было четко определить корневые коммутаторы (основной и резервный), а также стоимости портов в ручном режиме.

Как итог, ERR заметно выигрывает по времени сходимости, но не дает такой гибкости, которую дает RSTP.

Источник