Агрегация каналов: bonding и teaming в Linux

Один сетевой порт — это одновременно ограничение скорости и единая точка отказа. Когда сервер отдаёт резервные копии, обслуживает виртуальные машины или работает с хранилищем, второй кабель и правильная агрегация заметно повышают надёжность. В Linux есть два инструмента: проверенный временем bonding в ядре и teaming через teamd. Разберём режимы, настройку через NetworkManager, требования к коммутатору и диагностику, которая показывает реальное состояние каналов.

Что даёт агрегация, а что нет

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

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

Режимы bonding

Режим задаётся параметром mode. Номера и имена стоит помнить, потому что они встречаются в конфигурациях и документации.

• balance-rr (0) — пакеты по очереди; не требует настройки коммутатора, но может переупорядочивать кадры.
• active-backup (1) — один активный порт, остальные в резерве; самый совместимый режим.
• balance-xor (2) — выбор порта по хешу источника и назначения; без LACP.
• broadcast (3) — кадр уходит во все порты; применяется редко, для специфичных задач.
• 802.3ad (4) — LACP, динамическая агрегация; требует настройки коммутатора.
• balance-tlb (5) и balance-alb (6) — адаптивная балансировка без настройки коммутатора, только на стороне Linux-хоста.

Для сервера с managed-коммутатором стандартный выбор — 802.3ad. С неуправляемым коммутатором берите active-backup: отказоустойчивость без согласования режимов.

Настройка bonding через nmcli

NetworkManager создаёт интерфейс bond, затем добавляет в него физические порты. Порядок важен: сначала мастер, потом slave-подключения. Имена интерфейсов подставьте свои — их показывает ip -brief link.

nmcli con add type bond con-name bond0 ifname bond0 mode 802.3ad miimon 100
nmcli con add type ethernet con-name bond0-p1 ifname enp3s0 master bond0
nmcli con add type ethernet con-name bond0-p2 ifname enp4s0 master bond0
nmcli con mod bond0 ipv4.method manual ipv4.addresses 192.168.1.10/24 ipv4.gateway 192.168.1.1 ipv4.dns 192.168.1.1

Параметр miimon=100 включает проверку несущей каждые 100 мс: при обрыве линка трафик переключается за доли секунды. Для LACP дополнительно задайте lacp-rate fast и политику хеширования, например xmit_hash_policy layer3+4. Затем поднимите соединения:

nmcli con up bond0
nmcli con up bond0-p1
nmcli con up bond0-p2
nmcli device status

Если адрес выдаётся по DHCP, вместо ручных параметров оставьте ipv4.method auto. У slave-портов не должно быть своих адресов: NetworkManager не даст использовать интерфейс в двух профилях одновременно.

LACP и настройка коммутатора

В режиме 802.3ad обе стороны обмениваются управляющими пакетами LACPDU и договариваются об агрегате. На коммутаторе порты объединяют в port-channel или LAG с режимом active. Если одна сторона настроена на статическую агрегацию, а другая на LACP, линк не поднимется или будет работать нестабильно.

Требования просты: одинаковая скорость и дуплекс на всех портах, одинаковый VLAN-режим, согласованный MTU. Коммутатор тоже использует хеш для балансировки. На Linux политика задаётся параметром xmit_hash_policy:

nmcli con mod bond0 bond.options "mode=802.3ad,miimon=100,xmit_hash_policy=layer3+4"
sudo ip link set bond0 mtu 9000
cat /proc/net/bonding/bond0

layer2+3 учитывает MAC и IP, layer3+4 добавляет порты — он лучше распределяет множество коротких соединений. encap2+3 и encap3+4 нужны для инкапсулированного трафика. Менять политику на лету можно, но часть соединений при этом переедет на другой порт.

Teaming и его текущий статус

Teaming появился как замена bonding с гибкой конфигурацией в JSON и разными runner-ами: activebackup, broadcast, roundrobin, lacp, loadbalance. Управляет им демон teamd, а NetworkManager поддерживает тип соединения team.

nmcli con add type team con-name team0 ifname team0 config '{"runner": {"name": "activebackup"}}'
nmcli con add type ethernet con-name team0-p1 ifname enp3s0 master team0
teamdctl team0 state
systemctl status teamd

На практике teaming считается устаревающим: Red Hat объявил teamd deprecated в RHEL 9 и убрал его в RHEL 10, а сообщество постепенно возвращается к bonding. Для новых установок в 2026 году разумнее сразу использовать bonding: он встроен в ядро, не требует демона и покрывает те же сценарии. Teaming оставьте для систем, где он уже настроен и работает.

Диагностика и проверка отказоустойчивости

Главный источник правды — /proc/net/bonding/bond0. Там видны режим, состояние каждого slave, скорость, дуплекс, счётчик обрывов и состояние LACP. Для team-интерфейсов используйте teamdctl, для общего списка — ip -brief link.

cat /proc/net/bonding/bond0
ip -brief link show bond0
ethtool bond0
journalctl -u NetworkManager -n 50 --no-pager

В выводе ищите MII Status: up у всех портов и Aggregator ID в режиме 802.3ad: одинаковый ID означает, что порты попали в один агрегат. Счётчик link failure count растёт при физических проблемах — плохой кабель, окисленный коннектор, несовпадение скорости.

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

sudo ip link set enp3s0 down
watch -n 1 cat /proc/net/bonding/bond0
sudo ip link set enp3s0 up
ping -I bond0 192.168.1.1

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

Типичные ошибки

• Порты агрегата подключены к разным коммутаторам без MLAG или стека — LACP не поднимется.
• На коммутаторе включён статический LAG, а на сервере — 802.3ad.
• Скорость или дуплекс портов различаются, либо один кабель повреждён.
• MTU на bond и на slave-портах не совпадает, из-за чего крупные пакеты теряются.
• Ожидание, что один поток ускорится вдвое: хеширование не делит одно соединение.
• Забытый miimon: переключение происходит только после сброса линка, а не сразу.

Итог

Bonding в Linux решает две разные задачи — пережить отказ порта и распределить нагрузку между линиями. Для отказоустойчивости достаточно active-backup, для производительности нужен 802.3ad и согласованная настройка коммутатора. Начинайте с проверки режимов и LACP, настраивайте через nmcli, а состояние всегда сверяйте по /proc/net/bonding. Teaming пока работает, но для новых систем выбирайте bonding — меньше движущихся частей и предсказуемое поведение.