Защита от петель на уровне 2: три последовательных переключателя

Я знаю, что это похоже на домашнее задание, но на самом деле это часть более крупного проекта (и сети), и мне нужно разбить его на куски, чтобы я понял, что делаю. Я никогда не работал с [R / M] STP и раньше настраивал только статическую LAG, поэтому я не совсем уверен, что мне здесь нужно.

У меня есть три коммутатора в пределах одного и того же широковещательного домена с помощью тегов VLAN, связанных между собой группой LAG, состоящей из 2 медных гигабитных сетей Ethernet на группу LAG.

Предположим, что эти коммутаторы поддерживают маркировку VLAN LAG / LACP / * STP / 802.1q; пытаясь свести к минимуму проприетарные расширения, предлагаемые поставщиком, для сравнения, но если есть открытый стандарт поставщика, который «перемаркирован» или стоит упомянуть, пожалуйста, не стесняйтесь.

Цели:

• иметь резервные каналы связи для коммутатора A через B и C
• иметь балансировку нагрузки / увеличенную полосу пропускания по обоим восходящим каналам (если это возможно, то есть 4 группы GbE LAG или 2 группы GbE LAG «активный / пассивный», если это имеет смысл)

В чем я не уверен, так это:

1. Вот как я думаю, что этот цикл работает: запрос ARP от компьютера B1 (на коммутаторе B), который ищет 1.2.3.4, который принадлежит машине A1 (на коммутаторе A), поступит на коммутатор A как от A-to-B, так и от A -C-C Uplink. Коммутатор A (я предполагаю) сначала получит широковещательную рассылку через прямую восходящую линию LAG B-A, но отправит ответ обратно с обоих портов LAG восходящей линии (т. Е. LAG A-to-B - это порты 1/2 и LAG A-to-C - порты 23/24), что сильно сбивает с толку коммутатор B. Я прав в том, как я интерпретирую этот цикл?

2. Если мое утверждение о том, что # 1 действительно является циклом, мне нужен * STP. Из того, что я прочитал, STP старый и медленный; RSTP намного быстрее (может быть спорным вопросом во всех сетях, кроме самых крупных? Похоже, что говорит Intarweb). Тогда есть MSTP, который запутал меня до чертиков: кажется, позволяет несколько групп STP для нескольких VLAN, но при условии, что я имею дело только с одной VLAN (2), это необходимо? Что, если я добавлю вторую VLAN, которая будет проходить через все 3 коммутатора?

3. Я почти уверен, что M-LAG (я думаю, это то, что он называется) будет разрешать LAG, которые охватывают коммутаторы, но я не уверен, будет ли это LAG, которая включает 4 соединения Ethernet, которые включают коммутатор A- Up-B (2) и A-to-C (2) восходящие линии?

4. Я где-то читал на форуме (не могу вспомнить, где), что LACP устранит необходимость в * STP, потому что он «динамический» и «знает», какой канал восходящей связи направляет широковещательный / одноадресный трафик на основе алгоритмов балансировки нагрузки, но позже кто-то сказал, что это не так.

Чтобы свести это к минимуму, учитывая аббревиатуру супа LAG / LACP / * STP и мою топологию, что мне делать здесь на высоком уровне?

Честно говоря, я считаю, что намеренное проектирование петли в вашей сети не является хорошим дизайном. Связующее дерево может быть основной проблемой при управлении, проектировании, реализации, устранении неполадок и т. Д.

LACP и STP - две совершенно разные вещи. На очень высоком уровне LACP - это то, что позволяет вам создавать свою LAG - она ​​будет использовать несколько интерфейсов и обрабатывать их как одну ссылку. Как правило, для этого требуется, чтобы порты подключались к одним и тем же двум коммутаторам, то есть нельзя распределить группу LAG с LACP между несколькими коммутаторами. LACP предотвратит петлю при соединении двух коммутаторов вместе с несколькими каналами, если вы настроили эти порты как LAG с использованием LACP. Spanning Tree предназначен для предотвращения сбоев в работе вашей сети. Это делается путем обнаружения петли в топологии и будет активно блокировать трафик по одному или нескольким каналам, если петля обнаружена. Для правильной работы требуется некоторая мысль, и она может отличаться для каждой VLAN в зависимости от используемой версии STP.

Ваша идея о том, как будет работать цикл, неверна. После того, как вы подключите коммутаторы таким образом, если вы правильно настроили связующее дерево, оно отключит одну из LAG. Какой из них отключить, будет зависеть от того, где находится ваш корневой мост. Итак, допустим, что Spanning Tree закрывает LAG между коммутатором A и B. Ваш трафик, исходящий от коммутатора B, сначала должен перейти на коммутатор C, а затем перенаправить его на LAG для коммутатора A. Если вы настроили связующее дерево по-другому, вы можете отключите LAG между коммутатором A и C. В этом случае трафик от коммутатора A к коммутатору B будет идти напрямую от коммутатора A к B. Однако трафик с коммутатора A на C сначала должен проходить через коммутатор B. Как видите, чем больше вы делаете свой цикл, больше трафика прыжков может потребоваться, прежде чем он достигнет своего пункта назначения, в зависимости от источника / пункта назначения и того, какие связи связующего дерева отключены. Связующее дерево не будет динамически включать / отключать ссылки, чтобы найти кратчайший путь.

Итак, как это вписывается в ваши цели:

1. Технически вы получите избыточность с этим дизайном. Отработка отказа не будет мгновенной, поскольку связующее дерево должно будет сделать свое дело.
2. В зависимости от ваших коммутаторов, вы не получите большей пропускной способности или распределения нагрузки. Стандартные коммутаторы, правильно настроенные с помощью Spanning Tree, отключат одну из групп LAG. Если бы это не отключило LAG, у вас был бы цикл, и ваша сеть замедлилась бы до сканирования.

Какими еще способами вы можете достичь этих целей? Это будет зависеть от бюджета / потребностей / мест

1. MLAG действительно помогает решить многие из этих проблем. Почти полное резервирование, отсутствие потерь пропускной способности и т. Д. Но каждый поставщик делает вещи немного по-своему, поэтому обязательно изучите, как / что / почему они его реализуют. Cisco имеет VSS на линии коммутатора 6500, vPC на линии Nexus. Juniper делает их виртуальное шасси, Extreme имеет свою версию (не помню названия). Вы можете посмотреть на коммутатор Nexus с парой модулей FEX (или несколькими коммутаторами Nexus и модулем FEX с настройкой vPC для подключения к каждому Nexus). Путь по маршруту MLAG открывает много разных возможностей и, как правило, требует большего бюджета, и кто-то со знаниями о продуктах, чтобы прийти и сделать правильную оценку сайта и должен разработать правильное решение.
2. Купите стекируемое решение для коммутатора, которое имеет выделенное соединение объединительной платы. Это связывает коммутаторы вместе в один логический коммутатор, обычно с большей общей объединительной платой между коммутаторами. Даст вам избыточность и производительность.
3. Купите решение для переключения шасси. Снова общая объединительная плата, как правило, лучшее оборудование и функции и более высокая производительность, чем у большинства стековых решений. Может показаться, что это не так уж избыточно, поскольку у вас одно шасси, но я почти никогда не видел, чтобы шасси полностью вышло из строя. Вы можете настроить избыточные модули супервизора и иметь несколько линейных карт для обеспечения количества портов.

Это довольно высокий уровень обзора технологий. Вы можете копать довольно глубоко в связующее дерево, MLAG / vPC / и т. Д., Если хотите. Однако, если в этой части более крупной сети вы рассматриваете MLAG и т. П., У вас, вероятно, должен быть кто-то из сотрудников / по контракту, который немного лучше знаком с задействованными технологиями.