Как агрегируются порты (LAG, teaming, bonding EtherChannel и т.д.)

Приветствую.

 Это моя первая статья на Хабре. Говорят, для такого рода дебютов надо выбирать что-то предельно неизвестное. Но мне вот захотелось написать про агрегацию каналов, про которую уже, казалось бы, всякого писано-переписано.

Все уже написано о том, как она настраивается на всем возможном железе, как она балансируется, тоже много чего есть. Но во всем этом многообразии упущен один момент – а как именно порты собираются в агрегированные каналы на одном коммутаторе? Каким это таким магическим образом? Что их сподвигает работать как единый организм и на совершать при этом петель, штормов и прочих безобразий? Сразу скажу большое спасибо автору вот этой статьи, одна из ссылок в которой и вдохновила на данный литературный опыт.

Немного теории про порты и петли

Для того, чтобы понять как порты агрегируются, давайте вспомним как вообще работает порт, то есть погрузимся немного в пучины модели OSI. Если кто знает эту модель вдоль и поперек – переходите на следующий пункт.

Как мы знаем, порт коммутатора работает на двух уровнях: физическом (PHY) и канальном. А канальный подразделяется еще на два подуровня: уровень логического управления каналом (LLC) и уровень управления доступом к среде (MAC).

Для чего столько-то? У каждого своя специализация. Говоря по-простому: на физическом уровне электромагнитные колебания превращаются в биты (нули и единицы), которые передаются на уровень MAC.

Уровень MAC из этих битов собирает кадры. В этом ему помогают два его лучших друга: преамбула и межпакетный интервал. Но сегодня речь не о них. Собрав кадр, уровень MAC передает его на уровень LLC (клиент уровня MAC), на котором происходит магия коммутации, а именно:

1. Оценивается MAC-адрес назначения (MACDst). Если он групповой (младший бит старшего октета равен 1) то коммутатор отправляет его во все порты кроме порта получения. Так работает multicast и его частный случай broadcast.

2. Если MACDst индивидуальный (младший бит старшего октета равен 0) и он указан в таблице MAC-адресов, то кадр отправляется в определенный порт. Если MAC-адрес не указан в таблице MAC-адресов, он рассылается во все порты кроме порта получения. Такое явление называется unknown unicast, и может накозить траблов не меньше чем оба брата из п. 1.

3. В таблицу MAC-адресов вносится (изучается) значение поля MAC-адрес источника (MACSrc).

Вот в последнем пункте, как сказал бы последний Генсек КПСС, и порылась собака.

Дело в том, что коммутатор изучает MAC-адреса крайне прилежно, а значит если MAC оказывается не на том порту, на котором он уже изучен в таблице MAC-адресов, то… коммутатор ПЕРЕизучает его, то есть просто переписывает на новом порту таблицы. А значит, теперь в предыдущий порт можно пересылать кадры как будто на нем ничего изучено не было. Так вот петли и возникают.

Насмотревшись на это безобразие, инженеры компании Kalpana разработали технологию, которую назвали EtherChannel, которую и представили граду и миру в марте 1994 года (легкий офтоп – учитывая что эти же ребята придумали сам коммутатор, а потом VLAN, неудивительно что до конца 1994 года компания не дожила, ее купила Cisco).

Мысль у ребят была простая: надо «растянуть» подуровень LLC на несколько портов, чтобы каждый порт самостоятельно не изучал MAC-адреса и не вносил сумятицу в таблицу MAC-адресов. И вот теперь мы переходим к главному – КАК?

Как объединить несколько портов не привлекая внимания санитаров

Итак, что у нас получится, если мы для нескольких подуровней MAC сделаем один общий подуровень LLC?

Как-то так. Но как мы знаем из мема с Шоном Бином, «нельзя просто взять и» сделать что-то. Не перепайкой же платы заниматься, честное слово. Поэтому придумали некоторую «прокладку» – еще один подуровень, который назвали LAS (Link aggregation sublayer, подуровень агрегации каналов, кто бы мог подумать).

Что же должно происходить на этом подуровне? Очевидно, что он должен собирать кадры с нескольких MAC-подуровней для передачи единому интерфейсу, который будет выполнять роль LLC (MAC-клиенту). И наоборот, при передаче данных от MAC-клиента в сторону среды LAS должен определить через какой именно MAC-подуровень будет заниматься разбивкой кадра на биты и передачей их на физический уровень.

Назревает понимание, что на уровне LAS будут работать два процесса: один для сборки кадров, а второй – для распределения кадров. Так они и называются: первый Collector, а второй Distributor.

А общий для нескольких портов LLC называется теперь PortChannel.

То есть, когда администратор задает на порту коммутатора команду

Switch(config‑if)#channel‑group 1 mode on

он фактически сообщает MAC-подуровню порта: все собранные кадры ты, пожалуйста, отдавай коллектору №1, а если тебе передаст кадр дистрибьютор №1, ты уж будь любезен передать его в среду. И ведь передает.

Как передается трафик по агрегированным каналам?

Давайте посмотрим, как передаются разные пакеты по агрегированному каналу.

Для начала разберемся с BUM-кадрами (broadcast, unknown unicast, multicast), которые должны рассылаться во все возможные порты. В нашем случае, BUM-кадр будет передан только в один интерфейс – PortChannel. А дальше уже в дело вступит дистрибьютор, который и решит, по какому из MAC-подуровней передавать кадр в среду.

На  соседнем коммутаторе этот кадр будет передан на коллектор, и далее на PortChannel, где и будет изучен MAC-адрес источника в кадре. Как видим, никаких петель, так как… все правильно, коммутатор НЕ пересылает кадр в порт, на котором он был получен. Dura lex sed lex, как говорили недорезанные варварами древние римляне.

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

Многая знания — многия печали: теперь мы с вами понимаем, что объединение N портов никогда не даст нам N-кратного прироста пропускной способности, так как часть времени будет тратиться на работу коллектора и дистрибьютора.

Требования к портам

Раз уж мы теперь понимаем процесс работы LAS, а именно коллектора и дистрибьютора, мы можем логически вывести требования к портам, которые агрегируются в единый канал:

1. Порты должны «уметь» одновременно обрабатывать как исходящие, так и входящие кадры, то есть работать в режиме full duplex.

2. Порты должны иметь одну и ту же скорость, так как для нормальной работы коллектора, а особенно дистрибьютора, важно чтобы кадры обрабатывались единообразно.

3. Порты не должны иметь дополнительных фильтров на подуровне MAC. Такими фильтрами могут служить, например, условия прохождения тегированного трафика: проще говоря, все порты должны находится в одном режиме работы порта и иметь одинаковые настройки VLAN, а еще лучше – совсем их не иметь. Все необходимые настройки работы VLAN желательно производить уже на PortChannel-интерфейсе. Как говорил Саша Привалов Модесту Камноедову: «Во избежание…». Иначе это что же получается: дистрибьютор отправляет кадр на MAC-подуровень порта, а тот его никуда не пересылает. Нехорошо это.

Именно эти требования, как вы помните, написаны во всех курсах CCNA любой академии вендора на букву «Ц»,  и вот теперь понятно почему.

Также, надеюсь, теперь понятный флаги Collecting и Distributing в выводах WireShark по протоколу LACP.

Вместо заключения

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