Агрегирование каналов что это
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Агрегирование каналов
Пакетная коммутация. Часть 2
Это продолжение статьи про пакетную коммутацию. Первая часть тут.
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Схемы агрегации каналов берут несколько физических каналов и объединяют их в один виртуальный канал. В целях протоколов маршрутизации и алгоритмов предотвращения петель, таких как связующее дерево, виртуальный канал обрабатывается, как если бы он был одним физическим каналом.
Агрегирование каналов используется для увеличения пропускной способности между узлами сети без необходимости замены более медленных физических каналов на более быстрые. Например, два канала 10 Гбит/с можно объединить в один канал 20 Гбит/с, тем самым удвоив потенциальную полосу пропускания между двумя узлами, как показано на рисунке 6. Слово «потенциал» было выбрано тщательно, поскольку агрегированные каналы на практике не масштабируются линейно.
Поэтому большинство поставщиков реализуют хеширование потоков, чтобы гарантировать, что весь поток трафика использует один и тот же элемент пакета. Таким образом, нет никакого риска того, что хост получит пакеты не по порядку, так как они будут отправляться последовательно через один и тот же элемент канала.
Хеширование потока работает путем выполнения математической операции над двумя или более статическими компонентами потока, такими как MAC-адреса источника и получателя, IP-адреса источника и получателя, протокол управления передачей (TCP) или протокол дейтаграмм пользователя (UDP). номера портов для вычисления элемента связи, который будет использовать поток. Поскольку характеристики потока статичны, алгоритм хеширования приводит к идентичным вычислениям для каждого кадра или пакета в потоке трафика, гарантируя, что один и тот же канал будет использоваться в течение всего срока службы потока.
Это несоответствие в использовании возвращает нас к вопросу о линейном масштабировании. Если бы фреймы были сбалансированы по нагрузке через агрегированный набор каналов совершенно равномерно, то добавление новых каналов в набор равномерно увеличило бы емкость. Однако алгоритмы хэширования в сочетании с непредсказуемым объемом потоков трафика означают, что связанные каналы не будут загружаться равномерно.
При объединении каналов связи необходимо учитывать сетевые устройства на обоих концах канала связи и проявлять особую осторожность, чтобы обеспечить формирование пакета каналов связи при сохранении топологии без петель. Наиболее распространенным способом решения этой проблемы является использование отраслевого стандарта Link Aggregation Control Protocol (LACP), кодифицированного как стандарт 802.3 ad института инженеров электротехники и электроники (IEEE).
На каналах, обозначенных сетевым администратором, LACP объявляет о своем намерении сформировать агрегированный канал с другой стороной. Другая сторона, также выполняющая LACP, принимает это объявление, если объявленные параметры действительны, и формирует канал. Как только группа каналов сформирована, агрегированный канал переводится в состояние пересылки. Затем операторы сети могут запросить LACP для получения информации о состоянии агрегированного канала и о состоянии его членов.
LACP также знает, когда элемент связки выходит из строя, так как управляющие пакеты больше не проходят через сбойный канал. Эта возможность полезна, так как позволяет процессу LACP уведомлять сетевую операционную систему о необходимости пересчета хэшей потока. Без LACP сетевой операционной системе может потребоваться больше времени, чтобы узнать о сбойном канале, что приведет к хешированию трафика к элементу связи, который больше не является допустимым путем.
Существуют и другие протоколы управления агрегацией каналов. В некоторых случаях также возможно создавать пакеты каналов вручную без защиты управляющего протокола. Однако LACP доминирует в качестве стандарта, используемого сетевыми поставщиками, а также ведущими операционными системами и поставщиками гипервизоров для агрегации каналов.
Multichassis Link Aggregation
Обычным обоснованием для MLAG является физическая избыточность, когда сетевому инженеру требуется более низкий уровень (например, Ethernet) смежности между сетевыми устройствами (вместо маршрутизируемого соединения), а также требуется, чтобы связка каналов оставалась включенной, если удаленная сторона канала выходит из строя. Распространение связки каналов между двумя или более коммутаторами позволяет выполнить это требование. Рисунок 7 демонстрирует это.
В то время как многие сети используют некоторые разновидности MLAG в производстве, другие уклоняются от этой технологии, по крайней мере частично, потому что MLAG является собственностью. Нет такой вещи, как multivendor MLAG. Тенденции к лучшему проектированию сети в сторону от широко рассредоточенных коммутируемых доменов, сценарий, который выигрывает у MLAG. Вместо этого при проектировании сети наблюдается тенденция к ограниченным коммутируемым доменам, взаимосвязанным посредством маршрутизации, что устраняет необходимость в технологиях MLAG.
Маршрутизированные параллельные каналы
Маршрутизируемые плоскости управления, называемые протоколами маршрутизации, иногда вычисляют набор нескольких путей через сеть с равными затратами. В случае маршрутизации несколько каналов с одинаковой стоимостью могут даже не подключать одну пару устройств; Рисунок 8 демонстрирует это.
На рисунке 8 есть три пути:
Поскольку эти три пути имеют одинаковую стоимость, все они могут быть установлены в локальной таблице переадресации в точках A и D. Маршрутизатор A, например, может пересылать трафик по любому из этих трех каналов в направлении D. Когда маршрутизатор имеет несколько вариантов. чтобы добраться до того же пункта назначения, как он решает, какой физический путь выбрать?
Механизмы обработки пакетов
Шаги, связанные с маршрутизацией одного пакета, могут показаться очень простыми—найдите пункт назначения в таблице, создайте (или извлеките) перезапись заголовка MAC, перепишите заголовок MAC, а затем поместите пакет в правильную очередь для исходящего интерфейса. Как бы просто это ни было, все равно требуется время, чтобы обработать один пакет. На рисунке 9 показаны три различных пути, по которым пакет может быть коммутироваться в сетевом устройстве.
Рисунок 9 иллюстрирует три различных пути коммутации через устройство; это не единственные возможные пути коммутации, но они являются наиболее распространенными. Первый путь обрабатывает пакеты через программное приложение, работающее на универсальном процессоре (GPP), и состоит из трех этапов:
Многие специализированные ASIC для обработки пакетов имеют ряд интересных функций, в том числе:
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Основы компьютерных сетей. Тема №8. Протокол агрегирования каналов: Etherchannel
P.S. Возможно, со временем список дополнится.
Итак, начнем с простого.
Etherchannel — это технология, позволяющая объединять (агрегировать) несколько физических проводов (каналов, портов) в единый логический интерфейс. Как правило, это используется для повышения отказоустойчивости и увеличения пропускной способности канала. Обычно, для соединения критически важных узлов (коммутатор-коммутатор, коммутатор-сервер и др.). Само слово Etherchannel введено компанией Cisco и все, что связано с агрегированием, она включает в него. Другие вендоры агрегирование называют по-разному. Huawei называет это Link Aggregation, D-Link называет LAG и так далее. Но суть от этого не меняется.
Разберем работу агрегирования подробнее.
Есть 2 коммутатора, соединенных между собой одним проводом. К обоим коммутаторам подключаются сети отделов, групп (не важен размер). Главное, что за коммутаторами сидят некоторое количество пользователей. Эти пользователи активно работают и обмениваются данными между собой. Соответственно им ни в коем случае нельзя оставаться без связи. Встает 2 вопроса:
Теперь об их отличии. Первые 2 позволяют динамически согласоваться и в случае отказа какого-то из линков уведомить об этом.
Ручное агрегирование делается на страх и риск администратора. Коммутаторы не будут ничего согласовывать и будут полагаться на то, что администратор все предусмотрел. Несмотря на это, многие вендоры рекомендуют использовать именно ручное агрегирование, так как в любом случае для правильной работы должны быть соблюдены правила, описанные выше, а коммутаторам не придется генерировать служебные сообщения для согласования LACP или PAgP.
Начну с протокола LACP. Чтобы он заработал, его нужно перевести в режим active или passive. Отличие режимов в том, что режим active сразу включает протокол LACP, а режим passive включит LACP, если обнаружит LACP-сообщение от соседа. Соответственно, чтобы заработало агрегирование с LACP, нужно чтобы оба были в режиме active, либо один в active, а другой в passive. Составлю табличку.
Теперь перейдем к лабораторке и закрепим в практической части.
Есть 2 коммутатора, соединенные 2 проводами. Как видим, один линк активный (горит зеленым), а второй резервный (горит оранжевым) из-за срабатывания протокола STP. Это хорошо, протокол отрабатывает. Но мы хотим оба линка объединить воедино. Тогда протокол STP будет считать, что это один провод и перестанет блокировать.
Заходим на коммутаторы и агрегируем порты.
На этом настройка на первом коммутаторе закончена. Для достоверности можно набрать команду show etherchannel port-channel:
Видим, что есть такой port-channel и в нем присутствуют оба интерфейса.
Переходим ко второму устройству.
После этого канал согласуется. Посмотреть на это можно командой show etherchannel summary:
Здесь видно группу port-channel, используемый протокол, интерфейсы и их состояние. В данном случае параметр SU говорит о том, что выполнено агрегирование второго уровня и то, что этот интерфейс используется. А параметр P указывает, что интерфейсы в состоянии port-channel.
Все линки зеленые и активные. STP на них не срабатывает.
Сразу предупрежу, что в packet tracer есть глюк. Суть в том, что интерфейсы после настройки могут уйти в stand-alone (параметр I) и никак не захотят из него выходить. На момент написания статьи у меня случился этот глюк и решилось пересозданием лабы.
Теперь немного углубимся в работу LACP. Включаем режим симуляции и выбираем только фильтр LACP, чтобы остальные не отвлекали.
Видим, что SW1 отправляет соседу LACP-сообщение. Смотрим на поле Ethernet. В Source он записывает свой MAC-адрес, а в Destination мультикастовый адрес 0180.C200.0002. Этот адрес слушает протокол LACP. Ну и выше идет «длинная портянка» от LACP. Я не буду останавливаться на каждом поле, а только отмечу те, которые, на мой взгляд, важны. Но перед этим пару слов. Вот это сообщение используется устройствами для многих целей. Это синхронизация, сбор, агрегация, проверка активности и так далее. То есть у него несколько функций. И вот перед тем, как это все начинает работать, они выбирают себе виртуальный MAC-адрес. Обычно это наименьший из имеющихся.
И вот эти адреса они будут записывать в поля LACP.
С ходу это может не сразу лезет в голову. С картинками думаю полегче ляжет. В CPT немного кривовато показан формат LACP, поэтому приведу скрин реального дампа.
Выделенная строчка показывает для какой именно цели было послано данное сообщение. Вот суть его работы. Теперь это единый логический интерфейс port-channel. Можно зайти на него и убедиться:
И все действия, производимые на данном интерфейсе автоматически будут приводить к изменениям на физических портах. Вот пример:
Стоило перевести port-channel в режим trunk и он автоматически потянул за собой физические интерфейсы. Набираем show running-config:
И действительно это так.
Теперь расскажу про такую технологию, которая заслуживает отдельного внимания, как Load-Balance или на русском «балансировка». При создании агрегированного канала надо не забывать, что внутри него физические интерфейсы и пропускают трафик именно они. Бывают случаи, что вроде канал агрегирован, все работает, но наблюдается ситуация, что весь трафик идет по одному интерфейсу, а остальные простаивают. Как это происходит объясню на обычном примере. Посмотрим, как работает Load-Balance в текущей лабораторной работе.
На данный момент он выполняет балансировку исходя из значения MAC-адреса. По умолчанию балансировка так и выполняется. То есть 1-ый MAC-адрес она пропустит через первый линк, 2-ой MAC-адрес через второй линк, 3-ий MAC-адрес снова через первый линк и так будет чередоваться. Но такой подход не всегда верен. Объясняю почему.
Вот есть некая условная сеть. К SW1 подключены 2 компьютера. Далее этот коммутатор соединяется с SW2 агрегированным каналом. А к SW2 поключается маршрутизатор. По умолчанию Load-Balance настроен на src-mac. И вот что будет происходить. Кадры с MAC-адресом 111 будут передаваться по первому линку, а с MAC-адресом 222 по второму линку. Здесь верно. Переходим к SW2. К нему подключен всего один маршрутизатор с MAC-адресом 333. И все кадры от маршрутизатора будут отправляться на SW1 по первому линку. Соответственно второй будет всегда простаивать. Поэтому логичнее здесь настроить балансировку не по Source MAC-адресу, а по Destination MAC-адресу. Тогда, к примеру, все, что отправляется 1-ому компьютеру, будет отправляться по первому линку, а второму по второму линку.
Это очень простой пример, но он отражает суть этой технологии. Меняется он следующим образом:
Здесь думаю понятно. Замечу, что это пример балансировки не только для LACP, но и для остальных методов.
Заканчиваю разговор про LACP. Напоследок скажу только, что данный протокол применяется чаще всего, в силу его открытости и может быть использован на большинстве вендоров.
Тем, кому этого показалось мало, могут добить LACP здесь, здесь и здесь. И вдобавок ссылка на данную лабораторку.
Теперь про коллегу PAgP. Как говорилось выше — это чисто «цисковский» протокол. Его применяют реже (так как сетей, построенных исключительно на оборудовании Cisco меньше, чем гетерогенных). Работает и настраивается он аналогично LACP, но Cisco требует его знать и переходим к рассмотрению.
У PAgP тоже 2 режима:
Теперь переходим к настройке SW2 (не забываем, что на SW1 интерфейсы выключены и следует после к ним вернуться):
Возвращаемся к SW1 и включаем интерфейсы:
Теперь переходим в симуляцию и настраиваемся на фильтр PAgP. Видим, вылетевшее сообщение от SW2. Смотрим.
То есть видим в Source MAC-адрес SW2. В Destination мультикастовый адрес для PAgP. Повыше протоколы LLC и SNAP. Они нас в данном случае не интересуют и переходим к PAgP. В одном из полей он пишет виртуальный MAC-адрес SW1 (выбирается он по тому же принципу, что и в LACP), а ниже записывает свое имя и порт, с которого это сообщение вышло.
В принципе отличий от LACP практически никаких, кроме самой структуры. Кто хочет ознакомиться подробнее, ссылка на лабораторную. А вот так он выглядит реально:
Последнее, что осталось — это ручное агрегирование. У него с агрегированием все просто:
При остальных настройках канал не заработает.
Как говорилось выше, здесь не используется дополнительный протокол согласования, проверки. Поэтому перед агрегированием нужно проверить идентичность настроек интерфейсов. Или сбросить настройки интерфейсов командой:
В созданной лабораторке все изначально по умолчанию. Поэтому я перехожу сразу к настройкам.
И аналогично на SW2:
Настройка закончена. Проверим командой show etherchannel summary:
Порты с нужными параметрами, а в поле протокол «-«. То есть дополнительно ничего не используется.
Как видно все методы настройки агрегирования не вызывают каких-либо сложностей и отличаются только парой команд.
Под завершение статьи приведу небольшой Best Practice по правильному агрегированию. Во всех лабораторках для агрегирования использовались 2 кабеля. На самом деле можно использовать и 3, и 4 (вплоть до 8 интерфейсов в один port-channel). Но лучше использовать 2, 4 или 8 интерфейсов. А все из-за алгоритма хеширования, который придумала Cisco. Алгоритм высчитывает значения хэша от 0 до 7.
4 | 2 | 1 | Десятичное значение |
---|---|---|---|
0 | 0 | 0 | 0 |
0 | 0 | 1 | 1 |
0 | 1 | 1 | 3 |
1 | 0 | 0 | 4 |
0 | 0 | 1 | 1 |
1 | 0 | 1 | 5 |
1 | 1 | 0 | 6 |
1 | 1 | 1 | 7 |
Данная таблица отображает 8 значений в двоичном и десятичном виде.
На основании этой величины выбирается порт Etherchannel и присваивается значение. После этого порт получает некую «маску», которая отображает величины, за которые тот порт отвечает. Вот пример. У нас есть 2 физических интерфейса, которые мы объединяем в один port-channel.
Значения раскидаются следующим образом:
1) 0x0 — fa0/1
2) 0x1 — fa0/2
3) 0x2 — fa0/1
4) 0x3 — fa0/2
5) 0x4 — fa0/1
6) 0x5 — fa0/2
7) 0x6 — fa0/1
8) 0x7 — fa0/2
В результате получим, что половину значений или паттернов возьмет на себя fa0/1, а вторую половину fa0/2. То есть получаем 4:4. В таком случае балансировка будет работать правильно (50/50).
Теперь двинемся дальше и объясню, почему не рекомендуется использовать, к примеру 3 интерфейса. Составляем аналогичное сопоставление:
1) 0x0 — fa0/1
2) 0x1 — fa0/2
3) 0x2 — fa0/3
4) 0x3 — fa0/1
5) 0x4 — fa0/2
6) 0x5 — fa0/3
7) 0x6 — fa0/1
8) 0x7 — fa0/2
Здесь получаем, что fa0/1 возьмет на себя 3 паттерна, fa0/2 тоже 3 паттерна, а fa0/3 2 паттерна. Соответственно нагрузка будет распределена не равномерно. Получим 3:3:2. То есть первые два линка будут всегда загруженнее, чем третий.
Все остальные варианты я считать не буду, так как статья растянется на еще больше символов. Можно только прикинуть, что если у нас 8 значений и 8 линков, то каждый линк возьмет себе по паттерну и получится 1:1:1:1:1:1:1:1. Это говорит о том, что все интерфейсы будут загружены одинаково. Еще есть некоторое утверждение, что агрегировать нужно только четное количество проводов, чтобы добиться правильной балансировки. Но это не совсем верно. Например, если объединить 6 проводов, то балансировка будет не равномерной. Попробуйте посчитать сами. Надеюсь алгоритм понятен.
У Cisco на сайте по этому делу есть хорошая статья с табличкой. Можно почитать по данной ссылке. Если все равно останутся вопросы, пишите!
Раз уж так углубились, то расскажу про по увеличение пропускной способности. Я специально затронул эту тему именно в конце. Бывают случаи, что срочно нужно увеличить пропускную способность канала. Денег на оборудование нет, но зато есть свободные порты, которые можно собрать и пустить в один «толстый» поток. Во многих источниках (книги, форумы, сайты) утверждается, что соединяя восемь 100-мегабитных портов, мы получим поток в 800 Мбит/с или восемь гигабитных портов дадут 8 Гбит/с. Вот кусок текста из «цисковской» статьи.
Теоретически это возможно, но на практике почти недостижимо. Я по крайней мере не встречал. Если есть люди, которые смогли этого добиться, я буду рад услышать. То есть, чтобы это получить, нужно учесть кучу формальностей. И вот те, которые я описывал, только часть. Это не значит, что увеличения вообще не будет. Оно, конечно будет, но не настолько максимально.
На этом статья подошла к концу. В рамках данной статьи мы научились агрегировать каналы вручную, а также, при помощи протоколов LACP и PAgP. Узнали, что такое балансировка, как ею можно управлять и как правильно собирать Etherchannel для получения максимального распределения нагрузки. До встречи в следующей статье!
Общие сведения о агрегирования каналов и LACP [чаво]
Понятие о протоколе Link Aggregation Control Protocol
Howard
Купить FS коммутаторы для предприятий
Агрегация каналов-это подход к объединению нескольких отдельных каналов (Ethernet) в один логический канал. Вместе с ним часто появляются два термина, то есть LAG и LACP. Они вас смутили? Давайте теперь немного подробнее рассмотрим эти термины.
Не стесняйтесь забегать вперед, если вы уже позаботились о некоторых деталях.
Что такое LAG и как это работает?
Кроме того, он обеспечивает резервирование на уровне канала при отказе сети и балансировке нагрузки трафика. Даже если одна связь выйдет из строя, остальные связи между двумя коммутаторами все равно будут работать. Они также принимают на себя тот трафик, который должен проходить через вышедшего из строя, поэтому пакет данных не будет потерян.
Что такое LACP (протокол управления агрегацией каналов) и как он работает?
В результате, каналы, поддерживающие протокол LACP, могут увеличить логическую полосу пропускания и надежность сети без изменения какой-либо сетевой инфраструктуры.
Более того, даже если одна ссылка выходит из строя, в режиме LACP другие доступные члены ссылки в той же группе LACP будут балансировать нагрузку.
В момент, когда LACP включен между двумя коммутаторами, они будут отправлять LACPDU (блоки данных LACP) друг другу. После получения друг от друга LACPDU два коммутатора будут определять, у какой стороны системный приоритет выше.
После выбора Субъекта два коммутатора будут выбирать активные порты на основе приоритетов портов порта Субъекта. Однако, если порты Субъекта имеют одинаковые приоритеты, порты с меньшими номерами портов будут выбраны в качестве активных портов.
После выбора соответствующих портов двух коммутаторов устанавливается порт-канал (группа LACP). Тогда активные ссылки загрузят данные баланса для связи.
LAG vs LACP: в чем разница?
После того, как каналы агрегации установлены, все эти ссылки становятся активными ссылками для пересылки пакетов данных. Если одна активная ссылка не работает, остальные оставшиеся активные ссылки будут балансировать нагрузку на трафик. Однако этот режим может обнаруживать только разъединения входящих в него каналов, но не может обнаруживать другие сбои, такие как сбои канального уровня и неправильные соединения каналов.
Когда условие агрегирования ссылок изменяется, LACP корректирует или удаляет агрегированный канал. Если одна активная ссылка выходит из строя, система выбирает ссылку среди резервных ссылок в качестве активной ссылки. Таким образом, количество ссылок, участвующих в пересылке данных, остается неизменным. Кроме того, этот режим не только обнаруживает разъединения своих звеньев, но и другие сбои, такие как сбои канального уровня и неправильные соединения каналов.
Должен ли я включать агрегацию каналов?
Если у вас есть коммутатор с большим количеством портов Gigabit Ethernet, вы можете подключить их все к другому устройству, у которого также есть несколько портов, и сбалансировать трафик между этими каналами для повышения производительности.
Другой важной причиной использования агрегации каналов является обеспечение быстрого и прозрачного восстановления в случае отказа одного из отдельных каналов.
Если вы очень заботитесь о надежности и доступности сети, было бы лучше включить агрегацию каналов на ваших устройствах.
Как настроить коммутатор агрегации каналов?
Коммутатор агрегации каналов или коммутатор LACP, см. Установку или настройку коммутатора для достижения технологии агрегации каналов. Коммутатор агрегации каналов может быть любым коммутатором, например Gigabit Ethernet коммутатор или 10 Gigabit коммутатор, который поддерживает LACP. Как правило, существует шесть шагов для настройки коммутаторов агрегации каналов:
Шаг 1. Добавьте интерфейсы участников в группу каналов.
Шаг 2: Установите приоритет системы LACP и определите Субъекта, чтобы Партнер выбирал активные интерфейсы на основе приоритета интерфейса Субъекта.
Шаг 3: Установите верхний порог количества активных интерфейсов для повышения надежности. (Этот шаг необязательно применяется в командах динамической конфигурации CLI.)
Шаг 4: Установите приоритеты интерфейса LACP и определите активные интерфейсы, чтобы интерфейсы с более высоким приоритетом выбирались в качестве активных интерфейсов. (Этот шаг необязательно применяется в командах динамической конфигурации CLI.)
Шаг 5: Создайте сети VLAN и добавьте интерфейсы к этим VLAN. (Этот шаг необязательно применяется в командах динамической конфигурации CLI.)
Шаг 6: Проверьте конфигурацию LACP.
Дополнительные сведения о настройке коммутатора LACP или коммутатора агрегации каналов см. В разделе Конфигурация LACP на коммутаторах серии FS S3900.
Коммутаторы поддерживающие LAG
Если вы ищете хорошие сетевые коммутаторы, поддерживающие LACP, вот три самых продаваемых коммутатора от FS, глобальной высокотехнологичной компании, предоставляющей решения и услуги для высокоскоростных сетей связи.
S3900-24T4S | S5850-48S6Q | S5860-20SQ | |
---|---|---|---|
Уровень управления | Layer 2+ | Layer 3 | Layer 3 |
Комбинация портов | 24 x 1G, 4 x 10G SFP+ | 48 x 10G SFP+, 6 x 40G QSFP+ | 20 x 10G SFP+, 4 x 25G SFP28, 2 x 40G QSFP+ |
Ключевая особенность | VLAN, QoS, IGMP Snooping, Link Aggregation, IPv6,L3 статическая маршрутизация | VLAN, QoS, IGMP Snooping, Link Aggregation, статическая маршрутизация, RIP, OSPF, IPv6 поддержка, BGP/ISIS, MLAG | QoS, IGMP Snooping, Link Aggregation, IPv6, L3 статическая маршрутизация, RIP, OSPF, BGP/ISIS, стекируемый |
Применения | SMB( 2500 пользователей) |