Для того, чтобы понять как порты агрегируются, давайте вспомним как
вообще работает порт, то есть погрузимся немного в пучины модели OSI.
Если кто знает эту модель вдоль и поперек – переходите на следующий
пункт.
Как мы знаем, порт коммутатора работает на двух уровнях:
физическом (PHY) и канальном. А канальный подразделяется еще на два
подуровня: уровень логического управления каналом (LLC) и уровень
управления доступом к среде (MAC).
Для чего столько-то? У каждого своя специализация. Говоря по-простому: на физическом уровне электромагнитные колебания превращаются в биты (нули и единицы), которые передаются на уровень MAC.
Уровень MAC из этих битов собирает
кадры. В этом ему помогают два его лучших друга: преамбула и межпакетный
интервал. Но сегодня речь не о них. Собрав кадр, уровень MAC передает
его на уровень LLC (клиент уровня MAC), на котором происходит магия
коммутации, а именно:
- Оценивается MAC-адрес назначения
(MACDst). Если он групповой (младший бит старшего октета равен 1) то
коммутатор отправляет его во все порты кроме порта получения. Так работает multicast и его частный случай broadcast. - Если MACDst индивидуальный (младший бит старшего октета равен 0) и он указан в таблице MAC-адресов, то кадр отправляется в определенный порт. Если MAC-адрес не указан в таблице MAC-адресов, он рассылается во все порты кроме порта получения. Такое явление называется unknown unicast, и может накозить траблов не меньше чем оба брата из п. 1.
- В таблицу 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, а именно коллектора и дистрибьютора, мы
можем логически вывести требования к портам, которые агрегируются в
единый канал:
- Порты должны «уметь» одновременно обрабатывать как исходящие, так и входящие кадры, то есть работать в режиме full duplex.
- Порты
должны иметь одну и ту же скорость, так как для нормальной работы
коллектора, а особенно дистрибьютора, важно чтобы кадры обрабатывались
единообразно. - Порты не должны иметь дополнительных
фильтров на подуровне MAC. Такими фильтрами могут служить, например,
условия прохождения тегированного трафика: проще говоря, все порты
должны находится в одном режиме работы порта и иметь одинаковые
настройки VLAN, а еще лучше – совсем их не иметь. Все необходимые
настройки работы VLAN желательно производить уже на
PortChannel-интерфейсе. Как говорил Саша Привалов Модесту Камноедову:
«Во избежание...». Иначе это что же получается: дистрибьютор отправляет
кадр на MAC-подуровень порта, а тот его никуда не пересылает. Нехорошо
это.
Именно эти требования, как вы помните, написаны во
всех курсах CCNA любой академии вендора на букву «Ц», и вот теперь
понятно почему.
Также, надеюсь, теперь понятный флаги Collecting и Distributing в выводах WireShark по протоколу LACP.