Комментарии 24
Традиционным способом уйти от «единой точки отказа» и сделать сеть отказоустойчивой является использование стека.
Стек не убирает, а, наоборот, создает огромную единую точку отказа там, где ее до этого не было.
ISC блокирует клиентский трафик при нормальной работе, если нет падений линка или отказа коммутаторов.
На каком уровне блокирует? Не направляет туда пакет, пришедший из mLAG, если соответствующий линк на другом свитче жив? Или блокирует для затронутых VLANов целиком? Но тогда что если два mLAG'а имеют диапазоны VLANов 1-10 и 5-15 например, и один из них лишился линка до одного из шасси?
легок в конфигурировании
А вот кстати есть ли какие-либо отдельные механизмы синхронизации конфигурации между шасси? Допустим, хочу немного изменить настройку бандла. Это делается руками на двух устройствах? Возможен ли сценарий, когда начинается расколбас из-за критического различия в конфигах?
На каком уровне блокирует? Не направляет туда пакет, пришедший из mLAG, если соответствующий линк на другом свитче жив? Или блокирует для затронутых VLANов целиком? Но тогда что если два mLAG'а имеют диапазоны VLANов 1-10 и 5-15 например, и один из них лишился линка до одного из шасси?
Скорее всего первое. На циско нексусах и на аристах наблюдаю именно такую ситуацию — в штатном режиме через интерконнект между коммутаторами всегда присутствует трафик. В тоже время каких-либо специфичных настроек STP мы не производили. Видимо коммутаторы понимают, что это M-LAG и защищают от петель на данном уровне.
Хотя возможно у Экстрима это не так.
Вот потому и спрашиваю. Я знаю, как работает vPC на нексусах, и мне интересно сравнить. Может, экстримы что-то свое сделали? Тот же vPC — вроде пара строк конфига, но целые книги на тему «как это устроено и какие могут быть грабли», т.е. ни о какой простоте там речь не идет.
Блокировки на аппаратном уровне, т.е. ОС применяет системные ACL, которые изменяют регистры и таблицы ASIC. В штатном режиме по ISC всегда бегают health-check.
Ниже на картинке пример для L2 unicast, для флудинга и мултикаста свои механизмы реплицирования/блокировки предотвращающие петли.
Ниже на картинке пример для L2 unicast, для флудинга и мултикаста свои механизмы реплицирования/блокировки предотвращающие петли.
А вот кстати есть ли какие-либо отдельные механизмы синхронизации конфигурации между шасси?
Такого нет, шасси всегда живут отдельными логическими устройствами
А если захочу изменить настройку, которая обязана быть одинаковой на всех линках бандла? Ну что там у вас может быть… MTU? Конфиг STP, который никто отключать не собирается?
Те же нексусы при type 1 inconsistency вообще сходу кладут vPC на одном из шасси, потому что так безопаснее. И есть отдельный протокол CFS, который позволит отслеживать расхождения и вносить изменения одновременно на двух разных логических устройствах (администратору надо делать conf sync вместо conf t).
Меня, конечно, пугает идея одновременного внесения изменения на двух разных девайсах (кое-кто уже довносился), но стеки или риск возникновения расколбаса при расхождении в конфигурациях пугает меня сильнее.
Те же нексусы при type 1 inconsistency вообще сходу кладут vPC на одном из шасси, потому что так безопаснее. И есть отдельный протокол CFS, который позволит отслеживать расхождения и вносить изменения одновременно на двух разных логических устройствах (администратору надо делать conf sync вместо conf t).
Меня, конечно, пугает идея одновременного внесения изменения на двух разных девайсах (кое-кто уже довносился), но стеки или риск возникновения расколбаса при расхождении в конфигурациях пугает меня сильнее.
А если захочу изменить настройку, которая обязана быть одинаковой на всех линках бандла? Ну что там у вас может быть… MTU? Конфиг STP, который никто отключать не собирается?
Абсолютных требований к зеркальности настроек нет кроме как присутствие одинаковых вланов на всех портах,
но даже при несиметричности все будет работать, а в лог будут сыпаться предупреждения, STP на этих портах не поднимается соответственно апокалипсиса не будет. Будет примерно то же если на на одном из портов LAG группы ограничить MTU, или отдельно отключить learning с одной стороны и сидеть думать что же случилось.
STP на этих портах не поднимается
Так он должен штатно подниматься на портах бандла, или нет?
Будет примерно то же если на на одном из портов LAG группы ограничить MTU
За экстрим не скажу, но IOS и NX-OS не позволят на одном из портов LAG группы менять такое. Надо зайти с виртуального интерфейса, тогда конфиг разом на все линки применится.
ISC блокирует клиентский трафик при нормальной работе, если нет падений линка или отказа коммутаторов.
Т.е. в обычной работе он не используется? А если у меня на Device 2 сидит жирный потребитель, берущий данные с Device1 — он будет жрать только через линк Dev2-Dev1?
Как быть с STP? Допустим, совсем от него отказаться не получается, а сделать M-LAG хочется?
Как быть с STP? Допустим, совсем от него отказаться не получается, а сделать M-LAG хочется?
STP_BDPU можно прозрачно пропускать через MLAG, главное чтобы порты принимающие учатие в MLAG не блокировались STP
То есть свитчи вообще не участвуют в STP? Или все-таки кто-то из них принимает и генерирует BPDU?
Полный отказ от STP на данном этапе вообще невозможен, даже с любыми реализациями MLAG/TRILL. Точнее, технически возможен, но с недопустимым риском. Если екстримы в MLAG совсем не участвуют в STP на соответствующих линках, то это — жирный минус.
Полный отказ от STP на данном этапе вообще невозможен, даже с любыми реализациями MLAG/TRILL. Точнее, технически возможен, но с недопустимым риском. Если екстримы в MLAG совсем не участвуют в STP на соответствующих линках, то это — жирный минус.
Интерфейсы участвующие в MLAG не принимают участие в STP — так как основная задача MLAG это уход от STP и всех производных недостатков (то есть вещи взаимоисключающие), на всех остальных портах одного и того же свича можно генерить STP_BPDU
основная задача MLAG это уход от STP и всех производных недостатков
Нет. Задача MLAG — уход от блокируемых в штатном режиме STP линков. Отказаться от STP в качестве предохранителя решительно невозможно даже на TRILL (на всех внешних портах он продолжит работать), а уж любые реализации MLAG — просто агрегация линков. Допустим, у вас есть топология, в которой всего два свитча. Между ними один транк. Надо быть безумцем, чтобы действительно отключить STP. Кому он мешает? Все порты и так всегда будут в FWD. А если вдруг кто-то протянет еще один патч-корд между этими двумя портами, STP спасет сеть, заблокировав один из транков.
Так что боюсь, экстримовская реализация MLAG непригодна для продакшна. L2 сеть, которая не сумеет разобрать кольцо, возникшее из-за такой простой ошибки как «неверная кроссировка», это хлам какой-то.
У всех страхи разные, я видел сотни конфигов без настроеного STP с очень большим аптаймом.
MLAG разработан на основе IEEE 802.1AXbq, я думаю что людям из такой уважаемой организации видней хлам это или нет.
MLAG разработан на основе IEEE 802.1AXbq, я думаю что людям из такой уважаемой организации видней хлам это или нет.
я видел сотни конфигов без настроеного STP
«Без настроенного» или «без включенного»? Обычно он везде по умолчанию включается. Его принудительно глобально отключали?
Есть много людей, которых разнообразные варианты стекирования ни разу не подводили. Сам же я встречал проблемы по этой части (полное падение) где угодно, от собственной сети (будь то обычные стеки или VSS) до проводимых циской презентаций с их собственной лабой.
MLAG разработан на основе IEEE 802.1AXbq, я думаю что людям из такой уважаемой организации видней хлам это или нет.
Покажите мне конкретные рекомендации, касающиеся взаимодействия с STP. Если действительно пишут «не включать на MLAG», то у меня не останется выбора кроме как назвать их идиотами. Но скорее всего, там будет что-то вроде «решение на совести вендора».
А может, Extreme просто схалтурил. Ведь для участия в STP надо немного менять логику поведения железок. Например, желательно, чтобы только одно шасси рассылало и отзывалось на BPDU по MLAG интерфейсам. Другое шасси, увидев BPDU из MLAG, должно переслать его ISC, что уже меняет логику работы этого интерфейса…
«Без настроенного» или «без включенного»видел и такие, и такие
Покажите мне конкретные рекомендации, касающиеся взаимодействия с STP.
Ниже через пост они уже были указаны
видел и такие, и такие
Ну что же, безумству храбрых поем мы славу. Я видел на просторах интернета немало конфигов, при взгляде на которые возникает вопрос «каким местом думал конфигуривший всё это, он что, перечислял все прикольно звучащие команды без оглядки на их функционал?».
Ниже через пост они уже были указаны
Это цитируется документация Extreme. А мы вроде про IEEE говорили. Я вот считаю, что если единственной мерой защиты от колец является комбинация мер «изначальный дизайн без колец» и «storm control и прочие сугубо реактивные меры», то это очень печально, мягко говоря.
Или вы считаете допустимым, что сетевое оборудование решительно ничего не сможет сделать с кольцом, возникшим при подключении патч-корда между двумя транковыми или аксессными портами?
Или вы считаете допустимым, что сетевое оборудование решительно ничего не сможет сделать с кольцом, возникшим при подключении патч-корда между двумя транковыми или аксессными портами?
Я считаю что STP это хорошо но не панацея, всегда есть альтернативы или их комбинации.
Типа как парацетамол — хороший анальгетик, но может служить причиной нарушений работы печени, кровеносной системы и почек (©wiki)
Я считаю что STP это хорошо но не панацея, всегда есть альтернативы или их комбинации.
А не существует альтернатив STP. Вообще. Так как нет более верного способа обнаружения кольца с участием посторонних устройств, чем BPDU (либо по содержащейся в нем информации, либо по самому факту его получения).
Есть лишь варианты дизайна внутри определенной L2 области, где либо не будет блокируемых им портов при штатной работе (разнообразные варианты MLAG), либо он будет заменен чем-то иным, но, опять же, только внутри той области и не на смотрящих наружу портах (TRILL).
Я смотрю, очень многие люди слишком буквально понимают лозунг «откажемся от STP» (не первый раз встречаю мнение вроде вашего) и не пытаются подумать над тем, что же на самом деле этот лозунг означает и почему полностью выключить STP вряд ли удастся и через десяток лет. Ну разве что администраторы и инженеры — роботы, никогда не допускающие ошибок, а оборудование у них никогда не глючит и желательно вообще отключено от питания.
А с этого места поподробней :) Juniper, например, сразу говорит отключать RSTP на ISC-порту (не помню, как он у джуна точно называется). ПРи этом к VSTP относится весьма пофигистично (разумеется, в ICL-влане его нужно отключать).
Дык вот, если свич — сам по себе активный участник STP-кольца, как быть?
Дык вот, если свич — сам по себе активный участник STP-кольца, как быть?
Так а на каких свитчах у extreme есть trill?
Есть много тонких методов поиграться с сетью. Например, можно взять и отключить в оптике один линк из двух. Или чуть-чуть недовставить разъём и «подребезжать». Довольно приличная часть железа и софта такого очень не любит и начинает козлить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
M-LAG как альтернатива STP и стека