VLAN у Proxmox не працює: налаштуйте VLAN-aware міст правильно

Швидкий план діагностики

Якщо VLAN «не працюють», ви можете втратити години на суперечки з командою комутаторів, командою фаєрвола та тим, хто «лише змінив опис». Не треба. Робіть ось що. Ви шукаєте перше місце, де тега немає, тег неправильний або фрейми відкидаються.

По-перше: доведіть наявність тега на кабелі (зі сторони гіпервізора)

1. Визначте, куди підключена VM (підключайтеся до порту моста, а не покладайтеся на інтуїцію).
2. Захопіть трафік і перевірте VLAN-теги. Якщо кадри, що виходять із ноди, незадетеговані, коли їх треба тегувати, зупиніться і не звинувачуйте комутатор.
3. Підтвердіть, що міст має увімкнене фільтрування VLAN. Класична помилка — «галочка VLAN aware», яку ви насправді не застосували.

По-друге: доведіть, що порт комутатора — trunk (і що native VLAN вам не шкодить)

1. Перевірте список дозволених VLAN. «Trunk» — це недостатньо; trunk може бути обмежений у дозволених VLAN.
2. Перевірте native VLAN. Якщо у вас в середовищі вважають, що «без незатегованих кадрів», але порт присвоює незатегований трафік VLAN 1 (або інший), ви створили тиху чорну діру.

По-третє: перевірте очікування тегування у гостя

1. Або Proxmox тегує для гостя (встановіть VLAN tag на NIC VM), або гість сам тегує (підінтерфейс VLAN всередині VM). Робити і те, і інше — призводить до double-tagging і проблем.
2. Підтвердіть, що DHCP працює в потрібному VLAN. Багато «проблем із VLAN» насправді — це «DHCP relay тут не налаштований».

Цитата на пам’ять: Надія — не стратегія. — General Gordon R. Sullivan (часто цитують у операційних контекстах). Це різко, але краще за «я думаю, що має працювати».

Ментальна модель: де фактично відбувається тегування VLAN

Діагностика VLAN стає простішою, коли ви припините думати про «VLAN на мосту» як про магію і почнете думати про те, хто додає 802.1Q тег і хто очікується зняти його.

Важливі лише три актори

• Гість (VM або контейнер). Він може надсилати теги (підінтерфейси VLAN) або звичайні фрейми (звичайний NIC).
• Хост Proxmox. Він може тегувати/знімати теги з кадрів згідно з налаштуванням NIC VM та правилами фільтрації моста, або пропускати теги далі.
• Порт комутатора. Він може поводитися як access (без тегів, один VLAN) або як trunk (з тегами, багато VLAN, плюс native/untagged VLAN).

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

Proxmox-специфічна реальність

Proxmox дає два основні способи мостування: Linux bridge (за замовчуванням) та Open vSwitch. Обидва працюють. Linux bridge з VLAN filtering цілком придатний для більшості розгортань і має найменше рухомих частин. Віддавайте перевагу йому, якщо немає вагомої причини інакше.

VLAN-aware міст у Proxmox означає: Linux bridge має увімкнене фільтрування VLAN, тож міст здатний мати членство по портах за VLAN, і Proxmox може програмувати ці правила VLAN на основі тегів NIC VM.

Ключова деталь: «VLAN tag», встановлений на NIC VM у Proxmox, — це не просто поле в інтерфейсі. Воно перетворює цей NIC VM на access-порт для цього VLAN, але на upstream‑trunk. Хост тегує трафік, що виходить на фізичний uplink, і роззнакує трафік, що доставляється гостю NIC.

Невідповідність — хвороба. Відповідність — лікування.

Жарт №1: VLAN як офісна політика — усі кажуть, що це просто, доки не спитаєш, хто володіє trunk і який native VLAN.

Цікаві факти та історичний контекст

• 802.1Q тегування додає 4 байти до Ethernet-кадру; саме тому VLAN і MTU можуть конфліктувати несподіваним чином, коли ви близькі до 1500.
• VLAN 1 історично є дефолтним на багатьох комутаторах; «native VLAN» часто за замовчуванням вказує туди, тому незатегований трафік потай опиняється там, куди ви не планували.
• Фільтрація VLAN у Linux bridge стала поширеною в середині 2010-х; раніше багато Linux‑налаштувань покладалися на окремі підінтерфейси VLAN (наприклад, eth0.100) замість правил VLAN по порту.
• Proxmox перевів багатьох користувачів від «ручної Debian‑мережі» до опініонованої моделі, де UI записує /etc/network/interfaces. Це підвищило консистентність — і створило нові способи впевнено помилятися.
• Hardware offloads (особливо VLAN offload) можуть спотворювати результати захоплення пакетів, якщо ви ловите на невірному інтерфейсі; іноді ядро бачить теги, яких tcpdump не бачить, або навпаки.
• Q-in-Q (802.1ad) існує для «подвійного тегування», але більшість SMB/enterprise віртуалізованих розгортань цього не роблять. Випадкове подвійне тегування виглядає як Q-in-Q, але зазвичай воно ненавмисне і відкидається.
• Мости і bond мають довгу іноді заплутану історію у Linux‑мережах; деякі «проблеми VLAN» насправді — проблеми режиму bond / невідповідності LACP, що проявляються вибірковою втратою пакетів.
• Spanning Tree задуманий для запобігання петлям у мостовій мережі; некоректно налаштований STP може виглядати як VLAN-аутейдж, бо трафік блокується, а не втрачається.

Правильні схеми конфігурації (і коли їх використовувати)

Схема A: «Trunk до хоста, Proxmox тегує по NIC VM» (рекомендовано)

Це чистий продакшн‑підхід для більшості кластерів Proxmox. Порт комутатора до ноди — trunk. Linux bridge — VLAN-aware. Кожний NIC VM отримує VLAN‑тег у Proxmox. Гості думають, що вони в звичайній Ethernet‑мережі. Життя прекрасне.

Використовуйте коли: хочете прості конфіги гостей, централізоване керування VLAN та менше «чому ця VM використовує VLAN 200?» загадок.

Уникайте коли: гість повинен бачити кілька VLAN на одному vNIC (наприклад, router VM, firewall VM). Для цього потрібен passthrough тегів.

Приклад /etc/network/interfaces

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.10.10.11/24
        gateway 10.10.10.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

Рядок bridge-vlan-aware yes — ключовий. bridge-vids 2-4094 вказує мосту, які ID VLAN взагалі дозволені на цьому мосту. Якщо його опустити, Proxmox у багатьох випадках все одно працюватиме, бо динамічно програмує членство VLAN, але в продакшні я віддаю перевагу явності. Це на один менше «чому VLAN 3000 не проходить?» сюрприз.

Схема B: «Trunk до хоста, гість сам тегує» (tag passthrough)

Тут ви хочете, щоб VM отримувала затеговані кадри і створювала підінтерфейси VLAN всередині гостя. Так створюють router VM, firewall VM, вузли Kubernetes з CNI‑хитрощами або аплайенси, що очікують trunk.

Конфігурація Proxmox: встановіть VLAN tag для NIC VM у «без тега» (порожнє / 0 залежно від UI). Міст усе одно має бути VLAN-aware, якщо ви хочете фільтрування і уникнути випадкового просочування; але потрібно дозволити VLANи на цьому порту.

Режим відмови: якщо ви встановили тег у Proxmox і тегуєте в гості — ви створили подвійне тегування. Більшість портів комутатора його не пропустить. Ваш packet capture виглядатиме як сучасне мистецтво.

Схема C: «Access порт до хоста, лише один VLAN» (не рекомендовано, але буває)

Так роблять, коли не контролюють комутатор або «лише тестують». Порт комутатора — access у одному VLAN. Proxmox міст не VLAN-aware (або може бути, але це марно тут). Всі VM, підключені до цього моста, опиняються в одному VLAN, якщо ви не почнете робити підінтерфейси VLAN на хості.

Використовуйте коли: лабораторії, вузли для однієї мети або провайдерське середовище, де access VLAN — це продукт.

Уникайте коли: дбаєте про масштабування, мульти‑тент сегментацію або розумове здоров’я вашого майбутнього «я».

Схема D: «Bond (LACP) + trunk + VLAN-aware міст» (поширено в кластерах)

Більшість кластерів бондують два NIC для відмовостійкості та пропускної здатності, а потім ставлять зверху VLAN-aware міст. Це нормально. Але додає додаткові режими відмов: LACP не погоджено, хешування викликає асиметрію, або комутатор налаштований як standalone, а хост очікує LACP.

Найкраща практика: тримайте це нудно. Використовуйте 802.3ad, якщо команда комутаторів це підтримує і налаштує правильно; інакше використовуйте active-backup і спіть спокійно.

Жарт №2: LACP — чудово, поки ні; тоді це розподілена система з двома вузлами і трьома думками.

Практичні завдання: команди, що означає вивід і рішення

Ви не дебагуєте VLAN на відчуттях. Ви дебагуєте їх спостереженнями. Нижче наведені перевірені в польових умовах тести, що відповідають на питання «що істинно прямо зараз?» і що робити далі.

Завдання 1: Підтвердити, що Proxmox вважає міст VLAN-aware

cr0x@server:~$ grep -A10 -n "iface vmbr0" /etc/network/interfaces
12:iface vmbr0 inet static
13-        address 10.10.10.11/24
14-        gateway 10.10.10.1
15-        bridge-ports eno1
16-        bridge-stp off
17-        bridge-fd 0
18-        bridge-vlan-aware yes
19-        bridge-vids 2-4094

Що це означає: Якщо bridge-vlan-aware yes відсутній, Proxmox не зможе застосувати фільтрацію VLAN по портах так, як ви очікуєте.

Рішення: Якщо його немає — додайте (і бажано bridge-vids), потім перезавантажте мережу у вікні технічного обслуговування.

Завдання 2: Перевірити, що фільтрація VLAN дійсно увімкнена в bridge ядра

cr0x@server:~$ bridge link show
2: eno1 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
3: tap100i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
4: fwpr100p0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0

cr0x@server:~$ bridge vlan show
port              vlan-id
eno1              1 PVID Egress Untagged
eno1              100
tap100i0          100 PVID Egress Untagged
fwpr100p0         100 PVID Egress Untagged

Що це означає: Ви дивитеся на членство VLAN по портах. Якщо bridge vlan show порожній або показує тільки VLAN 1 всюди, міст не фільтрує так, як ви очікуєте.

Рішення: Якщо VM має бути в VLAN 100, а її tap порт не PVID 100, виправте тег NIC VM або конфіг bridge VLAN.

Завдання 3: Перевірити конфігурацію NIC VM у Proxmox (режим тегування)

cr0x@server:~$ qm config 100 | egrep "net0|bridge|tag|trunks"
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,tag=100,firewall=1

Що це означає: Цей NIC VM — access-порт для VLAN 100. Гість не повинен створювати підінтерфейси VLAN для цього NIC.

Рішення: Якщо гість теж тегує — видаліть конфіг VLAN у гості або зніміть тег у Proxmox і налаштуйте trunk правильно.

Завдання 4: Перевірити, що фізичний uplink піднятий, має коректну швидкість і не флапає

cr0x@server:~$ ip -br link show eno1
eno1             UP             5c:ba:ef:00:11:22 <BROADCAST,MULTICAST,UP,LOWER_UP>

cr0x@server:~$ ethtool eno1 | egrep "Speed|Duplex|Link detected"
Speed: 10000Mb/s
Duplex: Full
Link detected: yes

Що це означає: Лінк піднятий. Якщо ви бачите падіння швидкості або флапи лінку, ви можете марно гнатися за VLAN-привидами, поки фізичний рівень горить.

Рішення: Якщо лінк нестабільний — зупиніться і виправте кабелі/SFP/помилки на порту комутатора.

Завдання 5: Перевірити помилки та дропи на інтерфейсі до комутатора

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 5c:ba:ef:00:11:22 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    987654321  1234567      0     124       0  45678
    TX:  bytes packets errors dropped carrier collsns
    876543210  1122334      0       0       0       0

Що це означає: Збиті RX пакети можуть бути через перевантаження, обмеження кільця або upstream policing. Це не доказ проблем VLAN, але червона картка.

Рішення: Якщо дропи зростають під час тестів — досліджуйте конгестію на порті комутатора, драйвер NIC і невідповідність MTU.

Завдання 6: Підтвердити MTU моста і врахувати накладні витрати VLAN

cr0x@server:~$ ip -d link show vmbr0 | egrep "mtu|vlan|bridge"
2: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    bridge vlan_filtering 1 vlan_default_pvid 1

Що це означає: Фільтрація VLAN увімкнена (vlan_filtering 1). MTU 1500 — підходить для більшості VLAN‑мереж, але може підкосити вас, якщо середовище очікує jumbo‑фрейми наскрізь.

Рішення: Якщо ви використовуєте MTU 9000 на storage/vMotion‑подібних мережах — забезпечте консистентність MTU на NIC, мості та trunk на комутаторі.

Завдання 7: tcpdump на uplink, щоб побачити VLAN-теги (або їх відсутність)

cr0x@server:~$ tcpdump -eni eno1 -c 10 vlan
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:01:11.123456 5c:ba:ef:00:11:22 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 100, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: DHCP, Request
10:01:11.223456 00:11:22:33:44:55 > 5c:ba:ef:00:11:22, ethertype 802.1Q (0x8100), length 370: vlan 100, p 0, ethertype IPv4, 10.10.100.1.67 > 10.10.100.50.68: DHCP, Reply

Що це означає: Ви буквально бачите VLAN 100 на лінії. Це одразу відповідає на питання «чи хост тегує і отримує теги правильно?»

Рішення: Якщо ви не бачите VLAN-тегів із хоста — зосередьтесь на конфіг bridge/VM NIC у Proxmox. Якщо ви бачите теги, але нічого не повертається — дивіться на trunk комутатора і upstream L2/L3.

Завдання 8: tcpdump на tap‑інтерфейсі VM, щоб підтвердити доставку без тега гостю

cr0x@server:~$ tcpdump -eni tap100i0 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tap100i0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:02:01.100001 de:ad:be:ef:10:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 328: 0.0.0.0.68 > 255.255.255.255.67: DHCP, Request
10:02:01.200002 00:11:22:33:44:55 > de:ad:be:ef:10:00, ethertype IPv4 (0x0800), length 352: 10.10.100.1.67 > 10.10.100.50.68: DHCP, Reply

Що це означає: Тут немає 802.1Q. Це очікувано, коли Proxmox робить тегування, а гість намагається бути в access‑VLAN.

Рішення: Якщо ви бачите 802.1Q на tap, коли не очікуєте — ви налаштували passthrough тегування або гість сам тегує несподівано.

Завдання 9: Перевірити, чи Proxmox firewall не відкидає те, що ви вважаєте «VLAN‑трафіком»

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

cr0x@server:~$ pve-firewall compile
root@pam: OK

Що це означає: Фаєрвол активний і компілюється. VLAN сам по собі не «блокується фаєрволом», але DHCP, ARP або ICMP можуть бути.

Рішення: Тимчасово відключіть фаєрвол на NIC VM (не глобально), щоб ізолювати проблему. Якщо це допоможе — перегляньте правила, це не VLAN‑помилка.

Завдання 10: Перевірити ARP‑резолюцію в неймспейсі хоста (швидка L2 перевірка)

cr0x@server:~$ ip neigh show dev vmbr0 | head
10.10.10.1 lladdr 00:aa:bb:cc:dd:ee REACHABLE
10.10.10.50 lladdr de:ad:be:ef:10:00 STALE

Що це означає: Хост бачить сусідів на vmbr0 (ймовірно management VLAN). Це не доводить, що VLAN 100 працює, але доводить, що міст живий і працює на L2.

Рішення: Якщо таблиця neighbor порожня і ви не можете ARP навіть у management — виправте базову конективність перед роботою з VLAN.

Завдання 11: Для режиму trunk‑to‑guest підтвердити, що гість бачить затеговані VLAN (зі сторони хоста)

cr0x@server:~$ qm config 200 | egrep "net0|tag"
net0: virtio=DE:AD:BE:EF:20:00,bridge=vmbr0,firewall=0

cr0x@server:~$ tcpdump -eni tap200i0 -c 5 vlan
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tap200i0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:03:11.010101 de:ad:be:ef:20:00 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 200, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: DHCP, Request

Що це означає: Tap бачить VLAN‑теги, як і має бути при trunk‑режимі гостя.

Рішення: Якщо ви очікуєте trunk і не бачите тегів — гість не тегує або Proxmox ненавмисно знімає теги через конфігурацію.

Завдання 12: Перевірити стан bond, якщо ви його використовуєте (LACP/active-backup)

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
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: 1
        Number of ports: 2
        Actor Key: 17
        Partner Key: 42
        Partner Mac Address: 00:25:90:12:34:56

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

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

Що це означає: LACP погоджено і обидва слейви підняті. Якщо бракує Partner Key/MAC або лише один слейв активний несподівано — upstream port-channel може бути налаштований неправильно.

Рішення: Виправте узгодження LACP/port-channel перед тим, як гнатися за конфігурацією VLAN. Поламаний bond може випадково скидати деякі VLAN залежно від хешування і upstream‑поведінки.

Завдання 13: Підтвердити, що Proxmox застосував конфіг (немає застарілого runtime‑стану)

cr0x@server:~$ ifreload -a
warning: vmbr0: interface is already configured
warning: eno1: interface is already configured

Що це означає: Перезавантаження виконано; попередження можуть бути нормальними. Ви хочете бачити: відсутність критичних помилок і відповідність runtime‑стану файлу.

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

Завдання 14: Перевірити sysctl або nftables, що пов’язані з VLAN (рідко, але буває)

cr0x@server:~$ sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.bridge.bridge-nf-call-arptables
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-arptables = 1

Що це означає: Містовий трафік потрапляє у хуки iptables/nftables. Це може бути бажаним (фільтрація) або фатальним (неочікувані дропи/затримки).

Рішення: Якщо ви навмисно не фільтруєте містовий трафік — розгляньте відключення цих опцій або перевірте правила фаєрвола уважно. «VLAN зламаний» іноді означає «bridge netfilter з’їв DHCP».

Три корпоративні міні-історії з VLAN-«окопів»

Міні‑історія 1: Аутейдж через хибне припущення

Середня компанія консолідувала стійки. Команда віртуалізації перемістила Proxmox‑ноду з старого стеку на новий leaf. Команді мереж сказали: «Порт trunk, вам вистачить». Нода піднялася, management працював, але всі tenant VLAN на цій ноді були мертві.

Команда віртуалізації припустила, що «trunk» означає «всі VLAN дозволені». На новому шаблоні комутаторів trunk був обмежений списком дозволених VLAN. Management VLAN був включений (бо всі потребують management), але tenant VLAN — ні. Хост старанно тегував кадри; комутатор старанно їх відкидав. Обидві сторони поводилися правильно.

Було гірше тому, що симптоми були вибіркові: деякі VM на ноді могли говорити з «shared services», які випадково були в management VLAN, тож ап‑оунери повідомляли про «переривчасті» проблеми. Хтось навіть припустив «Proxmox баг із VLAN». Ні — не було.

Виправлення було нудним: узгодити список дозволених VLAN з діапазоном VLAN, який планував гіпервізор, і документувати це. Дія післяінцидентного аналізу, що важила — не «покращити моніторинг», а «перестати використовувати слово trunk без уточнення allowed VLAN і поведінки native VLAN».

Міні‑історія 2: Оптимізація, що відкотилася назад

Ще одна організація захотіла «зменшити складність мережі». Вони вирішили, що кожна Proxmox‑нода матиме один bond, а кожен міст працюватиме з обрізаним списком VLAN: лише ті VLAN, що зараз використовуються. Ідея — зменшити площу ураження, якщо VM неправильно тегована.

Працювало — доки ні. Новий проєкт підняв VM у VLAN 240, і команда VM правильно проставила тег у Proxmox. Але bridge-vids на vmbr0 дозволяв лише 2-239. Linux bridge відфільтрував VLAN до того, як він дійшов до комутатора. З точки зору комутатора — нічого не відбувається. З точки зору Proxmox — нічого «не неправильно». З точки зору VM — всесвіт мовчить.

Тікет бігав між командами, бо всі перевіряли свій шар: конфіг VM мав tag=240, trunk комутатора дозволяв VLAN 240, фаєрвол мав правила, DHCP був готовий. Відсутнім кусочком був хост, оптимізований так, щоб виключати майбутні VLAN.

Вони зберегли фільтрацію VLAN (добре), але змінили політику: дозволяти широкий діапазон VLAN на uplink нод і контролювати доступ VM до VLAN через права Proxmox і рев’ю. Security‑by‑outdated‑allowlist — не безпека. Це таймер з бомбою.

Міні‑історія 3: Нудна практика, що врятувала день

Фінансова команда тримала Proxmox під строгим контролем змін. Кожна нода мала стандартну мережеву конфігурацію: bond0 (active-backup), vmbr0 для management, vmbr1 VLAN-aware trunk для гостей, і невелика «validation VM» на кожній ноді. Ця VM могла запускати DHCP‑запити, пінгувати шлюз і відправляти затеговані кадри за запитом.

Одного ранку цілий стій втратив конективність тільки для VLAN 310. Не management, не інші VLAN. Логи комутаторів були шумними, але неочевидними. Люди почали підозрювати зміну ACL у core.

On‑call SRE використав validation VM на двох нодах: одну в ураженому стійку, іншу в здоровому. Та сама мітка VLAN, той самий DHCP‑тест, той самий ping‑ціль. Захоплення на фізичних uplink показало, що в ураженому стійку ніколи не було відповідей — жодного DHCP Offer, жодної ARP відповіді — в той час як у здоровому стійку все було добре.

Ці докази звузили радіус проблеми до «десь між ToR і upstream» за кілька хвилин. Команда комутаторів знайшла член порту‑каналу зі старою конфігурацією, що не дозволяла VLAN 310. Оскільки bond був active-backup, перемикання активного лінку на правильно налаштований член відновило сервіс швидко.

Нудна практика: стандартизовані конфіги, маленька validation VM і звичка робити захоплення пакетів на краю. Це не було гламурно. Це було ефективно.

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

1) Немає DHCP на VLAN‑тегованій VM, але лінк піднятий

Симптом: NIC VM показує «connected», але DHCP таймаутиться. Pings не проходять.

Коренева причина: Порт комутатора — access VLAN (або trunk без VLAN) в той час, як Proxmox тегує кадри, отже теговані кадри відкидаються.

Виправлення: Налаштуйте порт комутатора як trunk і дозвольте потрібний VLAN. Підтвердіть tcpdump -eni eno1 vlan, що відповіді приходять.

2) VM спілкується в неправильній мережі (неочікувана конективність)

Симптом: VM, яка мала бути в VLAN 200, отримує IP з VLAN 1 або management VLAN.

Коренева причина: Невідповідність native VLAN / PVID: незатегований трафік мапиться в небажаний VLAN десь (на хості або комутаторі).

Виправлення: Визначте, що означає «незатегований» трафік. Віддавайте перевагу політиці «немає незатегованих» на trunk у продакшні. Переконайтеся, що uplink vmbr не використовує VLAN 1 як PVID, якщо це не навмисно.

3) Працює лише один VLAN; інші мертві

Симптом: VLAN 100 працює, VLAN 200 — ні, на тому ж хості/uplink.

Коренева причина: Список дозволених VLAN на trunk обмежений, або bridge-vids виключає VLAN.

Виправлення: Перевірте bridge vlan show і список allow‑на trunk на комутаторі. Розширте дозволений набір і протестуйте ще раз.

4) «Переривчасті» проблеми VLAN на bonded uplinks

Симптом: Випадкові втрати пакетів, деякі потоки працюють, інші ні; гірше під навантаженням.

Коренева причина: Невідповідність LACP або неправильно налаштовані члени port-channel з різними allowed VLAN/native VLAN/MTU.

Виправлення: Перевірте стан bond у /proc/net/bonding/* і переконайтеся, що члени порт‑каналу на комутаторі ідентичні. Не приймайте «майже ідентичні».

5) Захоплення показує відсутність VLAN‑тегів, хоча ви встановили tag=100

Симптом: tcpdump на eno1 не показує 802.1Q.

Коренева причина: Плутанина через VLAN offload/capture point, або трафік ніколи не виходить, бо міст фільтрує його.

Виправлення: Ловіть пакети і на tap, і на фізичному uplink; перевірте bridge vlan show. Якщо потрібно, тимчасово вимкніть VLAN offload під час діагностики і повторіть тест.

6) Гості в одному VLAN не можуть спілкуватися між собою

Симптом: Дві VM в VLAN 300 можуть доходити до шлюзу інколи, але не одна до одної стабільно.

Коренева причина: Правила Proxmox firewall, ebtables/nft фільтрація або STP/захист від петель блокують внутрішньохостове переключення.

Виправлення: Тимчасово вимкніть фаєрвол VM, перевірте L2. Потім поверніть правила поступово. Перевірте sysctls bridge netfilter.

7) Контейнери (LXC) поводяться інакше, ніж VM

Симптом: VLAN‑тегована VM працює; VLAN‑тегований контейнер — ні (або навпаки).

Коренева причина: Контейнер використовує іншу поведінку віртуального інтерфейсу, і ви могли тегувати на неправильному шарі (конфіг контейнера vs порт моста).

Виправлення: Стандартизуйте: або тегуйте на veth інтерфейсі Proxmox (хостова сторона), або всередині контейнера — не робіть і те, і інше; підтвердіть через bridge vlan show.

8) Міграція на іншу ноду ламає мережу VM

Симптом: VM працює на вузлі A, але не працює на вузлі B.

Коренева причина: Невідповідність мережевих конфігів між нодами: міст не VLAN-aware, інший bond/trunk, відсутні VLAN у allow‑листі.

Виправлення: Розглядайте мережу Proxmox як кластерний ресурс. Ті самі імена vmbr, ті самі VLAN-aware налаштування і та сама поведінка фізичного trunk на всіх нодах.

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

Крок за кроком: Побудуйте правильний VLAN-aware міст на одному uplink

1. Визначте модель: host тегує на NIC VM (рекомендовано) або гість сам тегує (trunk‑to‑guest). Запишіть це. Це уникне подвійного тегування.
2. Налаштуйте порт комутатора: trunk, дозволіть VLAN, які будете використовувати, встановіть native VLAN навмисно (або ефективно відключіть незатегований трафік). Тримайте MTU консистентним.
3. Налаштуйте Proxmox міст: Linux bridge з bridge-vlan-aware yes. За бажанням вкажіть bridge-vids у раціональному діапазоні.
4. Підключіть NIC VM: для access‑стилю встановіть tag=VLANID на кожен NIC VM. Для trunk‑to‑guest залиште тег порожнім.
5. Перевірте захопленнями: підтвердіть теги на фізичному uplink і незатеговані кадри на tap для access‑VM.
6. Зафіксуйте консистентність: реплікуйте конфіг по нодах. Невідповідність — причина проблем при міграціях.

Чекліст: Перш ніж звинувачувати VLAN

• Фізичний лінк стабільний? (ethtool, ip -s link)
• Міст справді фільтрує VLAN? (bridge vlan show)
• NIC VM затеговано у точно одному місці? (Proxmox або гість)
• Trunk комутатора дозволяє VLAN? (не тільки «це trunk»)
• Бачите DHCP Offer/ARP відповіді на захопленні uplink?
• MTU консистентний наскрізь для VLAN?
• Фаєрвол не фільтрує містовий трафік несподівано?

Чекліст: Безпечна процедура змін для production‑нод

• Заплануйте вікно, якщо змінюватимете bridge-ports, bond чи перезавантажуватимете мережу.
• Майте доступ до консолі out‑of‑band. Зміни мережі лише віддалено — це спосіб життя з певним ризиком.
• Міняйте по одній змінній: спочатку список allow‑VLAN на комутаторі, потім конфіг хоста, потім теги VM.
• Захоплюйте трафік до/після змін на фізичному uplink. Це ваша правда.
• Після змін тестуйте: DHCP, ping шлюзу, ping між VM та невелика TCP‑сесія.

FAQ

1) Чи потрібен Open vSwitch, щоб VLAN працювали в Proxmox?

Ні. Linux bridge з увімкненим VLAN-aware достатній для більшості розгортань. OVS корисний, якщо вам потрібні його фічі або операційна модель, але не як пластир для VLAN.

2) Що саме змінює «VLAN aware»?

Воно увімктає фільтрацію VLAN на Linux bridge, дозволяючи членство VLAN по порту і даючи Proxmox можливість програмувати access/trunk поведінку для NIC VM.

3) Чи варто ставити bridge-vids 2-4094?

У продакшні — так, якщо немає причин обмежувати. Це запобігає дивним випадкам «VLAN не проходить, бо він поза дозволеним діапазоном», коли хтось додає новий VLAN.

4) Чому VM втрачає конективність після live‑міграції?

Цільова нода ймовірно має інші налаштування VLAN моста, інший список дозволених VLAN upstream або інше мапування vmbr. Робіть мережу нод ідентичною для мігруючих робочих навантажень.

5) Де має відбуватися тегування VLAN: у Proxmox чи всередині гостя?

Оберіть одне. Для звичних VM — тегуйте у Proxmox (простішe, централізовано). Для router/firewall/appliance VM, що потребують кількох VLAN — тегуйте всередині гостя і пропускайте trunk.

6) Чому tcpdump інколи не показує VLAN‑теги, коли я їх очікую?

VLAN offload може призводити до того, що теги обробляються апаратно, і захоплення залежить від інтерфейсу та драйвера. Ловіть пакети в кількох точках (tap і фізичний) і зіставляйте з bridge vlan show.

7) Чи може Proxmox firewall зламати DHCP на VLAN?

Так. DHCP — це багато широкомовного трафіку, чутливого до фільтрації. Якщо містовий трафік проходить через netfilter hooks, правило може відкинути DHCP або ARP і створити ілюзію «зламаного VLAN».

8) Чи вимагають VLAN вищого MTU?

Не обов’язково. Стандартний MTU 1500 працює з VLAN‑тегуванням у більшості середовищ. Проблеми виникають, коли ви намагаєтеся використовувати jumbo‑кадри, а якийсь сегмент шляху не налаштований відповідно.

9) Мій комутатор каже, що порт trunk, але VLAN все одно падає. Що запитати?

Запитайте: список дозволених VLAN, native VLAN та підтвердження, що всі члени port-channel мають однакові VLAN/MTU налаштування. «Це trunk» — не відповідь.

10) Чи безпечно пропускати management‑трафік через той самий VLAN‑aware міст, що і гості?

Може бути, але мені це не дуже подобається. Краще відокремити management (vmbr0) від гостинних trunk (vmbr1), коли це можливо. Це зменшує площу ураження та полегшує діагностику.

Висновок: кроки, що запобігають повторним інцидентам

Виправлення проблеми VLAN у Proxmox рідко пов’язане з «чарівною правильною опцією». Це про явний контракт тегування: хто тегує, де дозволено і що означає незатегований трафік. Коли ви можете вказати на захоплення пакету і сказати «це VLAN 100, що виходить з хоста», суперечки закінчуються і починається інженерія.

Зробіть наступні кроки:

1. Стандартизувати мережі нод по кластеру (однакові імена vmbr, VLAN-aware налаштування та поведінка bond).
2. Документувати очікувану поведінку trunk на комутаторах у операційних термінах: allowed VLAN, native VLAN, MTU, політика LACP.
3. Додати повторювану процедуру валідації: відома VM або скрипт, що робить DHCP/ping на вказаному VLAN, плюс рецепт захоплення пакетів.
4. Ускладнити подвійне тегування політикою: або Proxmox тегує access‑VLAN, або гість робить trunk — ніколи обидва.

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