Приветствую.
Это моя первая статья на Хабре. Говорят, для такого рода дебютов надо выбирать что-то предельно неизвестное. Но мне вот захотелось написать про агрегацию каналов, про которую уже, казалось бы, всякого писано-переписано.
Все уже написано о том, как она настраивается на всем возможном железе, как она балансируется, тоже много чего есть. Но во всем этом многообразии упущен один момент – а как именно порты собираются в агрегированные каналы на одном коммутаторе? Каким это таким магическим образом? Что их сподвигает работать как единый организм и на совершать при этом петель, штормов и прочих безобразий? Сразу скажу большое спасибо автору вот этой статьи, одна из ссылок в которой и вдохновила на данный литературный опыт.
Немного теории про порты и петли
Для того, чтобы понять как порты агрегируются, давайте вспомним как вообще работает порт, то есть погрузимся немного в пучины модели 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.
Вместо заключения
Автор надеется, что ему удалось пояснить механизм работы агрегации каналов, так как эта тема, как ему кажется, незаслуженно обойдена в учебных материалах некоторых уважаемых вендоров.
Автор: stasische
