Между двумя коммутаторами не хватает полосы. Очевидное решение — проложить второй кабель — не работает: два независимых линка между одними и теми же устройствами образуют петлю, и STP немедленно погасит один из них. Полосы не прибавилось, зато появился резерв, который простаивает.

Агрегация решает обе задачи разом: несколько физических портов объявляются одним логическим. Для STP это один порт — гасить нечего. Для таблицы MAC-адресов это тоже один порт, и адрес не скачет между двумя записями. А трафик при этом идёт по обоим кабелям.

Отсюда и двойная выгода, ради которой всё делается: суммарная полоса растёт, и отказ одного кабеля не рвёт связь — оставшиеся продолжают работать, канал просто становится уже. Пользователи такого отказа обычно не замечают вовсе.

Самое частое разочарование звучит так: «собрали агрегат из двух гигабитных портов, а файл копируется всё равно на гигабите». Так и должно быть.

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

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

Отсюда практический вывод: агрегация — это про суммарную пропускную способность и живучесть, а не про ускорение конкретной передачи.

Решение, по какому линку отправить кадр, принимается один раз для каждого потока — по хешу от полей заголовка. Что именно берётся в расчёт, зависит от настройки:

• только MAC-адреса — самый простой вариант;
• плюс IP-адреса;
• плюс номера портов TCP или UDP — самый мелкий помол.

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

Поэтому современная рекомендация — хеш по адресам и портам (в командах это обычно выглядит как src-dst-port). И даже он не гарантирует ровного распределения: хеш — не счётчик, а функция. Два тяжёлых потока могут попасть в один линк, и это нормальное поведение, а не неисправность.

Агрегат можно собрать двумя способами.

Статически: администратор просто объявляет порты агрегатом с обеих сторон. Работает, пока обе стороны настроены правильно. Ошибся в одном порту — и кадры полетят туда, где их не ждут, а виноватого искать придётся долго.

Через LACP (стандарт IEEE 802.3ad, ныне 802.1AX): устройства обмениваются служебными кадрами и договариваются, какие порты действительно ведут к одному и тому же соседу и готовы работать вместе. Порт, чей партнёр не отозвался, в агрегат просто не включается.

У участника есть режим:
• active — сам начинает переговоры;
• passive — отвечает, но не инициирует.

Два пассивных участника рискуют не договориться вовсе — на части оборудования такая пара так и останется молчать. Надёжная практика простая: ставьте active хотя бы с одной стороны, а лучше с обеих.

И главный довод в пользу LACP: он ловит ошибку коммутации. Воткнули кабель не в тот порт или не в тот коммутатор — LACP это увидит по идентификатору партнёра и не соберёт агрегат. Статический агрегат в такой ситуации будет уверенно слать трафик в никуда.

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

• скорость и дуплекс — гигабитный и стомегабитный порт в один агрегат не собрать;
• режим порта — все access или все trunk, вперемешку нельзя;
• набор VLAN на транке — расхождение приводит к тому, что часть VLAN ходит через раз, в зависимости от того, в какой линк попал хеш;
• сам факт настройки агрегата с обеих сторон.

Последний пункт стоит отдельного внимания: агрегат настраивают всегда на обоих концах. Одностороннего агрегата не бывает. Порты, собранные в агрегат только у себя, на той стороне остаются независимыми — и это прямая петля.

Расхождение по VLAN коварнее всего: связность вроде бы есть, но воспроизводимо ломается для одних отделов и работает для других. Ищут такое обычно долго, потому что «сеть же работает».

Обрыв кабеля коммутатор видит сразу — пропадает несущая, порт уходит из агрегата за миллисекунды. Но линк может быть поднят и при этом мёртв: между устройствами стоит медиаконвертер, оптический канал оператора, туннель. Порт горит, кадры не ходят.

Такой отказ ловится только по молчанию LACP, и здесь всё зависит от режима:
• slow (по умолчанию) — кадры раз в 30 секунд, партнёр признаётся мёртвым через 90;
• fast — раз в секунду, отказ виден через 3.

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

Обычный агрегат защищает от обрыва кабеля, но не от отказа самого коммутатора: оба конца воткнуты в одну железку, и её отказ уносит всё.

Лечится это тем, что два коммутатора притворяются одним. У разных вендоров приём называется по-разному — MLAG, vPC, стек, виртуальное шасси, — но суть одна: сервер собирает обычный агрегат, а его кабели уходят в разные физические устройства, которые договорились между собой отвечать одним идентификатором LACP.

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

Практический смысл: подключать важные серверы одним агрегатом в два коммутатора — стандарт де-факто в датацентрах.

Агрегат собран только с одной стороны. На той стороне порты остались независимыми — получилась петля со всеми последствиями. Если работает LACP, он такой агрегат просто не соберёт; статический соберётся и устроит шторм.

С одной стороны LACP выключен. Вторая сторона не получает ответа и не выпускает трафик в линки вовсе — канал встаёт целиком, хотя кабели целы и порты горят.

Обе стороны в пассивном режиме. На части оборудования переговоры так и не начинаются.

Разный набор VLAN на членах. Часть трафика ходит, часть нет, воспроизводимость зависит от хеша.

Ждали удвоения скорости одной передачи. Не ошибка настройки, а ошибка ожиданий — но обсуждать её приходится регулярно.

Хеш только по MAC при трафике через один роутер. Весь трафик в одном линке, второй пустой. Лечится сменой режима балансировки.

Медленные таймеры на ответственном стыке. Линк «поднят, но мёртв» держится в агрегате до полутора минут, и всё это время часть трафика уходит в никуда.

show etherchannel summary — с чего начинают всегда. Одной строкой видно, собрался ли агрегат (Po1(SU) против (SD)), каким протоколом и какие порты в нём: флаг (P) — порт в работе, (s) — подвешен, (D) — погашен.

show lacp internal — подробности переговоров со своей стороны. Строка статуса negotiated означает, что сосед ответил; configured — что мы настроены, а партнёр молчит.

show lacp neighbor — кто именно ответил. Здесь обнаруживается кабель, воткнутый не в тот коммутатор: идентификатор партнёра у портов одной группы окажется разным.

show etherchannel detail — раскладка потоков и темп служебных кадров, то есть ответ на вопрос «почему работает только один линк».

И общая привычка: смотреть с обеих сторон. Половина проблем агрегации видна только при сравнении двух выводов — на одной стороне всё выглядит нормально.

# собрать агрегат: команда даётся на каждом порту
interface eth1
 channel-group 1 mode active     # 1 — номер агрегата, одинаковый у всех членов.
                                 #   mode active — сам начинает переговоры LACP;
                                 #   passive — только отвечает на чужие;
                                 #   on — вообще без LACP, склеить принудительно
interface eth2
 channel-group 1 mode active     # тот же номер — значит тот же агрегат

# раскладка потоков — команда глобальная
port-channel load-balance src-dst-port
                                 # по каким полям считать хеш: src-dst-port учитывает
                                 #   адреса и номера портов. Бывают src-mac, dst-mac,
                                 #   src-dst-ip. Чем больше полей, тем ровнее раскладка

# темп служебных кадров — на самом агрегате
interface port-channel1          # номер в имени — тот самый номер группы
 lacp rate fast                  # fast — раз в секунду, партнёр считается мёртвым
                                 #   через 3; normal (по умолчанию) — раз в 30 секунд
 switchport mode trunk           # настройки задаются агрегату, а не его членам:
                                 #   иначе порты разъедутся и группа развалится

# проверка
show etherchannel summary        # сводка: состояние группы и флаги портов
show etherchannel detail         # подробности, включая режим раскладки потоков
show lacp internal               # своя сторона переговоров: режим, статус
show lacp neighbor               # что о переговорах думает сосед

Пока в группе один порт, собирать агрегат не из чего — вендорское железо выводит такой порт из работы (suspended), и связь по нему пропадает до прихода второй команды. Это штатное поведение, а не поломка.