# Bonding і LACP: об'єднання портів сервера

> Bonding і LACP на виділеному сервері збільшують швидкість каналу і захищають від обриву порту — режими, налаштування і перевірка.

## Навіщо об'єднувати мережеві порти сервера

Об'єднання портів (bonding, а на рівні комутатора — link aggregation) вирішує два завдання: збільшує пропускну здатність каналу понад [швидкість одного порту](https://www.zevshost.net/uk/kb/kanal-servera-trafik-unmetered/) і додає відмовостійкість — якщо один кабель або порт комутатора відключиться, трафік продовжить йти через інші інтерфейси без розриву з'єднань.

У більшості серверів є 2-4 мережеві порти на 1 або 10 Гбіт/с. Окремо кожен з них обмежений своєю швидкістю, а бондинг із двох портів по 10 Гбіт/с у режимі LACP теоретично дає 20 Гбіт/с сумарної пропускної здатності, хоча одне TCP-з'єднання, як і раніше, обмежене швидкістю одного фізичного лінка.

## Режими bonding: який обрати

У Linux драйвер bonding підтримує кілька режимів, але на практиці використовують три:

- **active-backup (mode 1)** — один порт активний, другий у резерві. Не потребує налаштування на комутаторі, але не збільшує швидкість.
- **balance-rr (mode 0)** — пакети йдуть по портах round-robin. Дає приріст швидкості для UDP, але часто ламає порядок TCP-пакетів.
- **802.3ad, він же LACP (mode 4)** — стандартний протокол агрегації, узгоджений із комутатором. Розподіляє з'єднання за хеш-функцією від MAC/IP/порту, потребує налаштування LACP з обох сторін.

Для продакшн-серверів у дата-центрі використовують LACP: він єдиний із трьох офіційно узгоджений із боку комутатора і коректно обробляє відмову лінка.

## Налаштування LACP на сервері та комутаторі

У Linux з NetworkManager бонд створюють так:

```
nmcli connection add type bond ifname bond0 mode 802.3ad
nmcli connection modify bond0 +bond.options "lacp_rate=fast,miimon=100"
nmcli connection add type ethernet ifname eth0 master bond0
nmcli connection add type ethernet ifname eth1 master bond0
nmcli connection up bond0
```

Через netplan конфігурація виглядає так:

```
network:
  version: 2
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
      addresses: [203.0.113.10/24]
```

На боці комутатора порти, до яких підключений сервер, об'єднують у port-channel із увімкненим LACP active. Якщо комутатор налаштований у режимі static (без LACP) — bonding у режимі 802.3ad не запрацює, обидва кінці зобов'язані узгодити протокол.

## Як перевірити, що бондинг працює

Статус інтерфейсу та режим узгодження LACP дивляться так:

```
cat /proc/net/bonding/bond0
ip -s link show bond0
```

У виводі важливий рядок `MII Status: up` для кожного slave-інтерфейсу та `Aggregator ID` — він має збігатися в обох портів, якщо вони реально агреговані. Пропускну здатність після налаштування варто виміряти через [iperf3](https://www.zevshost.net/uk/kb/benchmark-servera-fio-sysbench/) з двох боків одночасно, запустивши кілька паралельних потоків (-P 4), щоб задіяти хешування за різними з'єднаннями.

## Типові помилки: чому LACP «не злітає»

Найчастіше проблема в розсинхроні налаштувань між сервером і комутатором. Часті причини:

| Симптом | Причина |
| --- | --- |
| Bond піднято, але швидкість як в одного порту | На комутаторі порти не в одному port-channel |
| Aggregator ID різний у портів | Різні VLAN або швидкість на портах комутатора |
| Лінк постійно flap-ає | miimon занадто малий або кабель/SFP несправний |
| Одне TCP-з'єднання не пришвидшується | Хеш-алгоритм LACP розподіляє за потоками, а не ріже один потік |

Ще одна часта помилка — увімкнути LACP на сервері, але залишити порти на комутаторі в окремих VLAN без port-channel. Тоді bond0 підніметься локально, але реального агрегування не буде: трафік просто піде через один фізичний порт.

## Чек-лист перед введенням в експлуатацію

- Режим LACP (802.3ad) налаштований однаково на сервері й на комутаторі, порти зведені в один port-channel.
- У `/proc/net/bonding/bond0` у всіх slave-портів `MII Status: up` і однаковий Aggregator ID.
- Пропускну здатність перевірено навантажувальним тестом із кількома паралельними потоками.
- Відмовостійкість перевірено вручну: відключення одного кабелю не повинно рвати активні з'єднання.
- Якщо серверу потрібно кілька публічних адрес поверх bond0, IP-аліаси або [додаткові підмережі](https://www.zevshost.net/uk/kb/dopolnitelnye-ipv4-podseti-server/) налаштовують уже на інтерфейсі bond0, а не на eth0/eth1.

Перевірку мережі варто включити в загальний список під час [приймання сервера](https://www.zevshost.net/uk/kb/priyomka-vydelennogo-servera/) — лінк, що відмовив, або неправильно налаштований LACP простіше знайти в першу годину експлуатації, ніж через місяць під навантаженням.

---

Джерело: https://www.zevshost.net/uk/kb/bonding-lacp-setevye-porty/