Назад | Перейти на главную страницу

Избежание петель уровня 2: три коммутатора последовательно

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

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

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

Цели:

В чем я не уверен:

  1. Вот как, я думаю, работает этот цикл: ARP-запрос от машины B1 (на коммутаторе B), ищущий 1.2.3.4, который принадлежит машине A1 (на коммутаторе A), будет поступать на коммутатор A как от A-to-B, так и от A -to-C восходящие каналы. Коммутатор A (я предполагаю) сначала получит широковещательную передачу через прямой восходящий канал LAG B-to-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 A- восходящие линии связи с B (2) и от A к C (2)?

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

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

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

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

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

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

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

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

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

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