M-LAG как альтернатива STP и стека



Одними из основных проблем в сети являются «петли» и «единая точка отказа».

Традиционным способом победить «петли» является использование протокола STP. Но в то же время этот протокол приносит проблему неэффективного использования пропускной способности портов и линков коммутатора. При наличии нескольких возможных линков, активным будет один, все-равно, что купить домой крутой и дорогой компьютер для игры в пасьянс «Косынку» — не используется весь потенциал устройства. Низкая сходимость, особенно в сложных топологиях. А если в сети бегает голос или потоковое видео? Путь между двумя соседними коммутаторами может идти через корневой – не оптимально.

Традиционным способом уйти от «единой точки отказа» и сделать сеть отказоустойчивой является использование стека. Не поспоришь, вариант хорош, но все-равно возникает ряд вопросов: какое будет время сходимости при выходе из строя master-node? Хватит ли пропускной способности стека между коммутаторами (хотим больше скорость – платим больше)? Как себя будет вести стек при “split-brain”? Об этом под катом.

Эти проблемы и вопросы с успехом может решить технология Extreme Networks – M-LAG.

Справедливости ради стоит упомянуть о том, что подобные технологии есть и других производителей, но с некоторыми различиями. Также, часто используют комбинации, например: стек + M-LAG.



В данной статье мы рассмотрим именно M-LAG от Extreme Networks как отдельную технологию.

M-LAG – Multi-Chassis Link Aggregation, модификация обычной аггрегации. Отличие и преимущество в том, что в данном случае линки начинаются на одном устройстве, а заканчиваются на двух, то есть резервирование не только линка как в LAG, но и резервирование устройства.


Со стороны Device1 настраивается обычный LAG, со стороны Device2 и Device3 все немного сложнее.

Давайте рассмотрим принцип работы M-LAG.

Между Device2 и Device3 должен быть линк на котором настраивается ISC (Inter-Switch Connection).
ISC покрывает несколько задач:

1. Поскольку со стороны Device1 настроен LAG, то в зависимости от алгоритма балансировки, пакеты могут передаваться разным коммутаторам. Поскольку это 2 разных коммутатора, data plane каждого работает самостоятельно – обеспечивается загрузка обоих линков. Но нам нужна синхронная и совместная работа control plane обоих устройств (синхронизация таблиц коммутации), для этого и нужен ISC (Inter-Switch Connection).

2. Из рисунка видно, что у нас организовалась «петля». ISC блокирует клиентский трафик при нормальной работе, если нет падений линка или отказа коммутаторов.

Также, стоит упомянуть особенность M-LAG: коммутаторы между которыми настраивается ISC должны быть одного производителя, мало того, строго рекомендуется чтоб эти коммутаторы были одного типа и серии, с одинаковой версией ExtremeXOS. К тому же желательно использовать коммутаторы с одинаковым количеством портов, например: Summit X460-24t & Summit X460-24x; BlackDiamond 8900-G48X-xl & BlackDiamond 8900-G48T-x. В то же время, нижестоящие или вышестоящие устройства, на которых настраивается LAG могут быть различных производителей.

Справедливости ради нужно указать, что на данный момент можно настроить 1 пир M-LAG, но в то же время количество M-LAG-ов для каждой пары коммутаторов может достигать 768.
M-LAG поддерживается всеми коммутаторами Extreme Networks за исключением L2 коммутаторов.

Это все относится к обычной работе M-LAG. Но что же происходит при появлении fault?

Рассмотрим несколько вариантов отказов:

1. Выход из строя одного из пары коммутаторов:



В этом случае все просто – весь трафик плавно утечет на линк между Device1 и Device3.

2. Выход из строя линка между Device2 и Device1



Тут открывается ISC и трафик перенаправляется через него. Для исключения данного отказа используется схема, когда на таких линках, например: между Device2 и Device1 настраивается LAG



3. Выход из строя ISC (так называемый split-brain)



В данном случае Device1 не будет знать об отказе ISC, Device2 и Device3 сохранят свои System Identifier, трафик от Device1 будет отправляться согласно алгоритма балансировки, а Device2 и Device3 будут направлять трафик согласно своих правил коммутации.
В то же время для исключения проблемы пропадания линка ISC на нем настраивается LAG:



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



При экспериментировании:
1. Отключались линки между Summit X440-48t и X460-24x, X460-24t
2. Отключались линки между Summit X460-24p и X460-24x, X460-24t
3. Отключался линк ISC между X460-24x и X460-24t

Extreme Networks утверждает, что время сходимости:



Попробуем запустить PING от одного ПК к другому, при выставлении интервала ICMP Echo 50мс:



Видно, что время сходимости составляет не более 50 мс.





Причем, данные показаны при выходе из строя линка LAG, а при пропадании линка ISC — потерь пакетов вообще не наблюдалось.

Но мы не сдаемся и посмотрим при интервале ICMP Echo = 10мс:







При пропадании линка LAG время сходимости равно 40-70 мс, а при пропадании ISC потерь пакетов вновь не наблюдается.

На мой взгляд, результаты тестирования показали замечательные значения сходимости при отказах, да и получше STP.
Из чего делаем вывод: M-LAG отличная альтернатива устоявшимся технологиям STP и Стекирования, легок в конфигурировании, да и не требует дополнительного капиталовложения, не лицензируется, доступен в базовой лицензии ExtremeXOS.

Заключение:
Хотелось бы отметить, что M-LAG отличная технология, которая имеет огромный спектр применений, но она не является «пилюлей от всех болезней», поэтому применять можно в совокупности с тем же STP и стеком. Все зависит от топологии сети и задач которые ставятся перед ней. Также, есть перспективные, более интересные, на мой взгляд, решения, такие как TRILL (Transparent Interconnection of Lots of Links) или набирающий бешенной популярности SDN (Software-Defined Networking), но это уже отдельная тема для статьи. Да и коммутаторы Extreme Networks имеют поддержку данных технологий.



Контактная инфа
Все дополнительные вопросы: extreme@muk.ua




МУК-Сервис — все виды ИТ ремонта: гарантийный, не гарантийный ремонт, продажа запасных частей, контрактное обслуживание
МУК
Company
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 24

    +3
    Традиционным способом уйти от «единой точки отказа» и сделать сеть отказоустойчивой является использование стека.

    Стек не убирает, а, наоборот, создает огромную единую точку отказа там, где ее до этого не было.
    ISC блокирует клиентский трафик при нормальной работе, если нет падений линка или отказа коммутаторов.

    На каком уровне блокирует? Не направляет туда пакет, пришедший из mLAG, если соответствующий линк на другом свитче жив? Или блокирует для затронутых VLANов целиком? Но тогда что если два mLAG'а имеют диапазоны VLANов 1-10 и 5-15 например, и один из них лишился линка до одного из шасси?
    легок в конфигурировании

    А вот кстати есть ли какие-либо отдельные механизмы синхронизации конфигурации между шасси? Допустим, хочу немного изменить настройку бандла. Это делается руками на двух устройствах? Возможен ли сценарий, когда начинается расколбас из-за критического различия в конфигах?
      0
      На каком уровне блокирует? Не направляет туда пакет, пришедший из mLAG, если соответствующий линк на другом свитче жив? Или блокирует для затронутых VLANов целиком? Но тогда что если два mLAG'а имеют диапазоны VLANов 1-10 и 5-15 например, и один из них лишился линка до одного из шасси?


      Скорее всего первое. На циско нексусах и на аристах наблюдаю именно такую ситуацию — в штатном режиме через интерконнект между коммутаторами всегда присутствует трафик. В тоже время каких-либо специфичных настроек STP мы не производили. Видимо коммутаторы понимают, что это M-LAG и защищают от петель на данном уровне.
      Хотя возможно у Экстрима это не так.
        +1
        Вот потому и спрашиваю. Я знаю, как работает vPC на нексусах, и мне интересно сравнить. Может, экстримы что-то свое сделали? Тот же vPC — вроде пара строк конфига, но целые книги на тему «как это устроено и какие могут быть грабли», т.е. ни о какой простоте там речь не идет.
          0
          Блокировки на аппаратном уровне, т.е. ОС применяет системные ACL, которые изменяют регистры и таблицы ASIC. В штатном режиме по ISC всегда бегают health-check.
          Ниже на картинке пример для L2 unicast, для флудинга и мултикаста свои механизмы реплицирования/блокировки предотвращающие петли.
          0
          А вот кстати есть ли какие-либо отдельные механизмы синхронизации конфигурации между шасси?

          Такого нет, шасси всегда живут отдельными логическими устройствами
            0
            А если захочу изменить настройку, которая обязана быть одинаковой на всех линках бандла? Ну что там у вас может быть… MTU? Конфиг STP, который никто отключать не собирается?

            Те же нексусы при type 1 inconsistency вообще сходу кладут vPC на одном из шасси, потому что так безопаснее. И есть отдельный протокол CFS, который позволит отслеживать расхождения и вносить изменения одновременно на двух разных логических устройствах (администратору надо делать conf sync вместо conf t).

            Меня, конечно, пугает идея одновременного внесения изменения на двух разных девайсах (кое-кто уже довносился), но стеки или риск возникновения расколбаса при расхождении в конфигурациях пугает меня сильнее.
              0
              А если захочу изменить настройку, которая обязана быть одинаковой на всех линках бандла? Ну что там у вас может быть… MTU? Конфиг STP, который никто отключать не собирается?


              Абсолютных требований к зеркальности настроек нет кроме как присутствие одинаковых вланов на всех портах,
              но даже при несиметричности все будет работать, а в лог будут сыпаться предупреждения, STP на этих портах не поднимается соответственно апокалипсиса не будет. Будет примерно то же если на на одном из портов LAG группы ограничить MTU, или отдельно отключить learning с одной стороны и сидеть думать что же случилось.
                +1
                STP на этих портах не поднимается

                Так он должен штатно подниматься на портах бандла, или нет?
                Будет примерно то же если на на одном из портов LAG группы ограничить MTU

                За экстрим не скажу, но IOS и NX-OS не позволят на одном из портов LAG группы менять такое. Надо зайти с виртуального интерфейса, тогда конфиг разом на все линки применится.
          0
          ISC блокирует клиентский трафик при нормальной работе, если нет падений линка или отказа коммутаторов.

          Т.е. в обычной работе он не используется? А если у меня на Device 2 сидит жирный потребитель, берущий данные с Device1 — он будет жрать только через линк Dev2-Dev1?

          Как быть с STP? Допустим, совсем от него отказаться не получается, а сделать M-LAG хочется?
            0
            Как быть с STP? Допустим, совсем от него отказаться не получается, а сделать M-LAG хочется?


            STP_BDPU можно прозрачно пропускать через MLAG, главное чтобы порты принимающие учатие в MLAG не блокировались STP
              0
              То есть свитчи вообще не участвуют в STP? Или все-таки кто-то из них принимает и генерирует BPDU?

              Полный отказ от STP на данном этапе вообще невозможен, даже с любыми реализациями MLAG/TRILL. Точнее, технически возможен, но с недопустимым риском. Если екстримы в MLAG совсем не участвуют в STP на соответствующих линках, то это — жирный минус.
                0
                Интерфейсы участвующие в MLAG не принимают участие в STP — так как основная задача MLAG это уход от STP и всех производных недостатков (то есть вещи взаимоисключающие), на всех остальных портах одного и того же свича можно генерить STP_BPDU
                  0
                  основная задача MLAG это уход от STP и всех производных недостатков

                  Нет. Задача MLAG — уход от блокируемых в штатном режиме STP линков. Отказаться от STP в качестве предохранителя решительно невозможно даже на TRILL (на всех внешних портах он продолжит работать), а уж любые реализации MLAG — просто агрегация линков. Допустим, у вас есть топология, в которой всего два свитча. Между ними один транк. Надо быть безумцем, чтобы действительно отключить STP. Кому он мешает? Все порты и так всегда будут в FWD. А если вдруг кто-то протянет еще один патч-корд между этими двумя портами, STP спасет сеть, заблокировав один из транков.

                  Так что боюсь, экстримовская реализация MLAG непригодна для продакшна. L2 сеть, которая не сумеет разобрать кольцо, возникшее из-за такой простой ошибки как «неверная кроссировка», это хлам какой-то.
                    0
                    У всех страхи разные, я видел сотни конфигов без настроеного STP с очень большим аптаймом.
                    MLAG разработан на основе IEEE 802.1AXbq, я думаю что людям из такой уважаемой организации видней хлам это или нет.
                      0
                      я видел сотни конфигов без настроеного STP

                      «Без настроенного» или «без включенного»? Обычно он везде по умолчанию включается. Его принудительно глобально отключали?
                      Есть много людей, которых разнообразные варианты стекирования ни разу не подводили. Сам же я встречал проблемы по этой части (полное падение) где угодно, от собственной сети (будь то обычные стеки или VSS) до проводимых циской презентаций с их собственной лабой.
                      MLAG разработан на основе IEEE 802.1AXbq, я думаю что людям из такой уважаемой организации видней хлам это или нет.

                      Покажите мне конкретные рекомендации, касающиеся взаимодействия с STP. Если действительно пишут «не включать на MLAG», то у меня не останется выбора кроме как назвать их идиотами. Но скорее всего, там будет что-то вроде «решение на совести вендора».

                      А может, Extreme просто схалтурил. Ведь для участия в STP надо немного менять логику поведения железок. Например, желательно, чтобы только одно шасси рассылало и отзывалось на BPDU по MLAG интерфейсам. Другое шасси, увидев BPDU из MLAG, должно переслать его ISC, что уже меняет логику работы этого интерфейса…
                        0
                        «Без настроенного» или «без включенного»
                        видел и такие, и такие

                        Покажите мне конкретные рекомендации, касающиеся взаимодействия с STP.

                        Ниже через пост они уже были указаны
                          0
                          видел и такие, и такие

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

                          Это цитируется документация Extreme. А мы вроде про IEEE говорили. Я вот считаю, что если единственной мерой защиты от колец является комбинация мер «изначальный дизайн без колец» и «storm control и прочие сугубо реактивные меры», то это очень печально, мягко говоря.

                          Или вы считаете допустимым, что сетевое оборудование решительно ничего не сможет сделать с кольцом, возникшим при подключении патч-корда между двумя транковыми или аксессными портами?
                            0
                            Или вы считаете допустимым, что сетевое оборудование решительно ничего не сможет сделать с кольцом, возникшим при подключении патч-корда между двумя транковыми или аксессными портами?

                            Я считаю что STP это хорошо но не панацея, всегда есть альтернативы или их комбинации.

                            Типа как парацетамол — хороший анальгетик, но может служить причиной нарушений работы печени, кровеносной системы и почек (©wiki)
                              +2
                              Я считаю что STP это хорошо но не панацея, всегда есть альтернативы или их комбинации.

                              А не существует альтернатив STP. Вообще. Так как нет более верного способа обнаружения кольца с участием посторонних устройств, чем BPDU (либо по содержащейся в нем информации, либо по самому факту его получения).

                              Есть лишь варианты дизайна внутри определенной L2 области, где либо не будет блокируемых им портов при штатной работе (разнообразные варианты MLAG), либо он будет заменен чем-то иным, но, опять же, только внутри той области и не на смотрящих наружу портах (TRILL).

                              Я смотрю, очень многие люди слишком буквально понимают лозунг «откажемся от STP» (не первый раз встречаю мнение вроде вашего) и не пытаются подумать над тем, что же на самом деле этот лозунг означает и почему полностью выключить STP вряд ли удастся и через десяток лет. Ну разве что администраторы и инженеры — роботы, никогда не допускающие ошибок, а оборудование у них никогда не глючит и желательно вообще отключено от питания.
                0
                А с этого места поподробней :) Juniper, например, сразу говорит отключать RSTP на ISC-порту (не помню, как он у джуна точно называется). ПРи этом к VSTP относится весьма пофигистично (разумеется, в ICL-влане его нужно отключать).

                Дык вот, если свич — сам по себе активный участник STP-кольца, как быть?
                  0
                  MLAG Requirements
                  STP cannot be enabled on MLAG ports.
                  STP should not be enabled on the ports present in the remote node which connects to the MLAG ports.
                  You should ensure that the ISC port is never blocked by STP.
              0
              Так а на каких свитчах у extreme есть trill?
                0
                На сегодняшний день TRILL уже доступен на Summit X670, X770 и BlackDiamondX8
                0
                Есть много тонких методов поиграться с сетью. Например, можно взять и отключить в оптике один линк из двух. Или чуть-чуть недовставить разъём и «подребезжать». Довольно приличная часть железа и софта такого очень не любит и начинает козлить.

                Only users with full accounts can post comments. Log in, please.