etherchannel для чего нужен

Etherchannel на коммутаторах Cisco

Read the article CONFIGURING ETHERCHANNELS (LINK AGGREGATION) ON CISCO SWITCHES in English

Технология etherchannel (или port channel) позволяет из нескольких портов коммутатора (от 2 до 8) сделать один логический.
Эта технология используется для увеличения надежности соединения – трафик идет сразу по всем активным портам, а выход из строя любого физического порта никак не влияет на доступность всего соединения. Естественно, при использовании также увеличивается и скорость соединения

Важно!
Важно помнить, что подобные соединения возможно настроить только на портах с одинаковой пропускной способностью. Например на двух портах Fastethernet (100 + 100 Мбит/сек) или двух Gigabitethernet (1 + 1 Гбит/сек).
Нельзя объединить в один etherchannel интерфейсы Fastethernet (100Mb/s) и Gigabitethernet (1 Гбит/сек).

Важно!
Настройки etherchannel должны быть идентичными на обоих устройствах, которые соединяются подобным образом, будь то два коммутатора или коммутатор и сервер.

Для примера приведу настройки для соединения двух коммутаторов Cisco. Пусть это будут Cisco Catalyst 3560, хотя технология и синтаксис команды практически неизменен на всех моделях.

На первом коммутаторе SW-DELTACONFIG-1 необходимо создать логический интерфейс port-channel с уникальным порядковым номером (например 1)

SW-DELTACONFIG-1(config)#
interface port-channel1

Далее привязать к нему нужное количество физических портов. Не забудьте включить их командой no shut

SW-DELTACONFIG-1(config)#
interface Gi 0/1
channel-group 1 mode active
no shut

interface Gi 0/2
channel-group 1 mode active
no shut

Важно!
Я настоятельно рекомендую создавать подобные интерфейсы portchannel именно в такой последовательности:
— сначала сам логический интерфейс
— затем привязать его к физическим портам
— и уже после этого производить настройки логического интерфейса. Вся конфигурация переносится на физические порты автоматически.
Подобная последовательность исключит возможность ошибки в настройке, так как малейшее расхождение параметров ведет к некорректной работе всего portchannel.

Важно!
После включения физического интерфейса в логический на нем нельзя выполнять настройки. Любые изменения конфигурации производятся только (!) на логическом интерфейсе port-channel. Любое изменение на физическом порту коммутатора, включенного в port-channel ведет к выходу из строя всего агрегированного соединения.

На втором коммутаторе SW-DELTACONFIG-2 все настраивается аналогично. В примере оба коммутатора одинаковой модели Cisco Catalyst 3560 с идентичным набором интерфейсов. Поэтому отличия можно заметить только в поле description.

SW-DELTACONFIG-2(config)#
interface Gi 0/1
channel-group 1 mode active
no shut

interface Gi 0/2
channel-group 1 mode active
no shut

Проверка настроек

Помимо того, что стоит убедиться в наличии всех нужных строк в конфигурациях коммутаторов командой sh run, для проверки работы etherchannel используйте команду show etherchannel summary.

Number of channel-groups in use: 1
Number of aggregators: 1

Буквы P рядом с именами физических портов Gi 0/1 и Gi 0/2 означают, что интерфейсы функционируют исправно и входят в логическое подключение Portchannel 1. Символ D рядом с именем интерфейса будет означать, что интерфейс неактивен. Вероятнее всего стоить проверить соединение проводов и все настройки.

Важно!

Не забудьте сохранить конфигурацию на всех устройствах командой write или copy run start. Иначе после перезагрузки все изменения будут потеряны.
SWR-DELTACONFIG-1# write
Building configuration.
[OK]

Источник

Блог о системном администрировании. Статьи о Linux, Windows, СХД NetApp и виртуализации.

Приветствую всех. Сегодня я постараюсь внести ясность в такую неоднозначную и вызывающую много споров тему, как агрегирование каналов в Vmware. Многие (в том числе и производители оборудования) для описания агрегирования каналов применяют такие термины как LACP, 802.3ad, Ethernet trunk, NIC Teaming, Port Channel, Port Teaming, Link Bundling, NIC bonding, EtherChannel, link aggregation и некоторые другие. В целом, технология агрегирования каналов, это технология позволяющая объединить несколько физических каналов в один логический. Такое объединение позволяет увеличивать пропускную способность (он же Load Distribution или Load Balancing) и надежность канала (она же Failover). В данной статье, возможно, я сделал какие-то неверные выводы и буду благодарен за дополнения и комментарии. Для написания статьи я придерживался мануала Cisco IEEE 802.3ad Link Bundling, ибо только в нем нашел более менее систематизированные понятия.

Введение в агрегирование каналов (NIC Teaming)

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

Читайте также:  путевка матери и ребенка до какого возраста ребенка

Какие же требования необходимо выполнить, чтобы агрегирование каналов заработало корректно?

Режим работы EtherChannel

channel-group номер_группы mode
Это другие возможные режимы работы, но они нам не интересны, т.к. используют для согласования проприетарный протокол PAgP и vSphere не поддерживаются.

Работа протокола LACP будет возможна, при следующих конфигурациях сторон:

Режим работы LACP passive active
passive OK
active OK OK

То есть, не работающая конфигурация, когда обе стороны настроены в LACP passive режиме. Статическая агрегация IEEE 802.3ad возможна только когда обе стороны настроены в статическом режиме.

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

Кроме собственно настроек агрегации каналов, необходимо определиться с алгоритмом балансировки нагрузки, который должен иметь одинаковые параметры на обоих сторонах линка. Балансировка может производится по различным параметрам (а точнее по различным полям сетевого пакета/кадра). Большинство производителей сетевого оборудования могут поддерживать следующие параметры: MAC-адреса, IP-адреса или номера портов TCP/UDP, а также режим источника, режим назначения или оба режима. Vmware, дополнительно поддерживает балансировку по VLAN, Port ID, а так же любые комбинации всех описанных способов. Описание алгоритмов распределения нагрузки выходит далеко за рамки данной статьи. Для понимания работы, рекомендую почи тать Балансировка загрузки канала EtherChannel и избыточность на коммутаторах Catalyst в ссылках. Можно к ратко отметить, что выбирать алгоритм балансировки нагрузки необходимо основываясь на топологии Вашей сети и логике обмена данными между клиентами, использующими агрегированный канал. Вот хороший пример с xgu.ru.

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

Агрегация каналов ( NIC Teaming ) в VMware

NIC Teaming в Vmware vsphere до 5.5 (5.1.x, 4.x)

NIC Teaming по протоколу LACP в Vmware vsphere 5.5.x

VMware ESXi 5.5.x, как и прошлые версии поддерживает работу в режиме статического тиминга. Настройка его ни чем не отличается от той, которая написана в статье LACP, 802.3ad, load based IP hash и все такое. Далее, нас интересует настройка NIC Teaming с использованием согласования по протокол LACP на Vmware. В чем же польза LACP по сравнению с static aggregation:

Проверка корректности конфигурации. Агрегация каналов

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

Failover (обнаружение отказа). Если у вас имеется dumb-устройство между двумя концами EtherChannel, например media converter, и один из линков, идущих через него отказывает, LACP это понимает и перестает слать трафик в отказавший линк. Static EtherChannel не мониторит состояние линков. Это не типичная ситуация для большинства систем vSphere, которые мне встречались, но в ряде случаев это может оказаться полезным.

Типовой пример настройки NIC Teaming по протоколу LACP

Давайте на практике посмотрим как это выглядит. Предположим, что у нас уже создан некий Distributed Switch 5.5.0. Со свичом ассоциированы необходимые хосты. Создана некая портгруппа виртуальных машин в конфигурациях по умолчанию. Например:

Далее, перед настройкой LACP давайте рассмотрим некоторые аспекты настройки:

LACP не совместим с software iSCSI multipathing.

Итак, последовательность настройки LACP на Vmware следующая:

Назначить LAG как Standby интерфейс в настройке Teaming and Failover Order в Distributed Port Group.

Это рекомендованная мануалом последовательность. На самом деле, можно обойтись без шага №2. Просто задав ассоциацию свободных физических NIC к созданному LAG. Но тем не менее, давайте рассмотрим каждый шаг:

В vSphere Web Client переходим на наш созданный distributed switch.

Ассоциировать физические интерфейсы с LAG

В поле Failover order с помощью стрелок перемещаем наш созданный LAG в раздел Active, все остальные аплинки (если такие имеются) перемещаем в

Резюме

В текущей статье я постарался описать особенности работы с агрегированными каналами. Постарался описать статическую конфигурацию NIC Teaming и конфигурацию по протоколу LACP. Упор сделан не столько на практику, сколько на теорию и предоставление источников дальнейшего чтения для углубления изучения ) ИМХО, обзор получился несколько поверхностным, по возможности буду наполнять статью.

Источник

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

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

Агрегирование каналов может быть настроено между двумя коммутаторами, коммутатором и маршрутизатором, между коммутатором и хостом.

Для агрегирования каналов существуют другие названия:

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

Агрегирование каналов позволяет решить две задачи:

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

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

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

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

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

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

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

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

Для агрегирования каналов в Cisco может быть использован один из трёх вариантов:

Так как LACP и PAgP решают одни и те же задачи (с небольшими отличиями по возможностям), то лучше использовать стандартный протокол. Фактически остается выбор между LACP и статическим агрегированием.

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

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

При настройке агрегирования каналов на оборудовании Cisco используется несколько терминов:

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

На схеме, число после команды channel-group указывает какой номер будет у логического интерфейса Port-channel. Номера логических интерфейсов с двух сторон агрегированного канала не обязательно должны совпадать. Номера используются для того чтобы отличать разные группы портов в пределах одного коммутатора.

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

LACP и PAgP группируют интерфейсы с одинаковыми:

Настройка EtherChannel:

Создание EtherChannel для портов уровня 2 и портов уровня 3 отличается:

После того как настроен EtherChannel:

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

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

Комбинации режимов при которых поднимется EtherChannel:
Режим PAgP auto desirable
auto EtherChannel
desirable EtherChannel EtherChannel
Режим LACP passive active
passive EtherChannel
active EtherChannel EtherChannel

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

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

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

Просмотр информации о EtherChannel:

Команды просмотра информации

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

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

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

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

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

Включение физических интерфейсов на sw1:

Просмотр информации

Суммарная информация о состоянии Etherchannel:

Информация о port-channel на sw1:

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

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

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

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

Включение физических интерфейсов на sw1:

Просмотр информации

Суммарная информация о состоянии Etherchannel:

Информация о port-channel на sw1:

Информация о port-channel на sw2:

Информация LACP о локальном коммутаторе:

Информация LACP об удаленном коммутаторе:

Счетчики LACP:

LACP system ID:

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

LACP позволяет агрегировать до 16ти портов, 8 из которых будут активными, а остальные в режиме standby.

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

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

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

Включение физических интерфейсов на sw1:

Информация LACP об удаленном коммутаторе:

Интерфейсы в режиме standby не передают трафик, поэтому по CDP сосед не виден через эти порты:

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

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

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

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

Включение физических интерфейсов на sw1:

Просмотр информации

Суммарная информация о состоянии Etherchannel:

Информация о port-channel на sw1:

Информация PAgP о локальном коммутаторе:

Информация PAgP об удаленном коммутаторе:

Счетчики PAgP:

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

Настройка EtherChannel 3го уровня очень мало отличается от настройки EtherChannel 2го уровня. Поэтому в этом разделе показан только один пример настройки, с использованием LACP. Остальные варианты настраиваются аналогично, с изменением режима агрегирования. Команды просмотра аналогичны, их можно посмотреть в предыдущих разделах.

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

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

Настройка логического интерфейса на sw1:

Настройка физических интерфейсов на sw1:

Создание логического интерфейса на sw2:

Настройка физических интерфейсов на sw2:

Включение физических интерфейсов на sw1:

Просмотр информации

Суммарная информация о состоянии Etherchannel:

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

Особенности настройки агрегирования на маршрутизаторе:

Создание агрегированного интерфейса на маршрутизаторе:

Добавление физических интерфейсов в EtherChannel:

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

Информация о etherchannel на sw1:

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

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

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

Пример вариантов на коммутаторе 3560:

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

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

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

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

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

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

Для того чтобы проверить через какой интерфейс, при настроенном методе балансировки, пойдет конкретный пакет или фрейм, можно использовать команду test etherchannel load-balance.

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

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

Источник

Сказочный портал