Etherchannel cisco что это

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Настройка EtherChannel на Cisco

Онлайн курс по Кибербезопасности

Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии

На самом деле EtherChannel это технология агрегации (объединения) каналов. Это означает, что мы можем объединить несколько линков в один логический, что позволит увеличить пропускную способность между коммутаторами.

Пример использования

Взглянем на схему ниже:

В рамках данной схемы мы имеем серверную инфраструктуру, которая подключена в коммутатору распределения (distribution switch) через свой коммутатор. За коммутатором распределения сидят коммутаторы доступы, за которым расположились пользовательские рабочие станции:

Если мы подключим два коммутатор линком в 1ГБ/сек, то потенциально, мы можем столкнуться с проблемой «бутылочного горлышка», то есть узкого места. Тогда пользователи испытают проблемы с доступом к серверной ферме.

Используя технологию EtherChannel, мы можем объединить до 8 интерфейсов (физических) в один логический линк (агрегация портов, Port-Channel) и трафик будет распределяться между физическими портами равномерно (балансируя нагрузку).

В нашем примере мы объединили 4 (четыре) гигабитных линка между рабочими станциями и серверами в один, с пропускной способностью 4ГБ/сек. Это увеличило общую пропускную способность и добавило отказоустойчивость линков!

Не забывайте про STP (Spanning-tree protocol). В случае агрегации портов, мы исключаем STP петли.

Режимы EtherChannel

Каждый из протоколов LACP или PAgP имеет по 3 режима работы, которые определяют режим его активности (инициализировать ли построение агрегации со своей стороны, или ждать сигнал с удаленной стороны):

Давайте посмотрим, в каком из случае будет установлено соединение EtherChannel при различных режимах настройки. Для LACP:

Теперь разберемся с PAgP:

Настройка

Ок, предположим, что порты с Gi0/0 по Gi0/3 буду использованы для агрегации EtherChannel. Лучше всего настроить логический интерфейс (агрегированный) в качестве транка, чтобы пропускать VLAN между коммутаторами.

Поднимаем LACP

В нашем случае switch1 будет активном (Active) режиме, а switch2 будет в пассивном (Passive) режиме.

Поднимаем PAgP

Полезные команды

Вот некоторые команды, которые могут понадобиться вам в работе с EtherChannel:

Полный курс по Сетевым Технологиям

В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer

Полезно?

Почему?

😪 Мы тщательно прорабатываем каждый фидбек и отвечаем по итогам анализа. Напишите, пожалуйста, как мы сможем улучшить эту статью.

😍 Полезные IT – статьи от экспертов раз в неделю у вас в почте. Укажите свою дату рождения и мы не забудем поздравить вас.

Источник

Пример настройки межстекового канала EtherChannel на коммутаторе Catalyst 3750

Параметры загрузки

Содержание

Введение

В данном документе приводится пример настройки межстекового канала EtherChannel на коммутаторе Cisco Catalyst 3750 под управлением операционной системы Cisco IOS®. Канал EtherChannel может иметь название Fast EtherChannel или Gigabit EtherChannel. Это зависит от скорости интерфейсов или портов, которые используются для формирования межстекового канала EtherChannel.

Предварительные условия

Требования

Для данного документа нет особых требований.

Используемые компоненты

Сведения, содержащиеся в данном документе, касаются коммутатора Catalyst 3750 под управлением операционной системы Cisco IOS версии 12.2(25)SEC.

Сведения, представленные в данном документе, были получены на тестовом оборудовании в специально созданных лабораторных условиях. При написании данного документа использовались только данные, полученный от устройств с конфигурацией по умолчанию. В рабочей сети необходимо понимать последствия выполнения всех команд.

Условные обозначения

См. Технические советы Cisco. Условные обозначения для получения дополнительной информации об условных обозначениях в документах.

Теоретические сведения

В данном документе для межстекового канала EtherChannel объединяются следующие интерфейсы:

Два интерфейса Gigabit Ethernet одного из коммутаторов Catalyst 3750

Один интерфейс Gigabit Ethernet на другом коммутаторе Catalyst 3750 того же самого стека

Три интерфейса Gigabit Ethernet на коммутаторе Catalyst 3750 другого стека

Технология взаимоподключения Cisco StackWise предполагает использование двух взаимно направленных путей в 16 Гбит каждый. Для эффективного распределения нагрузки трафика, пакеты распределяются между этими двумя логическими взаимно направленными путями, которые образуют взаимоподключение в 32-Гбит. Это сдвоенные пути от любого порта к любому другому порту в рамках стека Catalyst 3750. Таким образом, гарантируется максимальное время доступности, так как всегда существует альтернативный путь при возникновении сбоя передачи данных по другому пути. Коммутатор Catalyst 3750 поддерживает:

Межстековый канал EtherChannel

Межстековый канал UplinkFast (с обработкой отказов в течение секунд)

Межстековые маршруты равной стоимости между различными коммутаторами в стеке

LACP-протокол и PAgP-протокол

Каналы EtherChannel могут настраиваться автоматически либо с помощью PAgP-протокола, либо с помощью LACP-протокола. PAgP-протокол – это принадлежащий компании Cisco протокол, который может работать только на коммутаторах Cisco и на коммутаторах, лицензированных для поддрежки PAgP, выпущенных другими лицензированными производителями. LACP-протокол определяется стандартом IEEE 802.3ad. LACP-протокол позволяет коммутаторам Cisco управлять Ethernet-каналами между коммутаторами, которые соответствуют стандарту IEEE 802.3ad.

PAgP-протокол не может использоваться на межстековых каналах EtherChannel, в то время как LACP-протокол поддерживается на межстековых каналах EtherChannel в операционной системе Cisco IOS версии 12.2(25)SEC и более поздней. Интерфейсы коммутатора обмениваются LACP-пакетами только с партнерскими интерфейсами в активном или пассивном режиме. Для формирования канала можно настроить до 16 портов. Восемь из этих портов будут находиться в активном режиме, а остальные восемь будут находиться в режиме ожидания. При выходе из строя любого из активных портов, произойдет активизация порта, находящегося в режиме ожидания. Интерфейсы в режиме настройки не обмениваются пакетами по протоколу PAgP или LACP.

На межстековом канале EtherChannel поддерживаются следующие режимы EtherChannel:

active — переводит интерфейс в активное состояние согласования, в котором интерфейс начинает обмениваться данными с другими интерфейсами, посылая LACP-пакеты.

passive — переводит интерфейс в пассивное состояние согласования, в котором интерфейс отвечает только на получаемые LACP-пакеты, однако, не начинает активного согласования. Этот параметр минимизирует передачу LACP-пакетов.

on — принудительно подключает интерфейс к каналу EtherChannel без использования протокола PAgP или LACP. В режиме «on» пригодный к использованию канал EtherChannel существует только тогда, когда группа интерфейса в режиме «on» имеет соединение с другой группой интерфейсов в режиме «on».

Настройка

В этом разделе приводятся сведения о настройке функций, описанных в данном документе.

Схема сети

В данном документе используется следующая схема сети:

В данной схеме сети существует два стека коммутатора Catalyst 3750 Switch — стек A и стек Б. Стек A содержит три узла коммутатора, а стек Б содержит только один узел коммутатора. Канал EtherChannel формируется двумя портами на коммутаторе 1 и одним портом на коммутаторе 3 стека A. Эти порты подключены к трем портам в стеке Б.

Процедура настройки сети необходима для определения этих портов в качестве магистральных.

Настройки

В данном документе используются следующие конфигурации:

Настройка межстекового канала EtherChannel без протокола PAgP или LACP

В данном подразделе содержится пример настройки канала EtherChannel без использования протокола PAgP или LACP:

Стек А коммутатора Catalyst 3750

Стек Б коммутатора Catalyst 3750

Состояние EtherChannel можно проверить следующим образом:

Примечание: В данном примере показано сообщение об ошибке, которое отображается при попытке настроить канал EtherChannel с помощью PAgP:

Стек А коммутатора Catalyst 3750

Настройка межстекового канала EtherChannel с помощью протокола LACP

В данном примере показана настройка канала EtherChannel с помощью протокола LACP. Минимально необходимой версией операционной системы IOS, которая поддерживает протокол LACP в межстековом канале Etherchannel, является операционная система Cisco IOS 12.2(25)SEC. В данном примере используется конфигурация LACP в режиме «active-active»:

Стек А коммутатора Catalyst 3750

Стек Б коммутатора Catalyst 3750

Состояние EtherChannel можно проверить следующим образом:

В данном примере используется конфигурация LACP в режиме «passive-active»:

Стек А коммутатора Catalyst 3750

Стек Б коммутатора Catalyst 3750

Состояние EtherChannel можно проверить следующим образом:

Проверка

Воспользуйтесь данным разделом для проверки правильности функционирования вашей конфигурации.

Выполните нижеследующие команды для проверки канала порта в коммутаторе Catalyst 3750 под управлением операционной системы Cisco IOS:

show interfaces port-channel [channel-group-number]

show etherchannel [channel-group-number] summary

Устранение неполадок

Для этой конфигурации отсутствуют сведения об устранении неполадок.

Источник

Steinkäfer

четверг, 28 января 2016 г.

Cisco. Агрегирование каналов.

Общая информация об агрегировании каналов

Большинство технологий по агрегированию позволяют объединять только параллельные каналы. То есть такие, которые начинаются на одном и том же устройстве и заканчиваются на другом.

Если рассматривать избыточные соединения между коммутаторами, то без использования специальных технологий для агрегирования каналов, передаваться данные будут только через один интерфейс, который не заблокирован STP. Такой вариант позволяет обеспечить резервирование каналов, но не дает возможности увеличить пропускную способность.

Без использования STP такое избыточное соединение создаст петлю в сети.

Технологии по агрегированию каналов позволяют использовать все интерфейсы одновременно. При этом устройства контролируют распространение широковещательных фреймов (а также multicast и unknown unicast), чтобы они не зацикливались. Для этого коммутатор, при получении широковещательного фрейма через обычный интерфейс, отправляет его в агрегированный канал только через один интерфейс. А при получении широковещательного фрейма из агрегированного канала, не отправляет его назад.

Хотя агрегирование каналов позволяет увеличить пропускную способность канала, не стоит рассчитывать на идеальную балансировку нагрузки между интерфейсами в агрегированном канале. Технологии по балансировке нагрузки в агрегированных каналах, как правило, ориентированы на балансировку по таким критериям: MAC-адресам, IP-адресам, портам отправителя или получателя (по одному критерию или их комбинации).

То есть, реальная загруженность конкретного интерфейса никак не учитывается. Поэтому один интерфейс может быть загружен больше, чем другие. Более того, при неправильном выборе метода балансировки (или если недоступны другие методы) или в некоторых топологиях, может сложиться ситуация, когда реально все данные будут передаваться, например, через один интерфейс.

Некоторые проприетарные разработки позволяют агрегировать каналы, которые соединяют разные устройства. Таким образом резервируется не только канал, но и само устройство. Такие технологии в общем, как правило, называются распределенным агрегированием каналов (у многих производителей есть своё название для этой технологии).

Агрегирование каналов в Cisco

Статическое агрегирование

Агрегирование с помощью LACP

Терминология и настройка

Общие правила настройки EtherChannel

Настройка EtherChannel

Так как для объединения в EtherChannel на интерфейсах должны совпадать многие настройки, проще объединять их, когда они настроены по умолчанию. А затем настраивать логический интерфейс.
Перед объединением интерфейсов лучше отключить их. Это позволит избежать блокирования интерфейсов STP (или перевода их в состояние err-disable).
Для того чтобы удалить настройки EtherChannel достаточно удалить логический интерфейс. Команды channel-group удалятся автоматически.

Синтаксис команды channel-group

Параметры команды:
active — Включить LACP,
passive — Включить LACP только если придет сообщение LACP,
desirable — Включить PAgP,
auto — Включить PAgP только если придет сообщение PAgP,
on — Включить только Etherchannel.

Комбинации режимов при которых поднимется EtherChannel:

Интерфейсы в состоянии suspended

Если настройки физического интерфейса не совпадают с настройками агрегированного интерфейса, он переводится в состояние suspended. Это будет видно в нескольких командах.

Просмотр состояния интерфейсов:

sw# show etherchannel summary
sw1#sh etherchannel port-channel

Настройка EtherChannel 2го уровня

Настройка статического EtherChannel 2го уровня

Перед настройкой агрегирования лучше выключить физические интерфейсы. Достаточно отключить их с одной стороны (в примере на sw1), затем настроить агрегирование с двух сторон и включить интерфейсы.

Настройка EtherChannel на sw1:

sw1(config)# interface range f0/11-14
sw1(config-if-range)# shutdown
sw1(config-if-range)# channel-group 3 mode on Creating a port-channel interface Port-channel 3

sw2(config)# interface range f0/11-14
sw2(config-if-range)# channel-group 3 mode on Creating a port-channel interface Port-channel 3

Настройка EtherChannel 2го уровня с помощью LACP

sw1(config)# interface range f0/11-14
sw1(config-if-range)# shutdown
sw1(config-if-range)# channel-group 1 mode active Creating a port-channel interface Port-channel 1

sw2(config)# interface range f0/11-14
sw2(config-if-range)# channel-group 1 mode passive Creating a port-channel interface Port-channel 1

sw1(config)# interface range f0/11-14
sw1(config-if-range)# no shutdown

Standby-интерфейсы

Перед настройкой агрегирования лучше выключить физические интерфейсы. Достаточно отключить их с одной стороны (в примере на sw1), затем настроить агрегирование с двух сторон и включить интерфейсы.

Настройка EtherChannel на sw1:

sw1(config)# interface range f0/11-20
sw1(config-if-range)# shutdown
sw1(config-if-range)# channel-group 1 mode active Creating a port-channel interface Port-channel 1

sw2(config)# interface range f0/11-20
sw2(config-if-range)# channel-group 1 mode passive Creating a port-channel interface Port-channel 1

Настройка EtherChannel 2го уровня с помощью PAgP

Перед настройкой агрегирования лучше выключить физические интерфейсы. Достаточно отключить их с одной стороны (в примере на sw1), затем настроить агрегирование с двух сторон и включить интерфейсы.

Настройка EtherChannel на sw1:

sw1(config)# interface range f0/11-14
sw1(config-if-range)# shutdown
sw1(config-if-range)# channel-group 2 mode desirable Creating a port-channel interface Port-channel 2

sw2(config)# interface range f0/11-14
sw2(config-if-range)# channel-group 2 mode auto Creating a port-channel interface Port-channel 2

sw1(config)# interface range f0/11-14
sw1(config-if-range)# no shut

Настройка EtherChannel 3го уровня

Для EtherChannels 3го уровня IP-адрес присваивается логическому интерфейсу port-channel, а не физическим интерфейсам.

Перед настройкой агрегирования лучше выключить физические интерфейсы. Достаточно отключить их с одной стороны (в примере на sw1), затем настроить агрегирование с двух сторон и включить интерфейсы.

sw1(config)# int port-channel 2
sw1(config-if)# no switchport
sw1(config-if)# ip address 192.168.12.1 255.255.255.0

sw2(config)# int port-channel 2
sw2(config-if)# no switchport
sw2(config-if)# ip address 192.168.12.2 255.255.255.0

Настройка агрегирования каналов на маршрутизаторе

R1(config)# interface port-channel 1
R1(config-if)# ip address 10.0.1.101 255.255.255.0

Пример настройки агрегирования каналов между коммутатором и маршрутизатором

Балансировка нагрузки

Метод балансировки нагрузки повлияет на распределение трафика во всех EtherChannel, которые созданы на коммутаторе.

При выборе метода балансировки, необходимо учитывать топологию сети, каким образом передается трафик.

Например, на схеме, все устройства находятся в одном VLAN. Шлюз по умолчанию маршрутизатор R1.

Если коммутатор sw2 использует метод балансировки по MAC-адресу отправителя, то балансировка выполняться не будет, так как у всех фреймов MAC-адрес отправителя будет адрес маршрутизатора R1:

Аналогично, если коммутатор sw1 использует метод балансировки по MAC-адресу получателя, то балансировка выполняться не будет, так как у всех фреймов, которые будут проходить через агрегированный канал, MAC-адрес получателя будет адрес маршрутизатора R1:

Определение текущего метода балансировки:

sw1# show etherchannel load-balance

Тестирование балансировки нагрузки

Проверка при задании IP-адресов:
Пример тестирования при задании MAC-адресов:

Источник

Основы компьютерных сетей. Тема №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.

Данная таблица отображает 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 для получения максимального распределения нагрузки. До встречи в следующей статье!

Источник