Мережі в Proxmox та ESXi: транкування VLAN, мости/vSwitchи, bonding/LACP — пояснення

November 14, 2025 • February 3, 2026 • Читання: 7 хв • Views: 8

Було корисно?

Якщо ви колись мігрували кластер і бачили, як «проста мережа» перетворюється на чотиригодинну відмову, ви вже знаєте правду:
мережі гіпервізорів — це місце, де припущення гинуть. VLANи поводяться як слід. Транки поводяться як слід. До того дня, поки
не перестануть — тому що пристрій робить саме те, що ви йому наказали, а не те, що ви мали на увазі.

Це практична карта відповідностей між мережами Proxmox і ESXi: як насправді реалізується транкування VLAN на Linux-місті проти vSwitch,
як працює bonding/LACP (і як він відмовляє), і що перевірити, коли пакети зникають у порожнечу.

1) Ментальна модель: мости проти vSwitchів

Мережі ESXi — це спеціально створений стек віртуального комутатора. Ви створюєте vSwitchі (стандартні або розподілені), визначаєте портгрупи,
підключаєте vmnics (uplinks) і отримуєте застосування політик у системі з керуванням у GUI та послідовними абстракціями.

Мережі Proxmox — це Linux-мережі з GUI. Під капотом ви використовуєте Linux-місти (часто з іменем vmbr0),
VLAN-підінтерфейси та Linux-bonding. «Комутатор» — це ядро. Перевага в тому, що ви можете відлагоджувати його як будь-який Linux-хост
стандартними інструментами. Недолік — ви також можете самі себе підстрелити тими ж інструментами.

Що що відображає

ESXi vSwitch / vDS ≈ Linux-міст (Proxmox vmbrX)
ESXi uplinks (vmnicX) ≈ Linux NIC (eno1, ens3f0 тощо) або bond (bond0)
ESXi Port Group ≈ VLAN на порті мосту (VLAN-aware міст + тег VM) або окремий міст/VLAN-підінтерфейс
ESXi VLAN ID 4095 (гість-транк) ≈ Proxmox NIC без VLAN-тега + гост сам тегує

Велика концептуальна різниця: ESXi схильний переносити ідентичність VLAN у портгрупи, тоді як Proxmox схильний зберігати її в конфігурації NIC
ВМ, коли використовується VLAN-aware міст. Обидва підходи можливі з обох сторін. Але люди звикають до звичок, і міграції ламаються на межах між ними.

Цитата надійності, яку варто вишити на своїх рунабуках

«Сподівання — це не стратегія.» — парафразована ідея, яку часто цитують в операціях і в колах reliability.
Ставтеся до конфігурацій VLAN і LACP як до коду: перевіряйте, тестуйте й майте відкат.

2) Транкування VLAN: Proxmox проти ESXi простими словами

VLAN транк — це просто «переносити кілька VLAN по одному фізичному лінку». Конфлікти починаються, коли питають: «Де саме відбувається тегування?»

Транкування VLAN в ESXi

В ESXi транкування здебільшого виражається через портгрупи:

VLAN ID = N: ESXi тегує кадри з VLAN N, що виходять з цієї портгрупи, і приймає VLAN N із зовні.
VLAN ID = 0: поведінка priority-tagging; рідко використовується в типовій серверній віртуалізації.
VLAN ID = 4095: спеціальний випадок, що означає «транк до гостя». ESXi пропускає теги VLAN, і VM займається тегуванням.

Коли ви підключаєте vmnic uplink до vSwitch або vDS, ви фактично говорите: «Цей uplink підключено до порту комутатора, який налаштований правильно
для того VLAN-поведінки, яку очікують ці портгрупи». ESXi не налаштовує ваш фізичний комутатор, а фізичний комутатор не читає ваші думки.
Ось чому з’являються інциденти.

Транкування VLAN в Proxmox

У Proxmox найпоширеніший «сучасний» патерн такий:

Зробіть vmbr0 VLAN-aware мостом.
Підключіть ваш trunk uplink (фізичний NIC або bond) як порт мосту.
Для кожного VM NIC вкажіть VLAN-тег у апаратній конфігурації VM.

Це концептуально схоже на портгрупи ESXi з VLAN ID, але Proxmox ставить тег на NIC VM замість об’єкту портгрупи.
Операційно це працює — поки вам не доведеться аудитувати 200 VM, щоб знайти «хто на VLAN 132?», і ви пропустите один, бо він
налаштований інакше у якомусь винятковому випадку з 2019 року.

Альтернативний підхід у Proxmox: створити VLAN-підінтерфейси на хості (наприклад, bond0.100) і побудувати окремий міст для кожного VLAN (наприклад, vmbr100).
Це більш багатослівно, але й жорстко прозоро. Прозорість — це функція продуктивності, коли тікає час на відновлення.

Визначення trunk: не плутайте «дозволені VLAN» з «native VLAN»

Фізичні trunk-и звично мають:

Список дозволених VLAN: які теги VLAN дозволені через trunk.
Native VLAN (або untagged VLAN): що відбувається з нетегованими кадрами (їх маплять у певний VLAN).

Якщо ваш uplink гіпервізора надсилає нетеговані кадри (менеджмент, кластер, сховище тощо) і ви припускаєте «нетеговане = VLAN 1»,
а комутатор використовує native VLAN 20, ви отримаєте підключення — але не туди, куди очікували. Так інциденти набувають наслідків для безпеки.

Жарт №1: VLANи як робочі місця в офісі — всі погоджуються, що вони потрібні, але ніхто не погоджується, хто де сидить.

3) ESXi портгрупи проти VLAN-aware мостів Proxmox

Портгрупа ESXi — це об’єкт політики: VLAN ID, налаштування безпеки, shaping трафіку, правила комбінування NIC, і в світі vDS навіть
такі речі, як NetFlow і порт-мірування. Це чиста абстракція для середовищ з багатьма користувачами й контролем змін.

Модель VLAN-aware мостів Proxmox ближча до «комутації в ядрі»: міст бачить теги і пересилає на основі MAC+VLAN.
TAP-інтерфейс VM отримує налаштування VLAN, а Linux займається тегуванням/зняттям тегів.

Що краще обирати

Якщо у вас мале або середнє середовище, VLAN-aware мости — найпростіший і найменш крихкий підхід у Proxmox.
Один міст, один trunk uplink, теги на VM NIC. Це масштабується операційно, поки не з’явиться потреба в політиках на рівні мережі.

Якщо вам потрібний чіткий розподіл обов’язків (netops визначає мережі, команда віртуалізації підключає VM), підхід ESXi з портгрупами зазвичай
краще вписується в корпоративну реальність. У Proxmox ви теж можете добитися поділу обов’язків — просто прийміть, що будете будувати це через
конвенції, автоматизацію й рев’ю, а не через магічні об’єкти.

Гостьове транкування VLAN (гість робить тегування)

ESXi робить це явним через VLAN 4095. Proxmox може зробити те саме, якщо не встановлювати VLAN-тег на NIC VM і забезпечити, щоб міст/uplink
пропускав теговані кадри. Тоді гість створює 802.1Q підінтерфейси всередині себе.

Це корисно для віртуальних маршрутизаторів, фаєрволів або аплайансів, які очікують trunk-лінк. Це також найшвидший шлях створити rabbit hole для
діагностики, де ніхто не знає, де відбувається тегування — в гості, у гіпервізорі чи на фізичному комутаторі. Оберіть одне місце і задокументуйте.

4) Bonding і LACP: що працює, що кусає

Ви об’єднуєте NIC, щоб отримати відмовостійкість і/або збільшення пропускної здатності. Є два широкі класи:

Статичні/team режими (без переговорів зі сторони комутатора): active-backup, balance-xor (залежно від реалізації) тощо.
LACP (802.3ad): агрегування з перемовинами зі сторони комутатора, із політиками хешування, що вирішують, який потік іде по якому лінку.

Bonding у Proxmox

У Proxmox зазвичай використовують Linux-bonding (bond0) з режимами, як-от:

active-backup: один активний лінк, інший у резерві. Нудно. Надійно. Мій за замовчуванням для мережі менеджменту.
802.3ad (LACP): всі лінки активні, краща утилізація, але потребує правильної конфігурації комутатора й узгодженого хешування.
balance-xor: статичне агрегування; може працювати, але його легше неправильно налаштувати на різних комутаторах.

NIC teaming і LACP в ESXi

NIC teaming у стандартному vSwitch ESXi — це не LACP. Це «teaming» з різними політиками балансування навантаження. Для справжнього LACP
зазвичай потрібен vDS (distributed switch), залежно від версії/ліцензії, і тоді ви визначаєте LACP LAG і прикріплюєте uplinks.

Переклад: якщо ви звикли «просто ввімкнути LACP на хості», ESXi може змусити вас перейти в vDS. Якщо ви звикли «просто командувати NICs»,
Proxmox може спонукати до статичних режимів, які працюють, поки заміна комутатора не змінить поведінку.

Хешування — там, куди йдуть мрії помирати

LACP не дає одному TCP-потоку подвійної пропускної здатності. Він розподіляє потоки по лінках на основі хешу (MAC/IP/port комбінації).
Якщо ви хочете «одна VM отримує 20 Гбіт», вам, ймовірно, потрібні інші рішення (кілька потоків, SMB multichannel, NVMe/TCP кілька сесій
або просто більший канал).

Також: сховищний трафік (iSCSI, NFS) і трафік міграцій можуть стати дуже чутливими до reordering і мікроспроб, якщо ви «оптимізуєте»
без вимірювань. LACP — не безкоштовний обід. Це погоджена угода сперечатися з фізикою.

Жарт №2: LACP — це стосунки: якщо одна сторона думає, що ви «active-backup», а інша — що ви «все активне», хтось почне глушити пакети.

5) MTU, offloads і «податок» на jumbo frames

Невідповідності MTU нудні й катастрофічні. ESXi схильний прокидати MTU через vSwitchи/vDS і VMkernel інтерфейси.
Proxmox прокидає його через Linux-інтерфейси, bondи, VLAN-підінтерфейси і мости. Ви можете зробити все правильно — або «майже правильно»,
що і породжує сховище, яке працює, поки ви не вмикаєте реплікацію.

Якщо ви використовуєте jumbo frames (9000 MTU), робіть це наскрізь: фізичні порти комутатора, uplinks, bond, міст, VLAN-інтерфейси і гостеві NIC,
де потрібно. Якщо не можете гарантувати наскрізь, не робіть напівзаходів. Тримайте 1500 і витрачайте час на CPU pinning або архітектуру сховища.

6) Налаштування безпеки vSwitch проти Linux за замовчуванням

Портгрупи ESXi мають класичні перемикачі безпеки: Promiscuous Mode, MAC Address Changes, Forged Transmits. Вони існують, бо віртуальна
комутація — це спільне середовище, і деякі робочі навантаження (IDS, аплаянси) потребують спеціальної поведінки. Багато найгірших «таємничих відмов»
в ESXi були спричинені саме жорсткими налаштуваннями для конкретної VM.

Proxmox/Linux-міст не подає ті самі перемикачі в тому ж вигляді, але існують аналогічні обмеження: ebtables/nftables правила,
фільтрація мосту і поведінка гостя. Якщо ви запускаєте віртуальні фаєрволи, потрібно перевіряти, що гіпервізор пропустить кадри, які ви очікуєте,
включно з VLAN-тегами та MAC-поведінкою.

7) Цікаві факти & історичний контекст (8 швидких тез)

802.1Q VLAN tagging був стандартизований у 1998 році, і ми досі сперечаємося про native VLAN, наче це нове.
Linux-місти були готові для production десятиліттями; вони передували багатьом сучасним UI у стеку віртуалізації.
LACP (802.3ad / 802.1AX) створювали, щоб стандартизувати агрегацію лінків між вендорами; воно стандартизувало й аргументи.
ESXi стандартний vSwitch історично не робив LACP так, як це може робити vDS; люди будували «достатньо хороші» політики teaming.
VLAN 4095 в ESXi — це не «VLAN», це сигнал портгрупі пропустити всі VLAN до гостя.
VXLAN/overlay мережі стали мейнстрімом частково тому, що масштаб VLAN (4094 корисних ID) був реальним обмеженням у великих середовищах.
NIC offloads (TSO/GSO/GRO/LRO) можуть змінювати поведінку пакетів настільки, щоб сплутати захоплення і деякі безпекові апарати.
STP та мости все ще важливі: випадкові петлі можуть швидко «сплавити» мережі, і це стосується і фізичних, і віртуальних комутаторів.

8) Практичні завдання: команди, виводи, рішення (12+)

Ось перевірки, які я справді виконую, коли щось пахне підозріло. Кожне завдання включає: команду, приклад виводу, що це означає, і яке рішення прийняти.

Завдання 1: Визначити фізичні NIC і стан лінку (Proxmox)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:fd:fe:aa:bb:01
eno2             DOWN           3c:fd:fe:aa:bb:02
ens3f0           UP             0c:42:a1:11:22:33
ens3f1           UP             0c:42:a1:11:22:34
bond0            UP             0c:42:a1:11:22:33
vmbr0            UP             0c:42:a1:11:22:33

Значення: Ви відразу бачите, що піднято/опущено і чи існують bond/місти.
Рішення: Якщо член NIC несподівано down — перестаньте звинувачувати VLANи і перевірте кабелі/помилки на портах комутатора перш за все.

Завдання 2: Перевірити режим bond і стан LACP (Proxmox)

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: fast
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
        Aggregator ID: 2
        Number of ports: 2
        Actor Key: 17
        Partner Key: 42
        Partner Mac Address: 00:11:22:33:44:55

Slave Interface: ens3f0
MII Status: up
Actor Churn State: none
Partner Churn State: none

Slave Interface: ens3f1
MII Status: up
Actor Churn State: none
Partner Churn State: none

Значення: Підтверджує 802.3ad, політику хешування і що обидва slave справді агреговані з MAC партнера.
Рішення: Якщо бачите «Number of ports: 1» або стани churn — підозрюйте невідповідність конфігурації LACP на комутаторі або флапінг лінків.

Завдання 3: Підтвердити VLAN-aware міст і членство портів (Proxmox)

cr0x@server:~$ bridge link
2: bond0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
5: tap100i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
6: tap101i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0

Значення: Показує, що приєднано до мосту: uplink і TAP-пристрої VM.
Рішення: Якщо uplink не в мосту, ваш «trunk» — це філософське поняття, а не мережа.

Завдання 4: Переглянути фільтрацію VLAN на Linux-місті (Proxmox)

cr0x@server:~$ bridge vlan show
port              vlan-id  
bond0             1 PVID Egress Untagged
bond0             20
bond0             30
tap100i0          20
tap101i0          30

Значення: Міст фільтрує VLANи; bond0 дозволяє VLANи 20 і 30 і має PVID 1 untagged.
Рішення: Якщо потрібного VLANу немає в списку, або дозволіть його (якщо фільтрація увімкнена), або виправте тегування NIC VM.

Завдання 5: Перевірити IP-адресацію хоста і який інтерфейс її має (Proxmox)

cr0x@server:~$ ip -br addr
eno1             UP             192.0.2.10/24
bond0            UP
vmbr0            UP             198.51.100.10/24
vmbr0.20         UP             10.20.0.10/24

Значення: Показує, чи менеджмент IP на мосту, VLAN-підінтерфейсі або фізичному NIC.
Рішення: Якщо IP хоста на фізичному NIC, який також включено в міст — очікуйте дивної поведінки. Ставте IP на міст (або на VLAN-інтерфейс над мостом), а не на підлеглі порти.

Завдання 6: Перевірити узгодженість MTU на uplink, bond, мосту (Proxmox)

cr0x@server:~$ ip -d link show bond0
3: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 0c:42:a1:11:22:33 brd ff:ff:ff:ff:ff:ff promiscuity 0
    bond mode 802.3ad miimon 100 updelay 0 downdelay 0 lacp_rate 1 xmit_hash_policy 1

Значення: MTU 9000 на bond; потрібно ще перевірити slave NIC, міст і порти комутатора.
Рішення: Якщо MTU відрізняється на будь-якому хопі — або виправте наскрізь, або скиньте до 1500 і припиніть платити податок jumbo frames.

Завдання 7: Швидкий тест досяжності VLAN ping + DF (Proxmox)

cr0x@server:~$ ping -c 2 -M do -s 8972 10.20.0.1
PING 10.20.0.1 (10.20.0.1) 8972(9000) bytes of data.
8972 bytes from 10.20.0.1: icmp_seq=1 ttl=64 time=0.421 ms
8972 bytes from 10.20.0.1: icmp_seq=2 ttl=64 time=0.398 ms

--- 10.20.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Значення: Підтверджує, що jumbo MTU працює до шлюзу в тому VLAN (хоча б для ICMP).
Рішення: Якщо це падає, але звичайний ping працює — у вас проблема фрагментації/blackhole MTU. Виправте MTU або поведінку Path MTU Discovery.

Завдання 8: Подивитися навчання MAC на мосту (Proxmox)

cr0x@server:~$ bridge fdb show br vmbr0 | head
0c:42:a1:11:22:33 dev bond0 master vmbr0 permanent
52:54:00:aa:bb:01 dev tap100i0 master vmbr0 vlan 20
52:54:00:aa:bb:02 dev tap101i0 master vmbr0 vlan 30

Значення: Підтверджує, що міст навчає MAC VM по VLAN і де вони знаходяться.
Рішення: Якщо MAC VM відсутній, хоча VM підключена й генерує трафік — підозрюйте прикріплення NIC VM, правила фаєрвола або що гість на неправильному VLAN.

Завдання 9: Захоплення тегованого трафіку на uplink (Proxmox)

cr0x@server:~$ sudo tcpdump -eni bond0 -c 5 vlan
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:11.123456 0c:42:a1:11:22:33 > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 86: vlan 20, p 0, ethertype IPv4, 10.20.0.10.5353 > 224.0.0.251.5353: UDP, length 44
12:01:11.223456 52:54:00:aa:bb:01 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 10.20.0.1 tell 10.20.0.50, length 28

Значення: Ви бачите теги VLAN на каналі і можете підтвердити ID VLAN.
Рішення: Якщо теги відсутні на trunk, який має їх нести — тегування робиться в іншому місці або зовсім не відбувається.

Завдання 10: ESXi — підтвердити лінк vmnic і інформацію про драйвер (в оболонці ESXi)

cr0x@server:~$ esxcli network nic list
Name    PCI Device    Driver  Link  Speed  Duplex  MAC Address         MTU  Description
vmnic0  0000:3b:00.0  ixgbe   Up    10000  Full    3c:fd:fe:aa:bb:01  9000 Intel Corporation 82599ES
vmnic1  0000:3b:00.1  ixgbe   Up    10000  Full    3c:fd:fe:aa:bb:02  9000 Intel Corporation 82599ES

Значення: Фізичні uplink-и підняті, на очікуваній швидкості/MTU. Це виключає цілу категорію «це мережа» виправдань.
Рішення: Якщо швидкість 1000 замість очікуваних 10000 — зупиніться. Спочатку виправте оптику/кабелі/налаштування порту комутатора.

Завдання 11: ESXi — переглянути vSwitchи і портгрупи

cr0x@server:~$ esxcli network vswitch standard list
vSwitch0
   Name: vSwitch0
   Class: etherswitch
   Num Ports: 128
   Used Ports: 12
   Configured Ports: 128
   MTU: 9000
   Uplinks: vmnic0, vmnic1
   Portgroups: Management Network, VM Network, Storage-20

Значення: Показує MTU, uplinks і які портгрупи є на стандартному vSwitch.
Рішення: Якщо потрібна портгрупа не на тому vSwitch, який ви думали — ви знайшли логічну помилку, не фізичну.

Завдання 12: ESXi — перевірити VLAN ID на портгрупах

cr0x@server:~$ esxcli network vswitch standard portgroup list
Name               Virtual Switch  VLAN ID
Management Network vSwitch0        10
VM Network         vSwitch0        0
Storage-20         vSwitch0        20
Trunk-to-FW        vSwitch0        4095

Значення: Скаже, чи ESXi тегує кадри (VLAN 10/20) або пропускає їх до гостя (4095).
Рішення: Якщо VM, який очікує нетегованого трафіку, сидить на VLAN 20 — вона буде «впізнана», але ізольована. Виправляйте VLAN ID портгрупи, а не VM.

Завдання 13: Proxmox — підтвердити, що файл конфігурації відповідає очікуванням

cr0x@server:~$ sed -n '1,200p' /etc/network/interfaces
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
        bond-slaves ens3f0 ens3f1
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4
        bond-lacp-rate 1

auto vmbr0
iface vmbr0 inet static
        address 198.51.100.10/24
        gateway 198.51.100.1
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

Значення: Підтверджує режим bond, налаштування bridge VLAN-aware і допуск VLAN-діапазону.
Рішення: Якщо bridge-vlan-aware вимкнено, але ви покладаєтесь на теги NIC VM — теги не працюватимуть як очікується. Увімкніть його або змініть дизайн.

Завдання 14: Proxmox — перевірити правила фаєрвола, що заважають L2/L3

cr0x@server:~$ sudo pve-firewall status
Status: enabled/running

Значення: Фаєрвол увімкнено; тепер треба враховувати правила хоста і VM у своїй ментальній моделі.
Рішення: Якщо ви дебагуєте «ARP працює, але TCP ні» — тимчасово ізолювати вплив фаєрвола (у контрольованому вікні) часто швидше, ніж гадати.

9) Швидкий плейбук діагностики

Коли мережа ламається на гіпервізорах, найшвидший шлях — знайти рівень, де реальність розходиться з вашою діаграмою. Перевіряйте в такому порядку.

Перше: фізична істина (лінк, швидкість, помилки)

Чи піднятий лінк NIC? Чи на очікуваній швидкості?
На Proxmox: ip -br link, ethtool eno1 (якщо доступно), лічильники портів комутатора.
На ESXi: esxcli network nic list.

Показник вузького місця: невідповідність швидкості (1G замість 10G), зростання помилок/дропів, флапінг лінків.

Друге: топологія L2 (bonding/LACP, прикріплення мосту/vSwitch)

Чи дійсно uplink прикріплений до мосту/vSwitch, який ви думаєте?
Чи LACP переговорений і стабільний?
Proxmox: cat /proc/net/bonding/bond0, bridge link.
ESXi: uplinks vSwitch, і якщо vDS — підтвердьте членство в LAG.

Показник вузького місця: лише один slave активний в bond, churn або uplink відсутній там, де має бути.

Третє: правильність VLAN (де тегування, дозволені VLANи, native VLAN)

Чи тег VLAN застосовано до правильного об’єкта (NIC VM vs портгрупа vs гість OS)?
Чи фізичний trunk дозволяє цей VLAN?
Proxmox: bridge vlan show, tcpdump -eni bond0 vlan.
ESXi: esxcli network vswitch standard portgroup list.

Показник вузького місця: ARP-запити видимі, але немає відповідей у очікуваному VLAN, або відповіді приходять в іншому VLAN.

Четверте: MTU і blackhole фрагментації

Тестуйте з DF ping на очікуваному MTU.
Перевірте MTU на кожному хопі: фізичний комутатор, uplink NIC, bond, міст/vSwitch, VMkernel (ESXi), гостевий NIC.

Показник вузького місця: малі ping-и працюють, великі падають; сховище гальмує під навантаженням; міграції зависають періодично.

П’яте: політика і фільтрація (фаєрволи, налаштування безпеки, поведінка MAC)

Налаштування безпеки портгруп ESXi блокує forged transmits або MAC changes для аплайансів.
Proxmox фаєрвол/nftables блокує трафік, який ви приймали за L2.

Показник вузького місця: один тип VM не працює (наприклад, фаєрвол VM), тоді як звичайні сервери працюють.

10) Три корпоративні короткі історії

Інцидент через неправильне припущення: «Нетеговане означає VLAN 1»

Середня компанія перенесла частину робочих навантажень з ESXi на Proxmox під час оновлення апаратури. Команда віртуалізації залишила ті самі
фізичні top-of-rack комутатори і повторно використала існуючі trunk-порти. В ESXi більшість портгруп VM були теговані VLANами, але менеджмент
був нетегований на uplink-ах, бо «так завжди було».

На Proxmox вони створили VLAN-aware vmbr0 і поставили management IP прямо на vmbr0 без VLAN-тега.
Хост піднявся, але менеджмент поводився нестабільно: деякі хости були досяжні, інші — ні, і ARP-таблиці виглядали як помішані.

Неправильне припущення: команда вірила, що native VLAN на комутаторі — VLAN 1. Ні. Попередня стандартизація змістила native VLAN на відокремлений «infra» VLAN,
і VLAN 1 був явно обрізаний в деяких місцях. Нетеговані кадри приземлялися в infra VLAN, а не в management VLAN. Тож хости розмовляли — просто в іншому «районі».

Виправлення було не героїчним. Вони тегували management правильно (VLAN-підінтерфейс або тег NIC VM) і зробили trunk явним:
список дозволених VLAN, визначений native VLAN і документація. Звіт по інциденту був короткий і трохи незручний — саме те, що має бути.

Оптимізація, що відкотилася: «Давайте LACP скрізь і MTU 9000»

Інша організація мала ESXi з окремими мережами: management, storage, vMotion. Вони перейшли на Proxmox і вирішили «спростити», згорнувши все в один LACP bond і один VLAN trunk.
Ідея: менше кабелів, менше портів, краща утилізація пропускної здатності.

Вони також ввімкнули jumbo frames наскрізь — або так думали. MTU хостів було 9000, порти комутатора налаштовані, і bond виглядав здоровим.
У лабораторії це працювало. У проді, під час backup-ікон, латентність сховища зросла, і міграції VM періодично падали. Відмови не були тотальними.
Вони були гірші: часткові, непередбачувані і їх легко списати на «мережу».

Причина була двояка. По-перше, один комутатор на шляху мав MTU, застосований до неправильного профілю порту, залишивши один хоп на 1500.
Частина трафіку фрагментувалася, частина губилася в залежності від протоколу і DF. По-друге, політика хешування на Linux-bond була layer3+4,
тоді як на боці комутатора потоки розподілялися інакше для деяких класів трафіку. Під мікронавантаженням один лінк насичувався, інший був майже пустим.

Відкат був прагматичним: лишити LACP для VM/data VLANів, але винести storage на окрему пару NIC з active-backup і виділеним VLAN,
з перевіреним MTU hop-by-hop. Продуктивність стабілізувалась. «Спрощення» було реальним, але воно також позбавило ізоляції і ускладнило діагностику.
Зближення — інструмент, не характер.

Нудна, але правильна практика, що врятувала ситуацію: «Один міст — одне призначення, протестовані конфіги»

Фінансова організація мала змішаний парк: частина ESXi, частина Proxmox для спеціальних навантажень. Їхня мережна команда наполягла на правилі, яке звучало як бюрократія:
кожен гіпервізор повинен мати маленький «лише-менеджмент» дизайн, що тестується незалежно від мереж VM.

На Proxmox це означало виділений management міст, змеплений на виділений VLAN з active-backup bonding, без хитрувань. VM/data VLANи жили на окремому trunk-місті,
часто на іншому bond. Так, це забирало більше портів. Так, це подовжувало схеми кабелювання. Але це дозволило перезавантажувати, оновлювати
і відновлювати хости без залежності від конвергованого LACP trunk, який може поводитися неконсистентно.

Під час оновлення прошивки комутаторів в одному стійці, LACP деградував у спосіб, що не повністю обривав лінки, але викликав churn і ребалансування.
Мережі VM бачили втрати пакетів. Менеджмент залишився чистим. Операційна команда могла достукатися до кожного хоста, евакуювати VM і контролювати зону ураження.

Постмортем не був гламурним. Це було нагадування, що сегментація — стратегія надійності. Коли ламається — хочеться вузького домену відмови. Нудні дизайни дають яскраву доступність.

11) Типові помилки: симптом → корінь → виправлення

1) VM не дістають шлюз в одному VLAN, але інші VLANи працюють

Симптом: Лише VLAN 30 «мертвий»; VLAN 20 працює нормально.
Корінь: VLAN не дозволено на фізичному trunk, або фільтрація VLAN на мосту його не включає.
Виправлення: Переконайтеся, що VLAN у списку дозволених trunk на комутаторі; на Proxmox перевірте bridge-vlan-aware yes і bridge vlan show включає VLAN; на ESXi перевірте VLAN ID портгрупи.

2) Менеджмент втрачається, коли додаєте порт в міст

Симптом: Додаєте NIC в міст; хост зникає з мережі.
Корінь: IP хоста налаштовано на рабському фізичному NIC замість мосту; ARP/MAC переміщення створює плутанину.
Виправлення: Помістіть IP на vmbrX (або на vmbrX.Y VLAN-інтерфейс), а не на підлеглий NIC/bond.

3) LACP bond показуєся, але лише один лінк несе трафік

Симптом: Обидва лінки «up», але використовується лише один.
Корінь: Політика хешування не підходить для патерну трафіку (домен з одним потоком) або невідповідність хешування на комутаторі.
Виправлення: Узгодьте політики хешування; прийміть, що один TCP-потік не буде розподілятися; розгляньте кілька сесій або окремі мережі для важких навантажень.

4) Сховище працює поки навантаження немає, потім таймаути

Симптом: NFS/iSCSI нормально в спокої, падає під backup/реплікацією.
Корінь: MTU mismatch або мікроспроби на конвергованих лінках; відсутній QoS; offloads поводяться погано.
Виправлення: Перевірте MTU з DF ping наскрізь; відокремте storage трафік або впровадьте буферизацію/QoS; ретельно тестуйте зміни offload.

5) Віртуальний фаєрвол/маршрутизатор VM бачить трафік лише в один бік

Симптом: Вхідні пакети видимі, вихідні відсутні (або навпаки).
Корінь: Налаштування безпеки портгрупи ESXi блокує forged transmits/MAC changes; або гостьове транкування налаштовано неправильно.
Виправлення: На ESXi відкоригуйте налаштування безпеки портгрупи для цього аплайансу; на Proxmox переконайтеся, що VLAN-теги передаються/обробляються на правильному рівні і правила фаєрвола не блокують пакети.

6) Випадкові попередження про дубльований IP або ARP flapping

Симптом: Логи показують дублікат IP; підключення коливається.
Корінь: Невідповідність native VLAN призводить до нетегованого трафіку в неправильний VLAN; або випадкова L2 петля.
Виправлення: Робіть native VLAN явним і послідовним; вмикайте STP там, де доречно; перевіряйте порти мосту і налаштування портів комутатора.

12) Чеклісти / покроковий план

Чекліст A: Проєктування VLAN trunking на Proxmox (робіть це, а не на відчуттях)

Вирішіть, де живе тегування VLAN: теги NIC VM (VLAN-aware міст) або VLAN-підінтерфейси на хості (міст на VLAN). Оберіть одне правило за замовчуванням.
Зробіть uplink bond, якщо потрібна відмовостійкість. Обирайте active-backup для менеджменту за замовчуванням; використовуйте LACP тільки коли ви можете валідувати конфігурацію комутаторів і хешування.
Встановіть bridge-vlan-aware yes на trunk-мостах і навмисно визначте дозволені VLANи (bridge-vids).
Визначте поведінку native/untagged: бажано не покладатися на netagged для важливих мереж. Тегуйте менеджмент також, якщо немає суворої причини інакше.
Перевірте MTU наскрізь за допомогою DF ping тестів для кожного VLAN.
Захопіть трафік на uplink за допомогою tcpdump -eni, щоб підтвердити наявність VLAN-тегів.
Задокументуйте: який міст несе які VLANи і чи якась VM є «гість-транком».

Чекліст B: Міграція з ESXi портгруп до Proxmox VLAN-тегів

Експортуйте або перелічіть портгрупи ESXi і їх VLAN ID (включно з 4095 trunk).
Створіть Proxmox trunk мост(и) і підтвердьте VLAN-aware.
Для кожної VM змепте: ESXi портгрупа VLAN ID → VLAN-тег NIC VM у Proxmox.
Для VLAN 4095 VM: переконайтеся, що NIC VM без тегу і гість налаштований на 802.1Q; валідуйте захопленням пакетів.
Перед cutover протестуйте одну VM на кожному VLAN: ARP, ping, jumbo ping (якщо використовується) і перевірку на рівні додатка.
Залиште менеджмент достатньо ізольованим, щоб можна було відкотити без виїзду в дата-центр.

Чекліст C: Розгортання LACP без самонанесення болю

Підтвердіть, що ваші комутатори підтримують LACP у потрібній конфігурації (multi-chassis LAG/MLAG, якщо використовуєте два комутатори).
Встановіть LACP rate (fast/slow) свідомо і узгодьте на обох сторонах.
Узгодьте політику хешування. Якщо не знаєте, що використовує комутатор — дізнайтесь. Не відгадуйте.
Протестуйте варіанти відмов: відключіть один лінк; перезавантажте один комутатор; підтвердьте, що трафік виживає і перебалансовується без флапінгу.
Моніторте дропи й помилки під навантаженням. Якщо не вимірюєте — не можете проголосити успіх.

13) Питання й відповіді

Q1: Чи Linux-міст Proxmox фактично те саме, що ESXi vSwitch?

Функціонально — так: і те, і те пересилає кадри між інтерфейсами VM і uplink-ами. Операційно — ні: ESXi — це appliance-абстракція;
Proxmox — це Linux-мережі з усією силою і гострими кутами, які це передбачає.

Q2: Чи варто використовувати один великий trunk-мост для всього на Proxmox?

Для багатьох середовищ один trunk-мост для VM/data VLANів підходить. Але залишайте менеджмент нудним і відновлюваним.
Якщо можете дозволити — відокреміть менеджмент від великого конвергованого trunk-а.

Q3: Що таке ESXi VLAN 4095 і який його еквівалент у Proxmox?

ESXi VLAN 4095 означає «передавати VLAN-теги гостю» (гість-транк). У Proxmox це зазвичай реалізується шляхом незадання VLAN-тега на NIC VM
і дозволу гостю створювати підінтерфейси 802.1Q — за умови, що міст/uplink пропускають теговані кадри.

Q4: Чи LACP подвоює пропускну здатність для однієї VM?

Не для одного TCP-потоку. LACP розподіляє потоки по лінках на основі хешування. Один великий потік зазвичай тримається на одному лінку.
Кілька потоків можуть використовувати кілька лінків.

Q5: Чи active-backup bonding «марнує» пропускну здатність?

Воно «марнує» потенційну агреговану пропускну здатність, так. Воно також дає простіші режими відмови. Для менеджменту цей компроміс зазвичай коректний.
Для інтенсивного east-west трафіку розгляньте LACP, якщо можете його експлуатувати.

Q6: Чому проблеми з VLAN іноді виглядають як баги DNS або додатків?

Бо часткова підключеність — найгірший сценарій. ARP може працювати, малі пакети можуть пройти, але MTU або фільтрація можуть ламати окремі протоколи.
Ваш додаток тоді падає творчими способами, і кожен перекладає відповідальність.

Q7: Чи варто використовувати jumbo frames для storage мереж?

Тільки якщо ви можете довести наскрізну MTU-консистентність і виміряли користь. Якщо не можете гарантувати — тримайте 1500 і оптимізуйте інакше.

Q8: Як швидко довести, чи тегування відбувається в потрібному місці?

Захопіть на uplink: у Proxmox використовуйте tcpdump -eni bond0 vlan; на ESXi використайте інструменти захоплення або подивіться конфіг портгрупи.
Якщо бачите 802.1Q теги з очікуваним VLAN — тегування реальне. Якщо ні — конфігурація не відповідає очікуванням.

Q9: Який Proxmox VLAN-дизайн найбільш дружній до міграцій?

VLAN-aware міст з тегами на NIC VM і чітко тегована мережа менеджменту. Це добре мапиться на портгрупи ESXi і уникає спалаху мостів.

Q10: Коли варто обирати міст-на-VLAN на Proxmox?

Коли потрібна максимально явна структура, суворіший поділ або ви інтегруєтеся з процесами, де «ця мережа має свій інтерфейс» — саме так люди мислять і аудитується.

14) Практичні наступні кроки

Якщо ви працюєте на ESXi — розглядайте портгрупи як джерело істини: VLAN ID, налаштування безпеки і правила teaming. Аудитуйте їх, експортуйте
і припиніть допускати, щоб «тимчасові» 4095 транки стали постійною архітектурою.

Якщо ви працюєте на Proxmox — прийміть Linux-реальність: свідомо використовуйте VLAN-aware мости, тримайте IP на правильних інтерфейсах і робіть
bonding усвідомлено (active-backup для нудних мереж, LACP там, де можна валідувати комутатор і хешування).

Наступні кроки, що приносять негайну віддачу:

Оберіть і документуйте одну стандартну стратегію VLAN на платформу (tag у портгрупі vs tag на NIC VM) і одну стратегію винятків (гість-транк) з суворими правилами.
Проганяйте швидкий плейбук діагностики на здоровому хості і зберігайте виводи. Базові лінії скорочують час простою.
Для будь-якого плану LACP або jumbo frames: тестуйте режими відмов і MTU наскрізь перед тим, як святкувати перемогу.