Обсудить проект
10 октября, 2026 · Linux

Bonding, bridge и VLAN в Netplan и NetworkManager

Один сетевой интерфейс на сервере это одна точка отказа. Стоит выдернуться кабелю или умереть порту коммутатора, и сервис недоступен. К тому же одна физическая сеть почти никогда не соответствует реальным задачам: нужно отделить управление от пользовательского трафика, дать виртуальным машинам прямой доступ в сеть, разнести хранилище и клиентов. Для этого в Linux есть три кирпича: bonding (объединение интерфейсов), bridge (программный коммутатор) и VLAN (разделение сети на логические сегменты по тегам 802.1Q).

Разберём, как собрать всё это на двух популярных способах настройки: Netplan (стандарт Ubuntu Server) и NetworkManager (RHEL, Rocky, Fedora и десктопы). Пример сквозной: хост srv-linux01 в домене itpages.lab.local имеет два сетевых порта eth0 и eth1, подключённых к разным коммутаторам. Нужно собрать из них отказоустойчивую связку, поверх неё сделать VLAN 10 (сервера, сеть 192.168.10.0/24) и VLAN 20 (гости виртуальных машин), а VLAN 20 завести в мост для VM.

Шаг 1. Выбираем режим bonding

Режим определяет поведение связки, и неверный выбор приведёт либо к отсутствию эффекта, либо к потерям связи. Главные варианты:

  • active-backup (mode 1): работает один интерфейс, второй ждёт. Не требует никакой настройки коммутатора, подходит всегда. Даёт отказоустойчивость, но не суммирует скорость.
  • 802.3ad, LACP (mode 4): динамическое агрегирование. Требует настроенной группы LACP на коммутаторе (или паре коммутаторов в стеке или MLAG). Даёт и отказоустойчивость, и распределение нагрузки, но один поток всё равно идёт по одному линку.
  • balance-alb (mode 6): балансировка без участия коммутатора, работает на основе ARP. Рабочий вариант, когда LACP недоступен, но капризнее остальных.

Если порты уходят в разные независимые коммутаторы, берём active-backup. Если в стек или MLAG-пару и админ сети согласен, берём LACP. Мы покажем оба варианта.

Перед настройкой проверь, что модуль ядра в наличии и физические имена интерфейсов именно такие:

modinfo bonding | head -3
ip -br link
ethtool -i eth0 | head -3

Шаг 2. Netplan: bond, VLAN и bridge

В Ubuntu всё описывается одним YAML-файлом в /etc/netplan/. Структура иерархическая: физические интерфейсы входят в bond, VLAN строятся поверх bond, а bridge собирается поверх VLAN.

# /etc/netplan/01-bond-vlan.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0: {}
    eth1: {}
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4
  vlans:
    bond0.10:
      id: 10
      link: bond0
      addresses: [192.168.10.10/24]
      routes:
        - to: default
          via: 192.168.10.1
      nameservers:
        search: [itpages.lab.local]
        addresses: [192.168.10.2]
    bond0.20:
      id: 20
      link: bond0
  bridges:
    br-vm:
      interfaces: [bond0.20]
      parameters:
        stp: false
        forward-delay: 0

Разберём ключевые моменты. Пустые записи eth0: {} нужны, чтобы Netplan знал об интерфейсах, но не навешивал на них адреса: адрес живёт на VLAN-интерфейсе. Параметр mii-monitor-interval: 100 означает проверку состояния линка каждые 100 мс, без него bond может долго не замечать обрыв. Политика layer3+4 учитывает IP и порты, поэтому разные соединения распределяются по линкам лучше, чем при хешировании только по MAC.

Для варианта active-backup замени блок parameters:

      parameters:
        mode: active-backup
        primary: eth0
        mii-monitor-interval: 100
        fail-over-mac-policy: active

Применять конфигурацию удалённо нужно осторожно. Команда netplan try применяет настройки и откатывает их автоматически, если ты не подтвердил в течение таймаута. Это спасает от потери доступа по SSH:

sudo netplan generate
sudo netplan try --timeout 60
sudo netplan apply

Шаг 3. NetworkManager: то же самое через nmcli

В дистрибутивах семейства RHEL используется NetworkManager, и работать с ним удобно через nmcli. Логика та же: сначала bond, затем ведомые интерфейсы, потом VLAN, затем bridge.

sudo nmcli con add type bond con-name bond0 ifname bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4" \
  ipv4.method disabled ipv6.method disabled

sudo nmcli con add type ethernet con-name bond0-eth0 ifname eth0 master bond0
sudo nmcli con add type ethernet con-name bond0-eth1 ifname eth1 master bond0

sudo nmcli con add type vlan con-name bond0.10 ifname bond0.10 dev bond0 id 10 \
  ipv4.method manual ipv4.addresses 192.168.10.10/24 \
  ipv4.gateway 192.168.10.1 ipv4.dns 192.168.10.2 \
  ipv4.dns-search itpages.lab.local

sudo nmcli con add type vlan con-name bond0.20 ifname bond0.20 dev bond0 id 20 \
  master br-vm slave-type bridge

sudo nmcli con add type bridge con-name br-vm ifname br-vm \
  bridge.stp no ipv4.method disabled ipv6.method disabled

sudo nmcli con up bond0

Обрати внимание на параметр master у ведомых соединений и на то, что у bond отключены IPv4 и IPv6: адресов на самой связке нет, они на VLAN. Если у тебя была ранее настроена старая конфигурация на eth0, сначала убери её командой nmcli con delete, иначе интерфейс будет захвачен прежним профилем и в bond не попадёт.

Для active-backup меняется только строка опций: "mode=active-backup,miimon=100,primary=eth0".

Шаг 4. Проверяем работу связки

Настроить недостаточно, нужно убедиться, что всё действительно работает как задумано, и проверить сценарий отказа.

cat /proc/net/bonding/bond0
ip -d link show bond0.10
bridge link show
bridge vlan show
ip -br addr show

В файле /proc/net/bonding/bond0 смотри на режим, состояние MII каждого ведомого интерфейса и, для LACP, на блок «802.3ad info»: там должен быть одинаковый Aggregator ID у обоих портов. Если у портов разные ID, коммутатор не договорился о группе, и чаще всего причина в том, что на его стороне не включён LACP или порты в разных группах.

Теперь проверка отказа. Из соседней консоли запусти непрерывный ping с другого хоста на 192.168.10.10 и сними один линк:

ping -i 0.2 192.168.10.10
sudo ip link set eth0 down
# смотрим потери в ping, затем возвращаем
sudo ip link set eth0 up
grep -E 'Slave Interface|MII Status|Currently Active' /proc/net/bonding/bond0

Нормально, когда теряется один-два пакета. Если связь пропадает на десятки секунд, значит не настроен мониторинг линка или коммутатор ждёт долгую сходимость. Ту же проверку повтори в обратную сторону, сняв eth1, и обязательно проверь физическое отключение кабеля, а не только программное, потому что поведение иногда различается.

Шаг 5. VLAN и bridge для виртуальных машин

Мост br-vm теперь привязан к VLAN 20, и всё, что подключено к нему, окажется в этом сегменте. Для KVM достаточно указать в описании виртуальной машины сеть типа bridge:

virt-install --name vm-test01 --memory 2048 --vcpus 2 \
  --disk size=20 --os-variant ubuntu24.04 \
  --network bridge=br-vm,model=virtio \
  --cdrom /srv/iso/ubuntu-24.04-live-server-amd64.iso

Если нужно пропускать несколько VLAN через один мост, включай VLAN-фильтрацию. В Netplan это делается на уровне параметров моста, а в NetworkManager командой:

sudo nmcli con modify br-vm bridge.vlan-filtering yes
sudo bridge vlan add dev vnet0 vid 20 pvid untagged

Не забудь, что на порту коммутатора, куда подключены eth0 и eth1, должен быть настроен trunk с разрешёнными VLAN 10 и 20. Типичная картина: на сервере всё настроено идеально, а в сети тишина, потому что порт коммутатора находится в режиме access. Убедись, что с сетевой стороны настроен trunk, и согласуй номера VLAN заранее. Ещё один нюанс: если используется native VLAN, нужно договориться, какой именно, иначе нетегированный трафик окажется не там, где ожидается.

Отдельно упомянем MTU. Если на коммутаторах включены jumbo frames, задавай одинаковый MTU на bond, на VLAN-интерфейсах и на мосту, причём на bond он должен быть не меньше, чем на вложенных интерфейсах. В Netplan это ключ mtu: 9000, в NetworkManager параметр 802-3-ethernet.mtu. Помни, что весь путь должен поддерживать выбранное значение, иначе получишь тихие потери больших пакетов.

Шаг 6. Откат, сохранение и документирование

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

sudo cp -a /etc/netplan /root/netplan.bak-$(date +%F)
ip -br addr > /root/net-before.txt
ip route > /root/route-before.txt
nmcli -t con show > /root/nm-before.txt 2>/dev/null

После изменения сравни результат с сохранённым состоянием: маршруты по умолчанию, DNS и адреса должны совпадать с ожидаемыми, а лишнего не появиться. Для NetworkManager полезно знать, что профили живут в /etc/NetworkManager/system-connections/ и могут быть сохранены и перенесены на другой хост как обычные файлы с правами 600.

Если после применения связь пропала и откат не сработал, действуй по порядку. Подключись через консоль гипервизора или IPMI, затем выполни sudo netplan apply со старым файлом или команду nmcli con up для прежнего профиля. Для проверки того, что именно видит ядро, достаточно трёх команд:

ip -d link show bond0
journalctl -u systemd-networkd -n 50 --no-pager
journalctl -u NetworkManager -n 50 --no-pager

Ещё один совет по эксплуатации: фиксируй схему подключения письменно. Какой порт сервера идёт в какой порт какого коммутатора, какие VLAN разрешены, какой режим bond выбран и почему. Через полгода, когда придёт время менять коммутатор, эта запись сэкономит часы. Хорошая практика, особенно для связки с LACP, хранить такую схему рядом с конфигурацией, в том же репозитории. Для хостов с несколькими сетевыми картами также зафиксируй устойчивые имена интерфейсов, чтобы после замены оборудования eth0 и eth1 не поменялись местами и связка не собралась на неверных портах.

Напоследок несколько замечаний по производительности. Режим LACP распределяет по линкам потоки, а не пакеты, поэтому один скачивающий клиент никогда не получит больше скорости одного физического порта. Агрегированная ёмкость проявляется только при множестве параллельных соединений. Если нужен именно быстрый одиночный поток, ставь сетевую карту побыстрее, а не добавляй линки. Для проверки распределения нагрузки запусти несколько параллельных тестов iperf3 с разных клиентов и посмотри счётчики: ip -s link show eth0 и ip -s link show eth1 должны расти примерно поровну.

iperf3 -s                       # на srv-linux01
iperf3 -c 192.168.10.10 -P 8    # с клиента, 8 потоков
watch -n1 'ip -s link show eth0 | grep -A1 RX; ip -s link show eth1 | grep -A1 RX'

Если весь трафик идёт по одному линку, проверь политику хеширования на обеих сторонах: коммутатор тоже выбирает порт для обратного направления по собственному алгоритму, и его нужно настроить на учёт IP и портов, а не только MAC-адресов.

Частые ошибки и как их избежать

  • LACP на сервере без LACP на коммутаторе. Сервер настроен на 802.3ad, а на порту обычный access. Связка собирается частично, один линк работает, второй висит, а при отказе первого связь пропадает. Заранее согласуй с сетевым администратором режим и проверяй Aggregator ID в /proc/net/bonding. Если коммутатор не умеет LACP, используй active-backup.
  • Применение настроек по SSH без страховки. Одна опечатка в адресе или шлюзе, и ты отрезан от сервера. Используй netplan try, держи открытой вторую сессию, а в NetworkManager заранее готовь консольный доступ (IPMI, KVM или гипервизорную консоль). Перед правкой делай копию конфигурации.
  • Адрес на физическом интерфейсе, вошедшем в bond или bridge. Если оставить IP на eth0 или на VLAN, который стал портом моста, получишь дублирование и странные потери. Адрес должен жить только на верхнем уровне: на VLAN без моста или на самом мосту. Проверяй результат через ip -br addr: адреса должны быть ровно там, где задуманы.

Что дальше

Администрирование Linux — это набор связанных навыков, вот соседние темы серии:

Автор — Команда IT-Pages