Eth trunk что это
Настройка сетевого оборудования компании HUAWEI (коммутация, статическая маршрутизация)
HUAWEI – одна из крупнейших китайских компаний в сфере телекоммуникаций. Основана в 1988 году.
Компания HUAWEI достаточно недавно вышла на российский рынок сетевого оборудования уровня Enterprise. С учётом тенденции тотальной экономии, на нашем предприятии очень остро встал вопрос о подборе достойной замены оборудованию Cisco.
В статье я попытаюсь рассмотреть базовые аспекты настройки сервисов коммутации и маршрутизации оборудования HUAWEI на примере коммутатора Quidway серии 5300.
Глобальные команды, режимы работы, cходства и различия с CLI CISCO.
Основные команды:
Настройка vlan интерфейсов, режимы работы физических портов коммутатора
Создание vlan
Для создания vlan как сущности, на коммутаторе в режиме system-view выполняется команда vlan XXX, где XXX – номер vlan.
Vlan создан. Так же командой description можно задать описание или название vlan. В отличие от Cisco имя не является обязательным атрибутом при создании vlan.
Для передачи созданых vlan в пределах локальной сети используется протокол GVRP. Включается он командой gvrp в режиме system-view.
Так же gvrp должен быть разрешён на интерфейсе:
Совместимости с Cisco VTP (vlan transfer protocol) нет и быть не может.
Создание vlan интерфейса.
В отличие от Cisco, маску можно писать сокращённо. Очень удобно.
Думаю, что комментарии излишни.
Режимы работы портов
Собственно, ничего нового. Существуют два основных режима работы порта: access и trunk.
Режим trunk
Настройка порта:
В отличие от коммутаторов Cisco, по-умолчанию, все vlan запрещены и их необходимо принудительно разрешить командой port trunk allow-pass vlan.
Нетэггированный native vlan на порту включается командой:
Настройка eth-trunk
Настройка STP
Для тестирование STP были соединены коммутаторы Cisco 2960 и HUAWEI Quidway S5328C-EI.
Для включения STP на коммутаторе необходимо в режиме system-view ввести команду
По умолчанию, приоритет коммутатора HUAWEI, так же как и коммутатора Cisco равен 32768.
Просмотр информации о текущем состоянии портов:
Видно, что один из портов заблокирован, т. к. приоритет коммутатора Cisco оказался больше.
Просмотр глобальной информации об STP:
Изменим приоритет коммутатора HUAWEI. Сделаем его наименьшим: 4096.
Посмотрим, что порт разблокировался:
Общая информация об STP:
Статическая маршрутизация
Статические маршруты прописываются точно так же, как на оборудовании Cisco:
Просмотр таблицы маршрутизации:
На этом всё.
Если уважаемое сообщество заинтересуется материалом, планирую продолжить освещать настройку оборудования HUAWEI. В следующей статье рассмотрим настройку динамической маршрутизации.
Основы компьютерных сетей. Тема №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 для получения максимального распределения нагрузки. До встречи в следующей статье!
Eth trunk что это
Продукты, решения и услуги для организаций
Пример настройки Eth-Trunk на проводных интерфейсах восходящей связи точки доступа
Требования к службе
Администратор хочет настроить Eth-Trunk на проводных интерфейсах восходящей связи точки доступа для обеспечения надежности восходящей связи.
Требования к сети
Режим сети AC: Встроенный режим уровня 2
Режим переадресации сервисных данных: туннельная переадресация
Рис. 3-26 Сеть для настройки Eth-Trunk на проводных интерфейсах восходящей связи AP
План данных
Управляющая VLAN для AP
Профиль проводного порта AP
Схема настройки
Замечания по конфигурации
Этот пример применим к AP с двумя или более проводными интерфейсами восходящей связи.
В этом примере предполагается, что AP находится в сети и описывает, как настроить Eth-Trunk на проводных интерфейсах восходящей связи AP. Перед физическими соединениями настройте Eth-Trunk. Иначе петля будет происходить в сети, в результате чего AP будет отключена.
Настройте изоляцию портов на интерфейсах устройства, напрямую подключенного к точкам доступа. Если изоляция порта не настроена и используется прямая переадресация, в VLAN может быть создано большое количество ненужных широковещательных пакетов, блокирующих сеть и ухудшающих работу пользователя.
В режиме туннельной переадресации управляющая VLAN и сервисная VLAN не могут быть одинаковыми. Только пакеты из управляющей VLAN передаются между AC и AP. Пакеты из сервисной VLAN не допускаются между AC и AP.
Configuring and Troubleshooting Eth-Trunks for S5700 Switches
Introduction
Ethernet link aggregation, also called Eth-Trunk, bundles multiple physical links into a logical link to increase link bandwidth, without having to upgrade hardware. Link aggregation increases bandwidth, improves link reliability, and enables load balancing.
This document discusses how to configure an Eth-Trunk in manual load balancing mode, how to configure an Eth-Trunk in LACP mode, and how to locate an Eth-Trunk fault.
Eth-Trunk Configuration
Link aggregation can work in manual mode or LACP mode. Before configuring an Eth-Trunk, perform step 1 and step 2.
Before connecting cables, run the display interface brief command to check interface status.
After the cables are successfully connected, the interface status changes from Down to Up.
When load balancing calculation is performed for an Eth-Trunk, the interface rate cannot be used as a weight. Therefore, when interfaces with different rates are added to an Eth-Trunk, the bandwidth of the Eth-Trunk is calculated based on the minimum interface rate. For example, if a GE interface and a 10GE interface are added to an Eth-Trunk, the GE interface rate is used for calculation. The actual bandwidth of the Eth-Trunk is 2 Gbit/s.
Configuring Link Aggregation in Manual Mode
Perform the following configurations:
After the configuration is complete, run the display eth-trunk 1 command to check whether the Eth-Trunk is correctly configured. If the value of Operate status is up, the Eth-Trunk is working properly.
Configuring Link Aggregation in LACP Mode
Perform the following configurations:
After the configuration is complete, run the display eth-trunk 1 command to check whether the Eth-Trunk is correctly configured. If the value of Operate status is up, the Eth-Trunk is working properly.
Eth-Trunk in Manual Load Balancing Mode Cannot Go Up
Troubleshooting Flowchart
Run the display eth-trunk command to check the working mode of an Eth-Trunk. If WorkingMode is NORMAL, the Eth-Trunk is working in manual load balancing mode.
Troubleshooting Procedure
The physical status of Eth-Trunk member interfaces must be Up so that the Eth-Trunk can work properly.
Run the display eth-trunk command to check information about Eth-Trunk member interfaces. If the Eth-Trunk member interface goes Down, rectify the fault by referring to «Troubleshooting: Ethernet Interface Physically Down» in the Huawei S Series Switches Troubleshooting Guide.
Run the display eth-trunk command to check whether the lower threshold for the number of active interfaces in the Eth-Trunk is configured. If the number of Eth-Trunk member interfaces in Up state is less than the lower threshold, the Eth-Trunk goes Down.
In the following command output, Least Active-linknumber indicates the lower threshold for the number of member links in Up state in an Eth-Trunk and is 3. However, the number of member interfaces in Up state in the Eth-Trunk is 1. Therefore, the value of Operate status is Down for the Eth-Trunk.
By default, the lower threshold for the number of active interfaces is 1. You can run the least active-linknumber link-number command to configure the lower threshold.
Eth-Trunk Interface in LACP Mode Cannot Go Up
Troubleshooting Flowchart
Check the working mode of an Eth-Trunk using either of the following methods:
Method 1: Check the WorkingMode field in the display eth-trunk command output.
Method 2: Check the configuration in the Eth-Trunk interface view.
Troubleshooting Procedure
The physical status of Eth-Trunk member interfaces must be Up so that the Eth-Trunk can work properly.
Run the display eth-trunk command to check information about Eth-Trunk member interfaces. If the Eth-Trunk member interface goes Down, rectify the fault by referring to «Troubleshooting: Ethernet Interface Physically Down» in the Huawei S Series Switches Troubleshooting Guide.
Check whether the configuration on two ends of the Eth-Trunk is consistent. The LACP mode needs to be configured on both ends because LACP packet negotiation is involved.
Run the display eth-trunk command to check whether the lower and upper thresholds for the number of active interfaces in the Eth-Trunk are configured. If the number of Eth-Trunk member interfaces in Up state is less than the lower threshold, the Eth-Trunk goes Down.
The default lower threshold for the number of active interfaces in an Eth-Trunk is 1. To configure the lower threshold, run the least active-linknumber link-number command. The default upper threshold for the number of active interfaces in an Eth-Trunk is 8. To configure the upper threshold, run the max active-linknumber link-number command.
If the least active-linknumber command has been configured before you run the max active-linknumber link-number command, ensure that the upper threshold for the number of active interfaces is greater than or equal to the lower threshold for the number of active interfaces.
Run the display lacp statistics eth-trunk command to check statistics about LACPDUs sent and received by Eth-Trunk member interfaces.
The number of increased packets is relevant to the timeout interval for an Eth-Trunk to receive packets. You can run the lacp timeout < fast| slow > command in the Eth-Trunk interface view to set the timeout interval for an Eth-Trunk in LACP mode to receive LACPDUs.
In fast mode, the remote end sends LACPDUs at an interval of 1 second. In slow mode, the remote end sends LACPDUs at an interval of 30 seconds. The fast mode ensures quicker response but consumes more system resources than the slow mode. The timeout intervals configured at the two ends can be different. You are advised to set the same LACPDU timeout interval on both ends to facilitate maintenance.
If the increase in the number of received LACPDUs is incorrect, check whether the remote end is not sending LACPDUs or the local end is discarding the received LACPDUs. If the number of LACPDUs received on the local end is incorrect, locate the reason the local interface does not receive LACPDUs.
For the S2700, S3700SI, S3700EI, S5700EI, S5700SI, and S5710LI, if the remote end sends LACPDUs but the local end does not receive the LACPDUs, check whether bpdu enable is configured on the Eth-Trunk. In V100R006 and later versions, bpdu enable is configured by default.
For the S9300, S9700, S7700, S12700, S7900, and other fixed switches, configure an ACL to obtain LACPDUs. If the remote end sends LACPDUs but the local end does not receive the LACPDUs, check whether the ACL has been delivered properly.
In V100R003 and later versions, run the display bcmfpi resource slot 5 acl app-resource service-name cp-car cp-car-name command in the hidden view or diagnostic view to check whether the PHYEntryId field exists for LACP. If so, the ACL has been delivered.