Прежде чем читать эту статью, настоятельно рекомендую изучить официальную документацию! Ссылки в разделе “Источники”
Содержание
Вступление
Доброго времени суток случайный путник!
Сегодня я продолжаю свой нерегулярный и спонтанный цикл статей о сетевых технологиях. В прошлой такой статье я затронул тему защиты некольцевых топологий, однако темой той статьи был обзор механизмов loopback-detection и их работоспособности у разных вендоров.
Сегодня же я бы хотел рассмотреть технологию защиты именно кольцевой топологии. Так как я работаю в организации, где на транспортной сети используются коммутаторы Huawei и H3C, для защиты нашей топологии был выбран проприетарный протокол RRPP, поэтому именно его мы сегодня и рассмотрим.
Так как протокол поддерживается и Huawei и H3C, у каждого вендора своё видение документации по нему. Лучшая – у Huawei. Её емкость может показаться преимуществом, но в этом же и ее сложность. Не всё понятно сразу, а какой-то важный аспект может описываться одной строчкой где-то в середине полотна текста.
К сожалению, я еще не добрался до плотного изучения ERPS, так что досконально сравнить эти 2 протокола не смогу, но уверен, что принципы их функционирования очень похожи.
Этой статьей я хочу сделать памятку на будущее для себя, а так же для тех, кто так же страдал при его изучении.
Зачем использовать протоколы защиты кольцевой топологии?
Зачем, собственно, придумывать что-то новое, если у нас есть прекрасные протоколы семейства STP (RSTP, MSTP)?
В этой статье я не буду вдаваться в подробности их функционирования. Скажу лишь, что по своей архитектуре эти протоколы хорошо подходят для защиты отдельных сегментов сети на уровне доступа, например, где перерыв сервиса в 5-10-15 секунд будет практически незаметен.
В то же время кольцевые топологии встречаются, в основе своей, на транспортных сетях, для которых 5 секунд – это огромный временной промежуток, который почувствуют все участники, задействованные в этой сети.
Рассмотрим время сходимости классических протоколов на условной кольцевой сети из 5 узлов:
STP (802.1D)
Время сходимости: 30-50 секунд. На это влияет:
Max Age timer: 20 секунд (ожидание истечения BPDU)
Forward Delay: 15 секунд × 2 (Listening Learning)
Время растёт линейно с диаметром сети. Каждый дополнительный хоп добавляет задержку пересчёта.
Это совсем никуда не годится для High Availability.
RSTP (802.1w)
Время сходимости: 1-2 секунды.
Такого улучшения разработчики добились благодаря механизму proposal/agreement вместо таймеров в STP. Следует отметить, что все преимущества этого механизма могут использовать лишь тогда, когда все узлы в защищаемом сегменте поддерживают RSTP.
Время так же растет линейно с диаметром сети, но слабее. Однако, в кольце из 20 узлов RSTP может достичь 3-5 секунд
MSTP (802.1s)
Время сходимости: 1-2 секунды.
Использует те же механизмы что и RSTP, но его преимущество заключается в возможности гибкого управления трафиком.
RRPP (Huawei/H3C) и ERPS (G.8032)
Время сходимости: <50 миллисекунд
Я объединил эти 2 протокола в один пункт. Отмечу лишь, что RRPP — проприетарный протокол Huawei, а ERPS (G.8032) — стандарт ITU-T, появившийся позже. Принципы их функционирования во многом схожи, но это разные протоколы. Время сходимости практически не меняется с увеличением количества узлов.
Разница, как говорится, налицо. Кольцо, где есть только 2 направления (налево и направо) защитить проще, чем древовидную структуру.
Как работает RRPP?
Этот вопрос одновременно и очень прост и довольно сложен. Я условно поделю его на 2 части:
Работа в пределах одного кольца
Работа со смежными кольцами (subring)
Сразу оговорюсь — я не буду рассматривать технические подробности протокола, которые достаточно хорошо описаны в документации, такие как механизм перестроения mac таблиц, структура пакетов. Я рассмотрю именно принцип его функционирования. Поверьте, там всё тоже не так очевидно.
О схемах
Я бы и рад привести примеры с “родной” среды эмуляции H3C “H3C Lab” но она напрочь отказывается нормально эмулировать RRPP на дефолтных образах, поэтому будем импровизировать
Базовые понятия RRPP
RRPP домен (instance). Группа взаимосвязанных коммутаторов, с одинаковым идентификатором домена и номерами
Топология с двумя кольцами, имеющими общий линк. В имеющуюся топологию из A-B-C-D мы добавили еще один коммутатор E, соединив его линками с B и C, чтобы сформировалось еще одно кольцо (B-C-E).
Зачем нужны подкольца
Тут можно задаться вопросом – а зачем вообще нужны подкольца, можно выстроить все узлы в одно большое кольцо? И это будет абсолютно верный и рабочий способ. Подкольца нужны лишь для того, чтобы при каждом добавлении нового коммутатора в вашу топологию не перекраивать всё кольцо, ведь для добавления подкольца не нужен перерыв сервиса. Также, обрыв линка на подкольце не вызывает перестроения основного кольца, так что это может рассматриваться как ограничение зоны влияния инцидента.
Как основное, так и вторичные кольца могут состоять из любого количества узлов.
Control VLAN и Data VLAN. Как намекают названия, Control VLAN нужен для передачи сугубо служебных пакетов протокола RRPP, а Data VLAN – это список VLAN, которые участвуют в кольцевой топологии для передачи данных. То же самое что и в MSTP, он даже конфигурируется через stp-instance.
Control VLAN неявно состоит из двух VLAN. Когда мы конфигурируем Control VLAN (например, vlan 1000) автоматически создается второй subcontrol vlan по формуле control vlan 1 (1000 1 = 1001). Control VLAN используется для передачи служебных пакетов протокола по главному кольцу, в том время как subcontrol vlan используется для передачи пакетов протокола по вторичным кольцам.
У всех участников RRPP домена control vlan должен быть сконфигурирован одинаково, иначе пакеты не смогут пройти весь маршрут и кольцо не соберется.
Пакеты протокола в основном кольце передаются в control vlan и пакеты протокола во вторичных кольцах передаются в subcontrol vlan.
Важно! Пакеты протокола из вторичных подколец, передаются по главному кольцу как data vlan, а значит подвержены блокировке передачи как и data vlan на мастере главного кольца.. Это очень важный момент для функционирования протокола, а именно для функционирования подколец, рассмотрим этот аспект чуть позже.
Роли узлов. Как было сказано ранее, RRPP вводит роли узлов. Рассмотрим каждую.
Мастер. Мониторит состояние кольца и управляет передачей трафика. В каждом кольце может быть только один мастер. Мастером может быть назначен любой узел.
Транзитный узел. Транзитными узлами являются все остальные узлы кольца, за исключением мастера. Они обеспечивают передачу пакетов протокола (в первую очередь, health) и, что немаловажно, обеспечивают механизм оповещения мастера об обрыве. Пока оба физических интерфейса, принадлежащих кольцу находятся в UP – кольцо считается целым. Как только один из интерфейсов переходит в состояние DOWN, транзитный узел незамедлительно отправляет специальное сообщение о разрыве кольца через оставшийся в живых интерфейс мастеру. Мастер, получив такое сообщение, незамедлительно реагирует соответствующим образом.
Снова эта картинка
Линк между B и C является местом пересечения Ring 1 (Major) и Ring 2 (Subring). Без Edge Master Ring 2 (Switch E) не сможет понять, что кольцо действует и надо заблокировать свой второй интерфейс, что приведет к петле между C-B-E.
Пара Edge и Assistant Edge являются основой механизма управления подкольцами. Работают как передатчик (Edge) и приемник (Assistant Edge). Edge шлет специальное сообщение Edge-hello через оба своих интерфейса (в оба направления по кольцу), а Assistant Edge их получает. Суть этого механизма в том, что при обрыве общего линка (между B и C) главное кольцо самостоятельно восстанавливает связность кольца. Если при этом и мастер вторичного кольца разблокирует свой второй линк, то получится петля.
Если вы сейчас нифига не поняли, то не переживайте, первые 50 раз я тоже ничего не понял. Именно поэтому чуть позже я разберу этот случай по шагам и с картинками.
Роли интерфейсов. Главные роли интерфейсов – Первичный (Primary) и Вторичный (Secondary), так как в кольце у любого узла присутствуют только 2 направления.
Мастер кольца шлет Health пакеты через Первичный интерфейс и ожидает его на Вторичном интерфейсе.
В зависимости от состояния кольца, мастер блокирует или разблокирует свой вторичный интерфейс для обеспечения связности между всеми узлами кольца.
На транзитных узлах направление Первичных и Вторичных интерфейсов не имеет никакого значения, главное чтобы они принадлежали кольцу.
Дополнительные роли интерфейсов – Edge и Common (общий).
Edge интерфейс – это интерфейс узла с одноименной ролью, который “смотрит” в сторону подкольца. На нем разрешено прохождение только subcontrol vlan и data vlan.
Common (общий) интерфейс – это интерфейсы Edge и assistant edge, которые смотрят на общий между двумя кольцами участок. Common интерфейсы принадлежат одновременно и Control Vlan и subcontrol vlan.
Это значит, что пока жив прямой линк между Edge и Assitant Edge, health-пакеты подкольца. будут приоритетно ходить по схеме Subring Master – Edge – Assistant Edge или наоборот, в зависимости от того, как вы настроили роли
Таймеры. За работу кольца отвечают 3 таймера и все используются только мастером кольца.
Hello Timer – периодичность передачи мастером кольца Health-пакетов для мониторинга состояния кольца.
Fail Timer – death interval. Если в течении данного промежутка времени Hello из первичного интерфейса так и не был получен на вторичном, кольцо считается разорванным.
Huawei рекомендует устанавливать Fail Timer не менее чем Hello Timer x 3. Значения по умолчанию сложностей не вызывали.
Link Up Timer – этакий буфер при восстановлении кольца. Так как протокол имеет очень быструю сходимость, частое изменения состояние линков (флап) может серьезно повлиять на трафик в кольце. Поэтому мастер после обнаружения восстановления кольца (после его падения) не сразу начинает операцию по смене маршрута трафика, а спустя Link Up timer. В общем, попытка защититься от флапа линков в кольце и частых перестроений.
Edge-Hello Timer – специфический таймер для общения между Edge и Assistant Edge. Определяет, через какой промежуток времени считать связь с Edge разорванной.
Взаимодействие с STP. Его нет. Коммутатор не даст активировать RRPP на порту, на котором не выключен STP. Имейте ввиду.
Концепция
Представим себе сеть из 3 коммутаторов подключенных в кольцевую топологию. Пусть это будут коммутаторы A, B и C.
И нам нужно обеспечить работу данной топологии, не допустив образования петли.
На этом этапе RRPP вводит роли узлов. В кольце есть один мастер-узел, его роль конфигурируется вручную при настройке коммутатора. Пускай это будет коммутатор A
Мастер – единственный узел, принимающий решения относительно кольца. Он контролирует его состояние (оно всё еще кольцо или уже развалилось где-то?) и предпринимает меры в случае его “разваливания”. Остальные узлы в случае, когда кольцо одно являются транзитными. Эта настройка на них необходима для нормально функционирования детектирования обрыва.
Прежде чем мы рассмотрим как именно мастер всё это делает, необходимо упомянуть о том, что RRPP вводит также роли интерфейсов. У кольца есть два направления относительно узла — направо и налево, по часовой и против часовой, как угодно. Поэтому и у интерфейсов есть две роли – первичный и вторичный. Роли интерфейсам также выдаются вручную при конфигурировании протокола. Правильно выданные роли интерфейсов критически важны для мастера и почти неважны для остальных узлов.
Теперь, когда мы узнали что у узлов и их интерфейсов есть роли, рассмотрим как именно мастер контролирует целостность кольца и как именно он эту ситуацию обрабатывает.
Мастер периодически (очень часто) посылает специальный протокольный пакет через свой первичный интерфейс. Если этот пакет пришел к нему же через вторичный интерфейс, кольцо считается целым, и трафик должен передаваться только через один интерфейс, а вторичный интерфейс должен быть заблокирован для передачи обычного трафика, не позволяя обычному трафику закольцеваться, но всё еще открыт для служебных пакетов (чтобы этот самый служебный пакет мог быть обработан мастером).
Итак, согласно картинке выше, предположим что интерфейс FA0/1 является первичным, а fa0/2 вторичным для мастера. Через него он будет контролировать целостность кольца, и пока он получает этот пакет с другой стороны, передача данных по fa0/2 будет заблокирована, подобно STP Block.
Таким образом протокол не позволяет закольцеваться пользовательскому трафику.
Если в каком-либо месте кольца происходит обрыв, транзитные узлы (TRANSIT) оповещают мастера о том, что один из их линков упал, одновременно с этим мастер не получает своё же health сообщение через вторичный интерфейс и у него запускается death timer. Как только мастер понимает (каким-либо из этих путей) что кольцо разорвано, например, так:
Он разблокирует свой вторичный интерфейс (ведь кольцо уже и не кольцо вовсе и блокировка не нужна), восстанавливая связность, в данном случае, с коммутатором C:
Как только кольцо восстанавливается (мастер снова получает свои же health пакеты через вторичный интерфейс), всё возвращается на круги своя: мастер блокирует вторичный интерфейс, оставляя только один путь для трафика.
Каждое кольцо в домене действует по тому же самому алгоритму, независимо от их размера и количества. В каждом кольце есть свой master который контролирует целостность своего кольца и управляет своими первичным и вторичным линками.
Тонкости работы с несколькими кольцами будут освещены в детальном разборе функционирования протокола.
Рассмотрим, как RRPP работает при разных конфигурациях
Одно кольцо
Теперь, когда мы накачались теорией, давайте посмотрим как работают механизмы RRPP при различных конфигурациях сети. Начнем с простейшего примера в виде одного кольца:
Даже на этой картинке есть неоднозначный момент: синяя стрелочка имеет 2 направления, что принципиально неверно. Сообщения Hello выходят строго из первичного интерфейса мастера и приходят (или не приходят) строго во вторичный.
На этой картинке мы видим, что кольцо в порядке, все линки в UP. Master node посылает служебный пакет Hello (health) через свой Primary интерфейс, получает его на Secondary, понимает что кольцо в порядке и НЕ передает Data Packet через свой Secondary интерфейс, чтобы не получить петлю.
Но что случится, если где-то произойдет обрыв?
Снова не совсем корректная картинка. Связность между Switch A и Master Node не теряется, Data Packet будет доходить и до него тоже.
На этой картинке изображен механизм обнаружения транзитными узлами обрыва. Тут у нас произошел обрыв между Switch A и Switch B. Оба свича увидели, что их линк принадлежащий кольцу упал и немедленно отправили сообщение LINK-DOWN через оставшийся. Мастер, получив это сообщение от любого из этих узлов немедленно принимает меры (разблокирует вторичный интерфейс для достижения Router 1 и Router 2).
В общем-то тут всё достаточно просто и не возникает сложностей. Но как только на сцену выходят подкольца и Edge с Assistant Edge всё становится интереснее.
Множество колец с общим участком
Вот такую картинку приводят в официальной доке. Человеку, который только знакомится с протоколом, может быть нифига непонятно, потому что на одну картинку сразу впихнули и проблему, и ее решение и механизм ее решения. Поэтому с вашего позволения я разделю их на слои.
Итак, какая проблема возникает, когда у нас с главным кольцо пересекаются 2 подкольца с одними и теми же Edge и Assistant Edge?
Итак – точка отсчета. На этой картинке мы видим полностью функционирующее главное кольцо и 2 подкольца с общими Edge и Assistant-edge. Желтыми линиями я выделил заблокированные протоколом линии, и действительно всё в порядке – до каждого узла у нас только один активный линк. Зеленой пунктирной линией показана отправка сообщений hello-edge от Edge к Assistant-edge.
Теперь представим, что общий линк между Edge и Assistant-Edge разорван:
Что случится? Да ничего страшного не произойдет. Помните, я делал акцент на том, что subcontrol vlan (vlan подкольца) идет через главное кольцо как обычный data vlan? Когда разорвался общий линк между Edge и Assistant edge они не могут больше обеспечивать прохождение по этому линку Health пакет от мастера подкольца.
Однако, главное кольцо увидело обрыв, разблокировало своё вторичное направление и теперь health пакет мастера подкольца корректно приходит ему же, пройдя круг через главное кольцо. То есть подкольцо не обнаружило разрыв и продолжает блокировать передачу данных по одному из линков.
Синими пунктирными стрелочками я попытался изобразить путь Health пакета от мастера подкольца через главное кольцо.
Хорошо, но что случится, если упадет еще один какой-нибудь линк на главном кольце?
В такой ситуации фокус с прохождением Health пакетов через Data VLAN главного кольца не прокатит. Все мастера подколец (а их может быть много) не смогут получить свои же Hello пакеты во вторичный интерфейс и закономерно сделают вывод – мое кольцо разрушено, разблокировать вторичный линк!
Но это решение будет фатальным для всей сети:
Каждый Sub Master, в данном случае их всего 2, разблокировал свой вторичный интерфейс и между Assistant-Edge, Edge и всеми мастерами подколец получилась (не) красивая большая петля. Именно для борьбы с этой ситуацией и нужны роли Edge и Assistant Edge.
Вернемся к первой картинке. Edge отправляет Edge-Hello в сторону Assistant Edge через оба направления.
Когда рвется один общий линк, Edge-Hello всё еще доходит до Assistant-Edge через второй путь:
И всё работает как полагается. А вот когда падает второй линк и Edge теряет связь c Assistant edge, по истечении таймера Edge Hello Timer, Assistant-Edge понимает, что связь с Edge нарушена и отправляет протокольный пакет MAJOR FAULT через свои Edge интерфейсы, то есть через подкольца:
Синим пунктиром я показал путь сообщения MAJOR FAULT. Видно, что через все подкольца они сходятся в Assistant Edge.
Edge, в свою очередь, получив данное сообщение, немедленно блокирует все свои Edge порты, предотвращая глобальную петлю между всеми подкольцами.
Но есть в этом механизме, в этой ситуации, один подвох. При срабатывании этого механизма, в зависимости от места обрыва и настройки первичных портов на всех мастерах, может быть полностью утрачен один или несколько сегментов сети:
При такой конфигурации Edge заблокирует передачу данных через единственный доступный путь и будет утрачен доступ ко всему подкольцу 1 и всему подкольцу 2, то есть могут пострадать огромные сегменты сети.
Или, например, при такой конфигурации будет утрачен доступ к Router2 и прилежащему к нему коммутатору.
Сначала я думал, что есть какой-то принцип где удастся избежать потерь, но потом понял, что краеугольным камнем при двух обрывах всегда становится Edge, вопрос только в том, насколько большой участок сети будет задет.
Чтобы уменьшить этот эффект, можно распределить трафик по нескольким RRPP интсансам с разным расположением Edge.
Балансировка трафика с помощью RRPP
Помимо резервирования, RRPP позволяет балансировать трафик разных vlan, подобно MSTP. Каждый RRPP домен (читай instance) может иметь абсолютно отличную от других топологию. Одно и то же устройство в одном домене может выступать Master, а в другом – Edge. Таким образом можно направлять трафик в разные стороны кольца, размещать Edge и Assistant Edge в разных местах.
Послесловие
Была проделана большая работа, перерыто множество документов, собрано с десяток стендов на реальном железе.
Я надеялся, что у меня получится пролить свет на все, или, хотя, бы, большинство непонятных из официальной документации аспектов протокола RRPP. Что-то у меня получилось, но в основном так же скомкано, как и в доках. Поэтому, прошу вас принять участие корректировке этой статьи, что облегчить страдания потомков, которые будут разбираться с этим, на самом деле, чудесным, протоколом.
Источники
Документация от H3C: https://www.h3c.com/en/d_200912/658836_294551_0.htm
Документация от Huawei: https://support.huawei.com/enterprise/en/doc/EDOC1000178168/a33c39d8/overview-of-rrpp
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
0%Они лучше открытых или вообще безальтернативны0
0%Категорически против вендор-лока0
100%Если есть открытый вариант, буду использовать открытый1
Проголосовал 1 пользователь. Воздержавшихся нет.
