Протокол lacp что это

Что такое Slow Protocols

Я как-то никогда не задумывался о том, как работает протокол LACP. Знаю, что делает, для чего нужен, а как передаются его сообщения никогда не интересовало.

Но некоторое время назад мне на глаза попался дамп трафика между двумя маршрутизаторами, где как раз были запросы LACP. Пробежал по нему мельком и глаз зацепился за незнакомое слово — Slow-Protocols.
На удивление информации об этом стандарте на русском языке я практически не нашёл. Есть только отсылки к тому, что это часть стандарта 802.3.

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

Итак, есть такой класс протоколов, которые призваны контролировать различные аспекты Ethernet, иначе говоря, Flow Control. Они являются частью стандарта 802.3 и делятся на два вида:

Случаться такое может при подключении друг к другу разноскоростных интерфейсов — например FE в GE. Либо при настройке ограничения скорости на портах коммутаторов. Случаются даже казусы, но мне с такими проблемами дела иметь не приходилось.

Однажны я сталкивался с Pause Frame в их несвойственном поведении. В тот день счётчики полученных PAUSE Frames стремительно росли на интерфейсах, система мониторинга тонула в авариях, дождь не прекращался 7-е сутки. Начали анализировать: количество трафика на данных интерфейсах едва переваливало за пару процентов, ни дропов, ни ошибок. Причём, что самое удивтельное, на противоположном конце устройство не отправляло эти самые PAUSE Frames — счётчики Pause Frame Output по нулям. Какая-то фанатастика, потому что промежуточных устройств даже транзитных нет.
Путём глубокой отладки с участием разработчиков тогда выяснилось, что это какие-то внутренние железные заморочки — чип коммутации имеет маленький буфер и отправляет на линейную плату Pause Frames, чтобы она снизила активность, но всё это хитрым образом разруливается внутри коробки и никак не влияет на сервисы.

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

Ограничения
Во-первых, на такого вида протоколы накладываются следующие ограничения:

1) Передавать не более 10 кадров в секунду
2) Максимальное число протоколов с EtherType 8809 — десять. Теоретически их может быть больше, но для них уже будет указан другой тип в заголовке Ethernet.
3) Размер кадра «медленных» протоколов ограничен 128 байтами. *Не сказать, что выполняется честно — OAMPDU, например, спокойно может превышать этот размер.

Вышеуказанные ограничения преследуют простую цель — уменьшить объём служебного трафика в сети.

Как для протоколов более высокого уровня существуют специально выделенные мультикастовые IP-адреса (224.0.0.5 для OSPF, например), так и «медленным» протоколам назначили отдельный мультикастовый MAC-адрес: 01-80-C2-00-00-02.

Данный МАС-адрес принадлежит диапазону выделенному ISO/IEC 15802-3 для протоколов, ограниченных одним линком. Фактически это означает, что кадры, передающиеся на данный адрес не могут быть перенаправлены за пределы данного конкретного линка.

Вполне возможно, что могут существовать «медленные» протоколы, которые требуют юникастовой пересылки кадра — это не воспрещается. То есть адрес 01-80-C2-00-00-02 — это не требование — это пожелание.
«Медленный» протокол может использовать другой МАС-адрес, но никакой другой протокол, кроме «медленного», не может использовать данный (01-80-C2-00-00-02).

Как уже я заметил выше, тип протоколов группы «Slow Protocols» (EtherType) — 8809. Далее определяются подтипы — subtypes для конкретных представителей сего славного класса:

Как видите, выделено 8 бит под подтип. О типе 10 поговорим чуть ниже, а с остальными всё понятно:
1 — обычный знакомый нам LACP

2 — также часть механизма LAG для балансировки нагрузки, упорядоченного получения кадров и оптимизации управления линками LAG.
3 — протоколы Ethernet OAM.

Как нужно вести себя при получении кадра Slow Protocols

1) Отбросить все кадры, в которых указаны запрещённые подтипы Slow protocols
2) Пропустить кадры, которые несут известные Slow протоколы (с известными подтипами) и передать их соответсвующим службам.
3) Пропустить кадры, которые несут валидные, но неизвестные протоколы и передать их MAC-клиенту.

По сути, два известных нам сейчас протокола, которые используют этот стандарт — это LACP и OAM, но вообще-то есть возможность создать собственный «медленный» протокол по своим нуждам. Это и есть тот самый пункт десять — OSSP — Organization Specific Slow Protocol.

Это относится к приложению 57B, которое описывает рекомендации к реализации каких-то специфических протоколов.

Как и у других протоколов есть свои названия их кадров (LACPDU, OAMPDU, BPDU), у OSSP есть неки обобщённый термин для этих целей — OSSPDU.

Далее идут совершенно логичные требования к структуре кадра OSSPDU и правилам передачи в сеть, но стандарт, на то и стандарт, что описывает все тонкости.

В общем я убрал это поглубже.

Organization Specific Slow Protocol Data Unit состоит из целого числа октетов. Биты в каждом октете нумеруются с 0 до 7. Когда последовательность октетов используется для представления численных значений, наиболее значимые октеты должны передаваться первыми.

а) Октеты передаются сверху вниз
б) В пределах октета биты расположены от 0 до 7 слева направо и передаются также слева направо.
в) Когда последовательность октетов представляет численное значение, наиболее значимые октеты должны передаваться первыми.
г) Когда последовательность октетов представляет MAC-адрес, наименее значимый бит первого октета несёт первый бит MAC-адреса. Следующий по значимости бит октета несёт второй бит MAC-адреса. И так далее до 8-го бита. Таким же образом от наименее значимого до наиболее значимого битов 2-го октета назначаются 9-17 биты МАС-адреса. Энд соу он, как говорится.

OSSPDU должен содержать следующие поля:

а) МАС-адрес назначения. Как правило мультикастовый адрес, выделенный для Slow Protocols — 01-80-C2-00-00-02.
б) МАС-адрес отправителя. Юникастовый адрес отправляющего интерфейса (LAG’а, если говорим об агрегированном канале)
в) Поле Length/Type содержит EtherType 8809
г) Поле Subtype содержит значения 10 (0x0A)
д) Поле OUI — Organizationally Unique Identifier. Некий идентификатор для данных.
е) Собственно данные протокола
ё) FCS. Но кого он волнует, если его формирует сам Ethernet?

Вот и весь сказ об этих нехитрых, но малоописанных в рунете протоколах.

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

Источник

Агрегирование портов. LACP.

Агрегирование порта

Что делать, если одного соединения пропускной способности в 100M/1G/10G/100G недостаточно для ваших нужд? Теоретическим, мы можем соединить оборудование несколькими линками, но без агрегирования мы получим только петлю на оборудовании, в результате чего положим сеть, если, конечно, не будет включен протокол Spanning Tree, который воспримет эти соединения как петли и не выключит лишние линки. Почему образуется петля? Это связано с работой коммутаторов, подробнее можно прочитать тут

Давайте рассмотрим, что такое агрегация и агрегированные порты и зачем это надо.

В терминологии CISCO это Etherchannel, Brocade — LAG, Extreme — sharing… Стандартизированное решение — LACP(Link Aggregation Control Protocol) — протокол, который не зависит от вендора (производителя) оборудования. Все реализации объединения/агрегирования портов выполняют одну функцию, а именно, объединение физических портов в 1 логический с суммарной пропускной способностью.

В данное время практически все провайдеры, цоды, дата-центры, контент-генераторы использую агрегацию для увеличения пропускной способности линии,так как ее плюсы очевидны: увеличение пропускной способности и резервирование линков (при падении одного, трафик равномерно распределяется между другими). Однако, находятся и те, которые не используют лаг, например, всем известная социальная сеть Вконтакте. Если вам придется с ними работать, то, возможно, вас удивит их заявление, что они не агрегируют линки. Вконтакте заставят вас настроить протокол динамической маршрутизации через каждый линк ( BGP), будь у вас там их хоть 16.

Протокол LACP

Рассмотрим, как работает агрегация на примере протокола LACP.

1. Пассивный режим, при котором оборудование ждет от соседа LACPDU пакеты и только тогда начинает высылать свои.

2. Активный режим, при котором оборудование постоянно шлет LACPDU пакеты.

Для того, чтобы LACP заработал, требуется одинаковая скорость и емкость каналов.

В результате установления работы протокола LACP коммутаторы обмениваются:

• System Identifier (priority + MAC)
• Port Identifier (priority + номер порта)
• Operational Key (параметры порта)

Это требуется для того, чтобы лаг не собрался как-нибудь не так, например как показано на рисунке 2.

Балансировка трафика в лаге

Балансировка трафика осуществляется посредством выбора физического канала отправителем фрейма посредством выбранного алгоритма. К основным и часто используемым можно отнести следующие алгоритмы :

Соответственно, если в лаге будет 3 линка, то как можно догадаться при использовании данного метода равномерной балансировки добиться будет сложно и пойдет перекос по трафику на какой-либо линк. Поэтому следует относиться внимательно к выбору метода балансировки.

Источник

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

Источник