Мережі: VLAN зроблено неправильно — єдина помилка, що створює «привидні» відмови

Єдина помилка: неконсистентне тегування по шляху

Ось помилка, що створює привидні відмови: VLAN тегується на одному боці лінка, а на іншому боці його трактують як нетегований.
Або native VLAN відрізняється між кінцями транку. Або список allowed VLANs не збігається по ланцюгу транків.
Різні варіанти — одна хвороба: у вас немає єдиної консистентної відповіді на питання «в якому VLAN цей кадр?» від кінця до кінця.

На практиці це проявляється так:

• Сервер відправляє теговані кадри на eth0.120, але порт комутатора налаштований як access-порт у VLAN 120 (очікує нетеговані кадри).
• Транк має native VLAN 1 на одному боці і native VLAN 120 на іншому. Нетеговані кадри стають VLAN 1 на одному боці і VLAN 120 на іншому.
• «Корисне» скорочення allowed VLANs на агрегаційному транку випадково видаляє VLAN, яким усе ще користується легасі-хост.
• Порт-група vSwitch гіпервізора очікує VLAN 120, але фізична NIC вгорі встановлена як «нетегована» і покладається на комутатор, що поставить тег.

Погана новина: це не завжди позбавляє всього зв’язку. Найнебезпечніші випадки пропускають достатньо зв’язку, щоб системи були напівживі.
ARP і MAC learning можуть коливатись. Деякі потоки хешуються в один бік, інші — в інший. Повторні спроби маскують проблему, поки не настане пікове навантаження і система не визнає, що їй боляче.

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

Чому це створює «привидні» відмови (а не чисті збої)

1) Плутанина в широкомовному домені: ARP і ND поводяться як ненадійні оповідачі

Коли тегування неконсистентне, ARP-запити можуть виходити в одному VLAN, а ARP-відповіді повертатися в іншому — або приходити на інший порт через коливання MAC-таблиці.
Хост кешує «IP → MAC». Комутатор кешує «MAC → порт». Тепер у вас два незалежні кеші, що моделюють реальність, яку ви щойно зламали.

Ви побачите такі симптоми:

• ARP-записи, що змінюються між двома MAC для тієї самої IP-адреси (або той самий MAC скаче по портах).
• Дивакуватості Neighbor Discovery в IPv6: reachable, stale, reachable, stale — без очевидної причини.
• З’єднання працює хвилину після оновлення ARP, потім деградує до наступного оновлення.

2) «Переважно працює» гірше, ніж «упало»

Чисті відмови вас оповістять, змушують діяти і закінчуються швидко. Привидні відмови тягнуться днями, бо:

• TCP-повторні спроби ховають втрати пакетів, поки затримки хвосту не стануть помітні бізнесу.
• Перевірки здоров’я пробують щасливий шлях, а реальний трафік йде по зламаному.
• Балансувальники навантаження тримають одну ніжку живою і тихо зливають іншу, тож ви помічаєте проблему тільки під навантаженням.
• Моніторинг агрегує шаблон: 0.5% втрат виглядає як шум, поки це не стане вашою базою даних.

3) Неконсистентне тегування створює асиметричні шляхи

Класичний привид: вихідний трафік йде з сервера нормально, але відповідний трафік потрапляє в інший VLAN або на інший порт, бо мережа десь навчила MAC інакше.
Або навпаки. Ви можете пінгувати в один бік, провалюватися в інший і витратити години, звинувачуючи фаєрволи. Логи фаєрвола виглядатимуть невинно, бо пакети ніколи не дісталися до них.

4) MTU і оверхед тегу VLAN можуть перетворити «нормально» на «хитке»

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

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

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

• IEEE 802.1Q (VLAN-тегування) став міжоперабельним стандартом, бо в 1990-х у вендорів були несумісні методи транкування.
• 802.1Q тег має 4 байти: 12-бітний VLAN ID (1–4094 придатні), плюс біти пріоритету й індикатор допустимості скидення.
• VLAN 0 зарезервований для priority-tagging; він «тегований», але не призначається як звичайний VLAN.
• VLAN 1 має історичний багаж: багато пристроїв за замовчуванням тримають там management/control-plane протоколи, тому «native VLAN 1 усюди» стало поширеним (і ризикованим).
• Native VLAN існує переважно для зворотної сумісності з нетегованим Ethernet; це також часте джерело мовчазних невідповідностей.
• Double-tagging атаки (VLAN hopping) експлуатували поведінку native VLAN; сучасна практика — уникати використання VLAN 1 як native і уникати нетегованих транків.
• Раніше дата-центри часто використовували VLAN для створення «зон безпеки», але VLAN — це сегментація, а не безпека; контроль залишається за ACL/фаєрволами.
• Велики середовища перейшли від «VLAN на додаток» до EVPN/VXLAN оверлеїв, оскільки масштаб L2 і складність spanning tree стали операційно дорогими.
• Список «allowed VLAN» на транку — і механізм безпеки, і рушій помилок: він обмежує радіус ураження, але може залишити трафік наодинці при дрейфі.

Підписи відмов: як це виглядає у продакшені

Привидні відмови мають свій характер. Коли вас один раз «попекло», ви відчуваєте їх по графіках.

Симптоми, які можна показати графіками

• Короткі, повторювані спалахи втрат кожні кілька хвилин (часто вирівняні з таймерами оновлення ARP/ND або старіння MAC).
• Сплески затримок без насичення пропускної здатності, особливо у east-west трафіку.
• Одна зона доступності/стійка «відчувається повільною», але нічого повністю не впало; пересунення робочих навантажень «вирішує» проблему.
• Нестабільність зберігача: тайм­аути iSCSI/NFS, флепи Ceph OSD, відставання реплікації. Зберігання нещадне і стане вашим раннім попередженням.

Симптоми в логах

• ARP flux (бурі грударних ARP, ріст churn у кеші сусідів).
• Попередження про MAC flapping на комутаторах («MAC переміщено з порту X на порт Y»).
• Лічильники помилок інтерфейсів, що не збігаються зі здоровим описом (CRC ок, але збільшуються drop; або входні помилки різко ростуть на аплінку).
• Повтори застосунку і тайм­аути без кореляції з навантаженням CPU/пам’яті.

Чому ваша перша гіпотеза зазвичай неправильна

Ви звинуватите DNS. Потім балансувальник. Потім Kubernetes. Потім «команду фаєрвола». Тим часом мережа тихо неправильно маркує кадри.
Найшвидші команди вчаться перевіряти VLAN-контракт, перш ніж винаходити нові теорії.

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

Це петля триажу, яку я використовую, коли хтось каже «це інтермітентно», а кава ще не подіяла.
Мета — знайти вузьке місце швидко, а не проходити духовну подорож через кожен комутатор.

По-перше: доведіть, чи це L2/VLAN-парадокс

1. Виберіть один уражений хост і одну ціль (IP-шлюз ідеально). Запустіть безперервний ping і ping з великою MTU (де дозволено).
2. Спостерігайте ARP/ND під час проблеми. Якщо ARP-записи змінюються або стають неповними, підозрюйте VLAN/некоректне тегування негайно.
3. Перевірте стабільність MAC-адреси на комутаторі: якщо той самий MAC переміщується між портами/VLAN, ви в L2-сфері.

По-друге: перевірте контракт тегування від кінця до кінця

1. На хості: підтвердіть, чи NIC відправляє теговані кадри (VLAN subinterface), чи нетеговані (звичайний інтерфейс).
2. На суміжному switchport: підтвердіть режим access vs trunk, native VLAN та список allowed VLANs.
3. Пройдіть аплінки: на кожному транку в шляху перевірте, що VLAN дозволено і послідовно тегується (і native VLAN збігаються, якщо використовуються).

По-третє: перевірте, чи це не MTU

1. Підтвердіть MTU на хості, switchport та на будь-яких межах оверлею/андерлею.
2. Пошукайте великі падіння, лічильники фрагментації або невідповідність TCP MSS clamping.
3. Не забувайте про гіпервізори і бонди — MTU-дрейф любить віртуалізацію.

По-четверте: упевніться, що ви не створили петлю чи hairpin

1. Перевірте зміни spanning-tree, заблоковані порти або неочікуваний forwarding state.
2. Перевірте LACP mis-bundles, коли одна сторона вважає це port-channel, а інша — двома незалежними лінками.
3. Пошукайте дублікати IP або плутанину VRRP/HSRP, що може імітувати проблеми VLAN.

Якщо виконати ці чотири кроки, ви або знайдете невідповідність VLAN, або швидко викреслите її і перейдете далі, не витрачаючи день.

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

Практика краще за теорію. Нижче реальні завдання, які можна виконати на Linux-хостах та звичних середовищах комутаторів. Кожне містить:
команду, що значить вивід і яке рішення з нього випливає.

Завдання 1: Перевірити, чи хост використовує VLAN subinterfaces

cr0x@server:~$ ip -d link show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
3: eth0.120@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    vlan protocol 802.1Q id 120 <REORDER_HDR>

Значення: eth0.120 існує і відправлятиме теговані кадри VLAN 120. Батьківський eth0 — лише носій.

Рішення: Порт комутатора поруч із цим хостом повинен бути trunk (або гібридний порт, налаштований приймати тегований VLAN 120). Якщо це access VLAN 120 — у вас невідповідність.

Завдання 2: Підтвердити, що IP прив’язаний до очікуваного VLAN-інтерфейсу

cr0x@server:~$ ip addr show dev eth0.120
3: eth0.120@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.20.120.17/24 brd 10.20.120.255 scope global eth0.120
       valid_lft forever preferred_lft forever

Значення: IP хоста знаходиться на тегованому інтерфейсі, а не на eth0.

Рішення: Якщо switchport — access (нетегований), хост кричатиме у теговану порожнечу. Виправте режим порту або перемістіть IP на правильний інтерфейс.

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

cr0x@server:~$ ip route show default
default via 10.20.120.1 dev eth0.120 proto static

Значення: Маршрут за замовчуванням виходить через підінтерфейс VLAN 120.

Рішення: Якщо шлюз доступний періодично, зосередьтесь на L2 (VLAN/ARP), перш ніж шукати проблему в маршрутизації вгору.

Завдання 4: Спостерігати ARP під час вікна проблеми

cr0x@server:~$ ip -s neigh show dev eth0.120
10.20.120.1 lladdr 00:25:90:aa:bb:cc REACHABLE used 42/0/38 probes 0
10.20.120.50 lladdr 00:25:90:11:22:33 STALE used 9/9/0 probes 0

Значення: Якщо записи перемикаються між REACHABLE, STALE та INCOMPLETE під час відмов, щось порушує L2 досяжність або відповіді приходять на інший сегмент.

Рішення: Нестабільність ARP/ND — гучна підказка: перевірте узгодженість тегування та переміщення MAC на комутаторах.

Завдання 5: Захопити VLAN-теги на лінії (довести, що хост ставить теги)

cr0x@server:~$ sudo tcpdump -eni eth0 -c 5 vlan 120
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:01.123456 52:54:00:12:34:56 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 120, p 0, ethertype ARP, Request who-has 10.20.120.1 tell 10.20.120.17, length 46
12:10:02.123457 52:54:00:12:34:56 > 00:25:90:aa:bb:cc, ethertype 802.1Q (0x8100), length 74: vlan 120, p 0, ethertype IPv4, 10.20.120.17 > 10.20.120.1: ICMP echo request, id 123, seq 1, length 32

Значення: Кадри, що виходять з eth0, мають VLAN-тег (ethertype 0x8100, VLAN 120).

Рішення: Якщо switchport — access/нетегований, він не прийме ці кадри (або може відкидати їх). Налаштуйте порт як trunk або приберіть тегування на хості.

Завдання 6: Перевірити MTU і шукати пастку «пінг працює, передачі — ні»

cr0x@server:~$ ip link show dev eth0.120
3: eth0.120@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

Значення: MTU на VLAN-інтерфейсі — 1500. Якщо ваша мережа очікує jumbo кадри (9000) або ви працюєте з оверлеями, можливо, ви випадково фрагментуєте або втрачаєте.

Рішення: Якщо ви бачите селективні збої для великих payload, проведіть path MTU тест і вирівняйте MTU від кінця до кінця.

Завдання 7: Тест path MTU без фрагментації

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.120.1
PING 10.20.120.1 (10.20.120.1) 1472(1500) bytes of data.
1472 bytes from 10.20.120.1: icmp_seq=1 ttl=64 time=0.402 ms
1472 bytes from 10.20.120.1: icmp_seq=2 ttl=64 time=0.398 ms
1472 bytes from 10.20.120.1: icmp_seq=3 ttl=64 time=0.401 ms

--- 10.20.120.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms

Значення: Шлях з MTU 1500 до шлюзу працює. Якщо це не так — у вас проблема MTU або фільтрація.

Рішення: Якщо 1472 не проходить, але маленькі пінги проходять, не називайте це «рандомним» — виправляйте MTU або MSS clamping; чотири байти тегу VLAN можуть бути частиною проблеми.

Завдання 8: Перевірити Linux VLAN filtering і членство моста (поширено на гіпервізорах)

cr0x@server:~$ bridge vlan show
port              vlan-id  
eth0              1 PVID Egress Untagged
br0               1 PVID Egress Untagged
vnet0             120

Значення: Налаштування хоста/моста несиметричне: eth0 фактично нетегований у VLAN 1, тоді як VM NIC (vnet0) очікує VLAN 120.

Рішення: Ось як отримуєте «VM іноді працює» залежно від того, на який інтерфейс приходить трафік. Виправте VLAN filtering на мосту: тегніть VLAN 120 на uplink або перемістіть VM у правильний portgroup.

Завдання 9: Підтвердити стан bond/LACP (L2-проблеми часто ховаються в «пів-бонді»)

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
Active Aggregator Info:
        Aggregator ID: 2
        Number of ports: 2
Slave Interface: eth1
MII Status: up
Actor Churn State: churned
Partner Churn State: churned
Slave Interface: eth2
MII Status: up
Actor Churn State: stable
Partner Churn State: stable

Значення: Один slave показує churn. Це може корелювати з періодичним реупорядкуванням пакетів або втратами, особливо якщо switch-side LACP неправильно налаштований або VLAN відрізняються по member link.

Рішення: Перевірте, що port-channel правильно сформовано і до бандлу застосовано послідовне налаштування VLAN, а не на окремих member-портах.

Завдання 10: Шукати докази MAC flapping на хості (як підказка)

cr0x@server:~$ sudo journalctl -k --since "1 hour ago" | tail -n 8
Feb 04 09:12:11 server kernel: IPv6: eth0.120: neighbor 10.20.120.1 is using my MAC address 52:54:00:12:34:56
Feb 04 09:12:12 server kernel: arp: 10.20.120.1 moved from 00:25:90:aa:bb:cc to 00:25:90:dd:ee:ff on eth0.120
Feb 04 09:12:40 server kernel: arp: 10.20.120.1 moved from 00:25:90:dd:ee:ff to 00:25:90:aa:bb:cc on eth0.120

Значення: MAC шлюзу ніби змінюється. Це може статися при HA-шлюзах, але патерн разом з відмовами часто вказує на витік VLAN або петлю.

Рішення: Підтвердіть, чи шлюз дійсно резервний (VRRP/HSRP) і чи ці пристрої послідовно ділять VLAN. Якщо ні — підозрюйте невідповідність тегування або L2-петлю.

Завдання 11: На Linux-маршрутизаторі/фаєрволі перевірте наявність VLAN-інтерфейсів і їх іменування

cr0x@server:~$ ip -d link show | grep -E "vlan|eth1\."
5: eth1.120@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    vlan protocol 802.1Q id 120 <REORDER_HDR>
6: eth1.220@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    vlan protocol 802.1Q id 220 <REORDER_HDR>

Значення: Маршрутизатор очікує теговані VLAN 120 і 220 на eth1.

Рішення: Суміжний switchport повинен транкувати ці VLAN до маршрутизатора. Якщо хтось «спростив» це до access VLAN 120, VLAN 220 зникне у дивних, часткових способах.

Завдання 12: Перевірити, чи правила фаєрвола не обманюють вас (бо пакети ніколи не доходять)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,40p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iifname "eth1.120" ip saddr 10.20.120.0/24 tcp dport { 22, 443 } accept
    iifname "eth1.220" ip saddr 10.20.220.0/24 tcp dport 443 accept
  }
}

Значення: Правила залежать від інтерфейсу. Якщо пакети VLAN 120 випадково приходять нетегованими на eth1, вони не потраплять під ці правила і за замовчуванням відкидаються.

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

Завдання 13: Підтвердити членство VLAN на стороні комутатора за допомогою LLDP (коли доступно)

cr0x@server:~$ sudo lldpctl | sed -n '1,40p'
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    eth0, via: LLDP, RID: 1, Time: 0 day, 00:00:22
  Chassis:
    ChassisID:    mac 00:1c:73:aa:bb:cc
    SysName:      tor-sw-07
  Port:
    PortID:       ifname Ethernet1/7
    PortDescr:    server-rack12-u14
  VLAN:           120

Значення: Комутатор рекламує VLAN 120 на тому порту. LLDP може бути хибним або неповним, але це корисна підказка.

Рішення: Якщо LLDP показує VLAN 120, але хост ставить теги й порт реально access VLAN 120, ви все ще маєте невідповідність. Використовуйте це як напрямок, а не як істину в останній інстанції.

Завдання 14: Перевірити фактичну класифікацію пакета на шляху за допомогою conntrack (для інтермітентних потоків)

cr0x@server:~$ sudo conntrack -L | head
tcp      6 431999 ESTABLISHED src=10.20.120.17 dst=10.20.120.80 sport=52344 dport=5432 src=10.20.120.80 dst=10.20.120.17 sport=5432 dport=52344 [ASSURED] mark=0 use=1
tcp      6 431998 ESTABLISHED src=10.20.120.17 dst=10.20.120.90 sport=49712 dport=443 src=10.20.120.90 dst=10.20.120.17 sport=443 dport=49712 [ASSURED] mark=0 use=1

Значення: Потоки існують і встановлені; якщо застосунок усе ще скаржиться, ймовірно, ви бачите періодичні втрати, реупорядкування або асиметричні шляхи, а не чисту блокування.

Рішення: Спустіться по стеку: лічильники інтерфейсів, стабільність ARP, стабільність MAC-таблиці і узгодженість VLAN-транків.

Це більше дюжини завдань. Використовуйте їх як воронку: починайте широко, потім звужуйте коло до одного лінка, що бреше щодо тегів.

Три короткі корпоративні історії (анонімізовані, правдоподібні, болючі)

Коротка історія 1: Відмова через хибне припущення

Середня SaaS-компанія мала «просту» мережу: два top-of-rack комутатори на ряд, аплінки до пари spine’ів і кілька VLAN.
Мережа збереження була VLAN 220, загальна мережа серверів — VLAN 120, і був VLAN управління, про який ніхто не хотів говорити.

Нова стійка з’явилася в роботі. Команда серверів надала хости з VLAN subinterfaces на Linux, бо «так працювала попередня стійка».
Вони тегували eth0.120 і eth0.220, ставили IP і продовжували роботу.

Тим часом мережева команда стандартизувала серверні порти як access-порти у VLAN 120 і тримала storage на окремому NIC.
Вони припустили, що нові сервери нетеговані. Ніхто не сказав, бо «це ж просто VLAN».

Результат не був чистим падінням. Частина трафіку працювала, бо upstream гіпервізор мав стару конфігурацію, що транкувала порти, і деякі сервери помилково підключилися до тих портів.
Інші сервери потрапили в строгі access-порти і фактично кричали теговані кадри в порожнечу.

Що зробило це привидною відмовою: моніторинг хоста опинився на «працюючому» порту. Помилки клієнтів були на «зламаних» портах.
Інцидент тривав стільки, щоб всім набридло, але недостатньо довго, щоб робити розгорнутий постмортем. До наступного разу.

Виправлення було принизливо базовим: узгодити контракт. Або зробити серверні порти транками з явним allowed VLAN list, або прибрати тегування на хостах.
Вони обрали транки з явними allowed VLAN, задокументованими по стойках. Наступне розгортання не вимагало телепатії.

Коротка історія 2: Оптимізація, що повернулась боком

Велика корпорація мала звичку «чистити VLAN-sprawl». Розумна ціль. VLAN накопичуються, як забуті S3 бакети.
Старший інженер вирішив звузити allowed VLANs транків, щоб зменшити широкомовний шум і зробити відмови менш руйнівними.

Він оновив allowed VLANs на кількох spine-to-leaf транках, видаливши кілька VLAN, які «ніби не використовувалися».
Перевірка використання базувалась на експорті CMDB і швидкому погляді на конфіги комутаторів. Було охайно, швидко і неправильно.

Один з видалених VLAN використовувався легасі-кластером пакетної обробки, що запускав важкі задачі лише у вихідні.
Протягом тижня він здавався бездіяльним. У суботу вранці кластер ожив, не зміг дістатися бази, почав повторювати спроби.
Повторні спроби перетворились на гуркіт стад. База зазнала шторму підключень. CPU підскочив. Затримки зросли. Всі звинувачували базу.

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

Урок не у «ніколи не чистити VLAN». Він у тому: не чистіть за паперами. Чистіть за спостережуваним трафіком і свідомим виведенням з експлуатації.
Робіть зміни відкатними, поетапними і вимірюйте. Оптимізація — податок, який платите пізніше, якщо не стежите зараз.

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

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

Під час апаратного оновлення ввели нову модель top-of-rack. Один з шаблонів за замовчуванням на новій лінійці комутаторів мав інший native VLAN,
ніж старий шаблон. Те саме вендор, різні дефолти. Класика.

Інженер розгортання все одно пройшов чеклист: після застосування шаблону він запустив валідаційний скрипт, що порівнював native VLAN транків
і allowed VLAN lists з контрактом. Він провалився відразу. Не в продакшені, а в staging.

Виправлення зайняло десять хвилин: оновити шаблон, щоб вимкнути використання native VLAN на транках (тегувати все), явно вказати ті самі allowed VLAN,
і перезапустити валідацію. Ніякого впливу на клієнтів. Жодних привидів.

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

Поширені помилки: симптом → корінь → виправлення

1) «Деякі хости в стійці не можуть дістатися шлюзу, інші можуть»

Корінь: Змішані access і trunk налаштування на серверних портах; хости неконсистентно тегують.

Виправлення: Стандартизувати: або хости нетеговані (access-порти), або хости тегують (trunk-порти). Оберіть один підхід для середовища і накладайте шаблони.

2) «Інтермітентні ARP-збої, записи neighbor стають INCOMPLETE»

Корінь: Невідповідність VLAN спричиняє ARP-запити/відповіді в різних VLAN, або нестабільність MAC-таблиці через витік/петлю.

Виправлення: Валідуйте контракт тегування хоп за хопом; перевірте MAC flaps на комутаторах; усуньте нетеговані транки або невідповідні native VLAN.

3) «Працюють лише великі передачі; маленькі пінги проходять»

Корінь: MTU-несумісність, підсилена оверхедом тегу VLAN або інкапсуляцією оверлею; PMTUD заблоковано; незгідне увімкнення jumbo.

Виправлення: Вирівняти MTU на хості, switchport, port-channel та оверлейних межах. Дозволити ICMP «fragmentation needed» де потрібно або клампити MSS.

4) «Попередження про MAC flapping на комутаторі»

Корінь: L2-петля, неправильно прокладені резервні лінки без коректного LACP, або витік VLAN, де той самий MAC з’являється в кількох місцях.

Виправлення: Перевірити стан spanning tree, LACP bundles і впевнитися, що VLAN випадково не мостяться між сегментами. Виправити кабелі та конфіг порт-channel.

5) «Фаєрвол нічого не бачить, а застосунки тайм­аути»

Корінь: Пакети ніколи не доходять до інтерфейсу/ VLAN фаєрвола, який ви очікуєте; вони приходять нетегованими або в іншому VLAN і відкидаються деінде.

Виправлення: Захопіть трафік на інтерфейсах фаєрвола з VLAN-усвідомленням; перевірте тегування switchport до фаєрвола; уникайте покладання на native VLAN для критичних зон.

6) «Після зміни один VLAN мертвий, але тільки в одному напрямку»

Корінь: Невідповідність allowed VLAN list на транку в багатохоповому шляху; асиметричні allowed VLAN або неконсистентне обрізання.

Виправлення: Порівняйте allowed VLAN list на обох кінцях кожного транку; використовуйте автоматизацію для виявлення дрейфу; етапуйте prune-зміни з перевіркою трафіку.

7) «VM на тому ж хості можуть спілкуватись, але не з іншими хостами»

Корінь: vSwitch/міст гіпервізора тегеє внутрішньо, але uplink налаштований як access (або вказаний неправильний trunk VLAN).

Виправлення: Зробіть фізичний uplink trunk, що несе VLAN VM; перевірте VLAN filtering на Linux bridge або VLAN ID portgroup на гіпервізорі.

8) «Резервування робить гірше»

Корінь: Члени LACP-бандлу не мають однакових VLAN-настроювань; або одна сторона LACP, інша — статичні/індивідуальні порти.

Виправлення: Налаштовуйте VLAN на port-channel, а не на окремих портах; перевірте стан LACP; переконайтесь, що обидві сторони погоджені щодо режиму і очікувань хешування.

Жарт №2: Native VLAN — як «шухляда для дрібниць»: зручно, поки вам не треба щось знайти, тоді вона стає місцем злочину.

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

Покроково: безпечно виправляємо поточний інцидент

1. Виберіть один відмовний потік (хост-джерело, хост/шлюз призначення, протокол/порт). Запишіть його.
2. Доведіть тегування на джерелі за допомогою ip -d link і tcpdump vlan.
3. Перевірте суміжний switchport (access vs trunk) і параметри VLAN (native VLAN, allowed VLANs).
4. Пройдіть шлях: для кожного транку перевірте, що VLAN дозволено і послідовно тегується.
5. Перевірте стабільність MAC: шукайте MAC flapping; якщо знайдено — зупиніться і шукайте петлі/місбандли до внесення змін у VLAN.
6. Виправте контракт на одній межі: оберіть «хост тегує» або «мережа тегує», а не обидва одночасно. Застосуйте найменшу зміну, що відновить консистентність.
7. Перевірте захопленням: побачте теговані кадри там, де очікуєте, і нетеговані лише там, де явно має бути.
8. Зафіксуйте зміну: оновіть шаблони й конфігураційний менеджмент, щоб дрейф не з’явився знову наступного тижня.
9. Постінцидентна перевірка: проведіть MTU-тести і спостереження ARP/ND стабільності як мінімум протягом одного інтервалу старіння MAC.

Чеклист: проектуємо VLAN так, щоб вони не переслідували вас

• Тегуйте все на транках. Якщо мусите використовувати native VLAN, робіть його невикористовуваним для користувацького трафіку і послідовним скрізь.
• Мінімізуйте L2 там, де можна. Маршрутизувати на ToR, якщо дизайн дозволяє; тримайте VLAN маленькими і цільовими.
• Явні allowed VLAN lists на транках — у парі з автоматизацією для виявлення дрейфу. Ручне prune — місце, де гарні наміри вмирають.
• Єдине джерело істини для власності й призначення VLAN. Якщо ніхто не володіє VLAN 317, рано чи пізно він заволодіє вами.
• Стандартизуйте підключення серверів. Вирішіть host-tagging vs access-порти; документуйте винятки як кримінал, що потребує паперів.
• Моніторте L2-сигнали: MAC flaps, STP-події, аномалії ARP/ND, і дропи інтерфейсів. Це сигналізація для проблем VLAN.

Чеклист: валідація перед зміною (перед дотиком до продакшену)

• Підтвердіть, що обидва кінці кожного транку погоджуються щодо: режиму транку, native VLAN (якщо є), allowed VLAN list.
• Підтвердіть консистентність LACP: той самий режим, ті самі member-порти, ті самі VLAN-настроювання на бандлі.
• Підтвердіть MTU: NIC хостів, switchports, port-channels і межі оверлею.
• Запустіть smoke test: ARP до шлюзу, ping з DF і дрібну транзакцію застосунку, якщо можливо.
• Майте rollback-план, що швидко відновить попередній allowed VLAN list або режим порту.

Операційний принцип, який варто запозичити

Ось парафраз ідеї, приписуваної Richard Cook (resilience engineering): складні системи вдаються, бо люди постійно адаптуються, щоб тримати їх у роботі.
Дрейф VLAN процвітає, коли система залежить від героїчних адаптацій замість явних контрактів.

Поширені питання

1) Що саме означає «привидна відмова» в термінах VLAN?

Відмова, коли зв’язок періодично або частково не працює, бо кадри іноді класифікують в неправильний VLAN по шляху.
Це не чистий розрив; це імовірнісна біль.

2) Чи native VLAN за своєю суттю поганий?

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

3) Чи може невідповідність VLAN спричинити односторонню доступність?

Так. Якщо вихідні кадри теговані правильно, а повернення навчані/форвардяться в інший VLAN (або приходять нетегованими і мапляться в інший VLAN),
ви отримуєте асиметричну досяжність: SYN виходить, SYN-ACK ніколи не повертається.

4) Чому ARP-проблеми з’являються першими?

ARP (і IPv6 ND) — широкомовні/мультікастні процедури і залежать від правильного L2-домену. Якщо VLAN-класифікація неправильна, розв’язування адрес ламається у спосіб, який TCP довго не приховає.
Ви побачите записи сусідів, що стають incomplete, або «зміни» MAC шлюзу.

5) Чи впливає VLAN-тегування на MTU?

VLAN-тег додає 4 байти. На правильно налаштованому обладнанні фізичний MTU враховує це. У реальному житті пристрої не завжди узгоджені.
Якщо ваш дизайн щільний (jumbos, оверлеї), ці 4 байти можуть штовхнути вас у втрати або фрагментацію, якщо не вирівняти MTU кінця в кінець.

6) Як обрати між host tagging і switch access-портами?

Якщо ви запускаєте гіпервізори або потребуєте кілька VLAN на одному NIC, host tagging (або тегування на гіпервізорі) часто практично — у парі з trunk-портами.
Якщо хочете простоти і менше рухомих частин, access-порти на кожен NIC/VLAN можуть бути безпечнішими. Неправильний вибір — змішувати обидва без документації.

7) Який найшвидший спосіб довести, що VLAN дозволено в тканині мережі?

З хоста: захопіть теговані кадри, що виходять з NIC, потім захопіть на суміжному комутаторі (SPAN/mirror), щоб побачити, чи ті теговані кадри приходять незмінними.
Якщо вони зникають або стають нетегованими — ви знайшли межу, що порушує контракт.

8) Чи може prune allowed VLAN викликати проблеми, навіть якщо «ніхто не використовує цей VLAN»?

Так, бо «ніхто не використовує» часто означає «ніхто не використовує зараз». Планові завдання, DR-тести, старі пристрої або HA-фейловери можуть активувати спляче VLAN.
Обрізуйте лише після перевіреного виведення з експлуатації й спостереження, а не тільки за документацією.

9) Як це стосується відмов зберігання?

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

10) Якщо я використовую VXLAN/EVPN, чи ще мають значення помилки VLAN?

Менше в деяких місцях, більше в інших. Оверлеї зменшують L2-розповсюдження, але на периферії (серверні порти, VTEP uplinks, handoff-сегменти) все одно є VLAN.
Некоректне тегування на краю все ще може створювати привидні відмови — тепер інкапсуляція робить симптоми важчими для розуміння.

Висновок: практичні наступні кроки

Привидні відмови не надприродні. Вони виникають, коли ваша мережа не може послідовно відповісти на просте питання: «У якому VLAN цей кадр?»
Неконсистентне тегування, невідповідні native VLAN і дрейф allowed VLAN списків перетворюють Ethernet на книгу вибору пригод,
де кінець завжди — інцидентний канал, повний скріншотів.

Наступні кроки, що справді дають результат:

1. Оберіть політику: тегуйте все на транках і вважайте нетеговане винятком.
2. Напишіть VLAN-контракт: для кожного VLAN визначте, де він існує, де тегується і хто ним володіє.
3. Автоматизуйте виявлення дрейфу: невідповідності native VLAN і allowed VLAN мають виявлятись до користувачів.
4. Додайте L2-сигнали в моніторинг: MAC flaps, STP-події, аномалії ARP/ND і дропи інтерфейсів.
5. Відпрацюйте план: відпрацюйте кроки швидкої діагностики в спокійний час, щоб виконувати їх під тиском.

Зробіть це, і наступного разу, коли хтось скаже «це інтермітентно», у вас буде короткий список доказів — не довгий список здогадок.