Bonding на MikroTik — агрегация каналов и LACP

RouterOS 7.xInterfaces10 мин330 мар. 2026 г.

Bonding (агрегация каналов) позволяет объединить несколько физических Ethernet-интерфейсов в один логический, увеличивая пропускную способность и/или обеспечивая отказоустойчивость. В корпоративных сетях bonding чаще всего используется для подключения серверов, NAS-хранилищ и uplink-соединений между коммутаторами. RouterOS поддерживает все стандартные режимы агрегации, включая IEEE 802.3ad (LACP), что делает MikroTik полноценным участником в сетях с managed-коммутаторами Cisco, HP, Juniper и другими.

Описание

Зачем нужен Bonding

Типичные сценарии применения bonding на MikroTik:

Сценарий	Описание
Увеличение bandwidth	Два порта GE объединяются в 2 Gbps канал к серверу
Отказоустойчивость	При выходе из строя одного кабеля/порта трафик переключается на второй
Uplink между коммутаторами	Агрегация нескольких линков между MikroTik и managed switch
Подключение гипервизора	Сервер ESXi/Proxmox с двумя NIC подключается с LACP

Bonding работает на уровне L2 — объединённый интерфейс ведёт себя как один Ethernet-порт с одним MAC-адресом. Его можно добавить в Bridge, назначить IP-адрес, использовать в VLAN-конфигурациях.

Режимы Bonding

RouterOS поддерживает несколько режимов агрегации. Выбор режима зависит от задачи и возможностей оборудования на другом конце:

Режим	Описание	Требует настройку на коммутаторе	Балансировка нагрузки
`802.3ad` (LACP)	Стандартный протокол агрегации IEEE 802.3ad	Да, LACP на коммутаторе	Да, по выбранному алгоритму
`balance-rr`	Round-robin — пакеты распределяются по интерфейсам поочерёдно	Нет	Да, но может нарушать порядок пакетов
`active-backup`	Один интерфейс активен, остальные в резерве	Нет	Нет, только failover
`balance-xor`	Распределение по хешу (src MAC XOR dst MAC)	Да	Да, стабильное распределение
`broadcast`	Пакеты отправляются во все интерфейсы одновременно	Нет	Нет
`balance-tlb`	Adaptive transmit load balancing	Нет	Только исходящий трафик
`balance-alb`	Adaptive load balancing (tx + rx)	Нет	Да, без поддержки на коммутаторе

Рекомендации по выбору:

802.3ad (LACP) — лучший выбор, если на другом конце managed-коммутатор с поддержкой LACP. Обеспечивает корректную балансировку и автоматическое согласование параметров.
active-backup — если нужен только failover без увеличения bandwidth, или коммутатор не поддерживает LACP.
balance-alb — если нужна балансировка без настройки коммутатора (unmanaged switch). Работает через ARP manipulation.
balance-rr — максимальная утилизация канала, но может вызвать проблемы с reordering пакетов. Подходит для bulk-трафика.

Алгоритмы хеширования (transmit-hash-policy)

Для режимов 802.3ad и balance-xor важен алгоритм, определяющий распределение трафика по slave-интерфейсам:

Алгоритм	Описание	Когда использовать
`layer-2`	Хеш по src/dst MAC	По умолчанию. Подходит для большинства сценариев
`layer-2-and-3`	Хеш по MAC + IP	Лучше распределяет при множестве IP-хостов
`layer-3-and-4`	Хеш по IP + TCP/UDP port	Лучшее распределение для серверных нагрузок
`encap-layer-2-and-3`	Для инкапсулированного трафика	Для туннелей (GRE, VXLAN)
`encap-layer-3-and-4`	Для инкапсулированного трафика с портами	Для туннелей с множеством потоков

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

Настройка

Схема: 2x GE от MikroTik к серверу через managed switch

code
[MikroTik RB5009]              [Managed Switch]              [Сервер]
  ether3 ─── LACP bond ──────── Port 1 ─┐
                                          ├── LAG ─── eth0+eth1 (bond)
  ether4 ─── LACP bond ──────── Port 2 ─┘

Цель: получить агрегированный 2 Gbps канал от MikroTik к серверу, с автоматическим failover при потере одного линка.

Шаг 1: Создание Bonding-интерфейса (802.3ad LACP)

[admin@MikroTik] >
/interface/bonding add \
  name=bond-server \
  slaves=ether3,ether4 \
  mode=802.3ad \
  transmit-hash-policy=layer-2-and-3 \
  lacp-rate=fast \
  link-monitoring=mii \
  mii-interval=100ms \
  comment="LACP bond to server via switch"

Параметры:

slaves=ether3,ether4 — физические интерфейсы, входящие в bond
mode=802.3ad — стандартный LACP
transmit-hash-policy=layer-2-and-3 — балансировка по MAC и IP
lacp-rate=fast — обмен LACP PDU каждую секунду (по умолчанию slow — раз в 30 секунд). Fast обеспечивает более быстрое обнаружение отказа.
link-monitoring=mii — мониторинг состояния линка через MII (Media Independent Interface)
mii-interval=100ms — проверка состояния линка каждые 100 мс

Шаг 2: Назначение IP или добавление в Bridge

Вариант А — назначить IP-адрес напрямую на bonding-интерфейс:

[admin@MikroTik] >
/ip/address add address=10.0.0.1/24 interface=bond-server

Вариант Б — добавить bond в существующий Bridge (чаще используется):

[admin@MikroTik] >
/interface/bridge/port add bridge=bridge-LAN interface=bond-server

Важно: при добавлении bond в Bridge, slave-интерфейсы (ether3, ether4) не должны быть отдельно добавлены в Bridge. Только bond-интерфейс добавляется как port.

Шаг 3: Настройка LACP на managed switch

На стороне коммутатора необходимо создать LAG (Link Aggregation Group) из соответствующих портов. Пример для разных вендоров:

Cisco IOS:

code
interface range GigabitEthernet0/1-2
  channel-group 1 mode active

interface Port-channel1
  switchport mode access
  switchport access vlan 10

HP ProCurve:

code
trunk 1-2 trk1 lacp

Пункт контроля: LACP mode на коммутаторе должен быть active или passive. Если MikroTik настроен в 802.3ad, на коммутаторе также должен быть LACP (а не static LAG).

Настройка режима Active-Backup (без LACP)

Если коммутатор не поддерживает LACP, или нужен простой failover:

[admin@MikroTik] >
/interface/bonding add \
  name=bond-failover \
  slaves=ether3,ether4 \
  mode=active-backup \
  primary=ether3 \
  link-monitoring=mii \
  mii-interval=100ms \
  comment="Failover bond - no LACP needed"

В режиме active-backup:

primary=ether3 — ether3 будет основным, ether4 активируется только при падении ether3
Настройка на коммутаторе не требуется — порты работают как обычные access-порты
Bandwidth не суммируется — используется только один линк в каждый момент времени

Настройка Balance-ALB (без настройки коммутатора)

Режим balance-alb обеспечивает балансировку нагрузки без какой-либо поддержки со стороны коммутатора:

[admin@MikroTik] >
/interface/bonding add \
  name=bond-alb \
  slaves=ether3,ether4 \
  mode=balance-alb \
  link-monitoring=mii \
  mii-interval=100ms \
  comment="ALB bond - no switch config needed"

Balance-alb работает за счёт манипуляции ARP-ответами: bond подставляет MAC-адреса разных slave-интерфейсов в ARP-reply, заставляя клиентов отправлять трафик на разные порты. Исходящий трафик балансируется на основании нагрузки каждого slave.

Ограничение: balance-alb не работает корректно, если bond находится за VLAN-aware bridge или если на коммутаторе включён port-security / MAC-limit.

Мониторинг линка: MII vs ARP

RouterOS предлагает два метода мониторинга состояния slave-интерфейсов:

MII (Media Independent Interface) — проверяет физическое состояние линка (link up/down):

[admin@MikroTik] >
/interface/bonding set bond-server \
  link-monitoring=mii \
  mii-interval=100ms

Быстрое обнаружение обрыва кабеля или падения порта
Не обнаруживает проблемы «выше» L1 (например, коммутатор повис, но линк горит)

ARP-мониторинг — отправляет ARP-запросы на указанный IP и ожидает ответ:

[admin@MikroTik] >
/interface/bonding set bond-server \
  link-monitoring=arp \
  arp-interval=1s \
  arp-ip-targets=10.0.0.254

arp-ip-targets — IP-адрес, который должен отвечать на ARP (обычно gateway или коммутатор)
arp-interval — интервал отправки ARP-запросов
Обнаруживает проблемы на L2/L3 уровне, а не только физический обрыв
Медленнее реагирует, чем MII

Рекомендация: используйте MII для стандартных сценариев. ARP-мониторинг полезен, когда оборудование на другом конце может «зависнуть» с поднятым линком.

Проверка

Проверка состояния Bonding

Основная команда для проверки bonding:

[admin@MikroTik] >
/interface/bonding/monitor bond-server

Ожидаемый вывод для рабочего LACP:

code
                  mode: 802.3ad
          active-ports: ether3,ether4
        inactive-ports:
          lacp-system-id: CC:2D:E0:12:34:56
    lacp-system-priority: 65535
  lacp-partner-system-id: AA:BB:CC:DD:EE:FF

Все slave-интерфейсы должны быть в active-ports. Если интерфейс попал в inactive-ports — есть проблема с LACP-согласованием или физическим линком.

Проверка LACP-статуса каждого slave

[admin@MikroTik] >
/interface/bonding/monitor bond-server once

Для детальной диагностики можно посмотреть LACP PDU:

[admin@MikroTik] >
/interface/ethernet/monitor ether3,ether4 once

Проверьте что link speed и status одинаковы на обоих интерфейсах.

Проверка пропускной способности

Для тестирования реальной агрегированной скорости используйте bandwidth-test с сервера:

[admin@MikroTik] >
/tool/bandwidth-test address=10.0.0.2 protocol=tcp duration=10s direction=transmit

Важно: один TCP-поток не покажет 2 Gbps — он пройдёт через один slave (потому что hash одинаковый). Для реальной утилизации нужно несколько параллельных потоков с разными IP/портами.

Проверка распределения трафика

Посмотреть трафик на каждом slave-интерфейсе:

[admin@MikroTik] >
/interface/print stats where name~"ether[34]"

При корректной работе LACP и нескольких потоках трафик должен распределяться приблизительно равномерно между ether3 и ether4.

Мониторинг через SNMP или Grafana

Bonding-интерфейс виден как обычный interface в SNMP. Его можно мониторить через Zabbix, Grafana+Prometheus или The Dude. Обращайте внимание на:

Количество active-ports (алерт если < 2)
Суммарный трафик на bond vs трафик на каждом slave
LACP partner system-id (изменение может означать переключение на коммутаторе)

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

1. Коммутатор не поддерживает LACP

Симптом: bond создан в режиме 802.3ad, но в мониторинге один или оба порта показаны как inactive.

Причина: на коммутаторе не настроен LAG/LACP, или используется unmanaged switch.

Решение: убедитесь, что на коммутаторе создан LAG с LACP mode active/passive. Если коммутатор unmanaged — используйте active-backup или balance-alb вместо 802.3ad.

[admin@MikroTik] >
# Переключение на active-backup если LACP невозможен
/interface/bonding set bond-server mode=active-backup primary=ether3

2. Разная скорость slave-интерфейсов

Симптом: bond работает, но на одном порту скорость 1 Gbps, на другом — 100 Mbps.

Причина: плохой кабель, порт коммутатора ограничен 100 Mbps, или auto-negotiation выбрал неоптимальную скорость.

Решение: проверить скорость на каждом slave:

[admin@MikroTik] >
/interface/ethernet/monitor ether3 once
/interface/ethernet/monitor ether4 once

При необходимости зафиксировать скорость:

[admin@MikroTik] >
/interface/ethernet set ether3 speed=1Gbps
/interface/ethernet set ether4 speed=1Gbps

Важно: в LACP bond все slave должны работать на одинаковой скорости. Разная скорость приведёт к проблемам с агрегацией.

3. Slave-интерфейс находится в Bridge

Симптом: при создании bond-интерфейса появляется ошибка, или bond не работает.

Причина: ether3 или ether4 уже добавлены как порты в Bridge. Один интерфейс не может одновременно быть slave в bond и port в bridge.

Решение: удалить интерфейсы из Bridge перед добавлением в bond:

[admin@MikroTik] >
/interface/bridge/port remove [find interface=ether3]
/interface/bridge/port remove [find interface=ether4]

Затем пересоздать bond и добавить уже bond-интерфейс в Bridge.

4. Один поток не утилизирует весь bond

Симптом: bond из двух GE-портов, но iperf/speedtest показывает только ~940 Mbps.

Причина: это не ошибка, а особенность работы hash-based балансировки. Один TCP-поток (один src IP + dst IP + порт) всегда пойдёт через один slave, потому что хеш для этого потока неизменен.

Решение: bonding увеличивает aggregate bandwidth, а не скорость одного потока. Реальные преимущества видны при:

Нескольких клиентах, обращающихся к серверу одновременно
Нескольких TCP-сессиях с разными портами
Балансировке с использованием layer-3-and-4 hash policy

Можно попробовать balance-rr для распределения одного потока, но это вызовет reordering пакетов и может снизить производительность TCP.

5. ARP-мониторинг ложно переключает slave

Симптом: bond периодически переключает active slave, хотя физические линки в порядке.

Причина: arp-ip-targets указывает на хост, который не всегда отвечает на ARP (например, сервер с arp-filter или firewall, блокирующий ARP).

Решение: в качестве ARP target используйте надёжный хост — gateway коммутатора или IP-адрес самого коммутатора. Или переключитесь на MII-мониторинг:

[admin@MikroTik] >
/interface/bonding set bond-server link-monitoring=mii mii-interval=100ms

6. LACP не согласовывается: lacp-rate mismatch

Симптом: порты в inactive, в логе коммутатора ошибки LACP timeout.

Причина: MikroTik настроен с lacp-rate=fast, а коммутатор поддерживает только slow (или наоборот).

Решение: привести lacp-rate к единому значению на обоих сторонах:

[admin@MikroTik] >
/interface/bonding set bond-server lacp-rate=slow

Slow (30 секунд) — более совместимый вариант, подходит для большинства коммутаторов. Fast (1 секунда) рекомендуется только если оба конца его поддерживают и нужно быстрое обнаружение отказа.

7. Bonding и Hardware Offloading

При добавлении bond-интерфейса в Bridge, hardware offloading для slave-портов отключается. Весь трафик через bond проходит через CPU, что может стать узким местом на младших моделях (hAP lite, hEX lite).

Проверить нагрузку CPU:

[admin@MikroTik] >
/system/resource/print

Если CPU-нагрузка высока, а трафик через bond значительный, рассмотрите использование более мощного устройства (RB5009, CCR) или уменьшение объёма трафика, проходящего через bond.