Мережі: проблеми MTU, які виглядають як «повільний інтернет» (виправити за 15 хвилин)

MTU простими словами (і чому воно вводить в оману)

MTU — це Maximum Transmission Unit: найбільший розмір пакета (у байтах), який лінк пропустить без фрагментації.
На типовій Ethernet-мережі це 1500 байт. Якщо ви використовуєте PPPoE, зазвичай це 1492. Якщо ви живете з jumbo frames, це може бути 9000.
Якщо ви інкапсулюєте всередині тунелю всередині оверлею, відніміть накладні заголовки, поки не повернетесь у реальність.

Пастка в тому, що TCP не надсилає «пакети» як такі. Він передає потік. ОС розбиває цей потік на сегменти, а мережа — на кадри.
Коли MTU неправильне, ви не отримуєте «помилку MTU». Ви бачите ретрансляції, зупинки,
асиметричні відмови та тайм‑аути, що схожі на затори. Іноді можна завантажити текст, але не зображення. Іноді сторінка логіну відкривається, але POST-запит зависає.
Іноді пошкоджена лише одна напрямок, бо лише один фаєрвол відкидає той ICMP-повідомлення, яке вам потрібно.

Чиста відмова MTU очевидна: великі пакети ніколи не проходять. Але в реальному житті відмови MTU часто перетворюються на
«PMTUD чорні діри», де мережа має повідомити відправника зменшити розмір пакета (через ICMP «Fragmentation Needed»), але якийсь пристрій блокує ці ICMP-повідомлення.
Відправник продовжує штовхати великі пакети, їх відкидають,
TCP повторює передачі, а ваш користувач продовжує казати «повільно».

Цитата, яку варто тримати в голові під час усунення несправностей: перефразована ідея — Richard Cook (дослідник з безпеки/операцій):
Системи зазвичай виглядають нормально, доки раптово не перестають, бо успіх ховає складність, яка робить можливим збій.
Проблеми MTU саме такого роду: усе здається в порядку, поки один розмір корисного навантаження не перетне невидиму межу.

Короткий жарт №1: баги MTU — ніби «тихо звільняються» пакети — приходять, роблять мінімум роботи, а потім зникають, коли справа стає серйозною.

Швидка діагностика (перший/другий/третій)

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

Перший: підтвердіть, що все залежить від розміру

• Чи працює дрібний трафік стабільно (DNS, невеликі HTTP‑відповіді, SSH‑банер), тоді як великі передачі зависають?
• Чи ping з DF (don’t fragment) падає при певних розмірах?
• Чи бачите ви TCP‑ретрансляції та «застряглі» з’єднання під час завантажень/відвантажень?

Другий: визначте сегмент шляху, який змінює MTU

• VPN, GRE, IPsec, WireGuard, оверлейні мережі, MPLS, PPPoE, cloud transit gateways, load balancers.
• Знайдіть, де відбувається інкапсуляція. Накладні заголовки зменшують ефективний MTU.
• Перевірте, чи фаєрвол не блокує ICMP типу 3 код 4 («fragmentation needed»). Це класика.

Третій: застосуйте найменш ризикове пом’якшення

• Clamp TCP MSS на краю (тимчасова пластирка, часто безпечна).
• Встановіть MTU інтерфейсу правильно на кінцях тунелю (постійне виправлення, якщо ви контролюєте обидві сторони).
• Дозвольте потрібні ICMP для PMTUD (постійне виправлення, але узгодьте з командами безпеки).

Мета не «ідеальний MTU». Мета — «припинити кровотечу не створюючи новий інцидент».

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

• 1500‑байтний MTU Ethernet став фактичним стандартом на ранніх етапах, частково через апаратні та пам’ятні компроміси в 1980–1990‑х.
• IPv4 дозволяє маршрутизаторам фрагментувати пакети (якщо DF не встановлено), але фрагментація має витрати по продуктивності та надійності, тому сучасні стеки намагаються уникати її.
• IPv6 маршрутизатори не фрагментують у транзиті; відправник має використовувати PMTUD. Через це ICMPv6 «Packet Too Big» має критичне значення.
• PPPoE зазвичай використовує MTU 1492 через накладні заголовки; ці «відсутні 8 байтів» можуть зламати шлях, якщо PMTUD заблоковано.
• Jumbo frames (часто MTU 9000) можуть зменшити навантаження на CPU і підвищити пропускну здатність у довірених LAN, але один не‑jumbo проміжний хоп може створити дивні часткові відмови.
• PMTUD чорні діри були широко задокументовані в 1990‑х та 2000‑х, коли фаєрволи почали блокувати ICMP без усвідомлення наслідків.
• TCP MSS — не те саме що MTU: MSS — це розмір корисного навантаження, MTU включає заголовки. Люди плутають їх і «правлять» неправильне число.
• Стек інкапсуляцій швидко додає накладні витрати: VXLAN/Geneve плюс IPsec плюс заголовки провайдера можуть урізати сотні байтів від ефективного MTU.
• Дата‑центри стандартизувалися на 1500 з причини: сумісність важливіша за теоретичну продуктивність. Більшість відмов народжуються, коли хтось каже «ми просто змінимо MTU».

Як виглядає біль MTU у продакшені

Класичні симптоми

• Деякі вебсайти завантажуються, інші зависають (часто під час TLS‑handshake або при великих відповідях).
• VPN підключається, але файлові шарі та великі API‑виклики зависають.
• SSH у інтерактиві працює, але scp повільний або заморожується.
• Вузли Kubernetes Ready, але завантаження деяких образів тайм‑аутиться.
• HTTP працює, HTTPS ненадійний (розміри TLS‑записів, більші handshake‑повідомлення або інший шлях через CDN).
• Тести пропускної здатності показують багато ретрансляцій; затримка виглядає нормальною.

Чому це вводить в оману

При проблемах MTU у вас може бути чудова затримка та гарна робота з дрібними пакетами. Моніторинг, який перевіряє «ping працює», покаже зелений.
Ваші синтетичні тести можуть звертатися до крихітної точки й називати шлях здоровим.
Тим часом реальні користувачі намагаються завантажити PDF або витягнути шар контейнера й отримують тайм‑аут.

Найшвидший шлях загубитися — трактувати це як загальну проблему «повільної мережі» й почати підлаштовувати TCP‑algorithms,
буфери або QoS. Проблеми MTU — не оптимізація пропускної здатності. Це проблема коректності.

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

Це виробничо‑дружні завдання, які можна виконати з Linux‑хоста. Використайте тестовий хост з кожного боку підозрюваного розриву (клієнт і сервер, або дві pod, або дві VM).
Мета — виміряти, а не гадати.

Завдання 1: Перевірте MTU інтерфейсу і знайдіть очевидні невідповідності

cr0x@server:~$ ip -d link show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Значення: eth0 має 1500, wg0 — 1420 (поширений вибір для WireGuard). Саме по собі це не помилка.

Рішення: Якщо ви бачите тунельний інтерфейс з MTU більшим, ніж може підтримувати underlay, це підозріло. Підтвердіть тестами DF ping наступним кроком.

Завдання 2: Підтвердьте PMTUD поведінку за допомогою DF ping (IPv4)

cr0x@server:~$ ping -M do -s 1472 -c 3 203.0.113.10
PING 203.0.113.10 (203.0.113.10) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1492
ping: local error: message too long, mtu=1492
ping: local error: message too long, mtu=1492

--- 203.0.113.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2044ms

Значення: Ваш хост вже знає, що вихідний MTU — 1492 на тому шляху/інтерфейсі. Він відмовився надсилати 1500‑байтні пакети.

Рішення: Якщо аплікація очікує 1500, а шлях має 1492, потрібен MSS clamp або правильний MTU на краях тунелю/PPPoE.

Завдання 3: Бінарний пошук найбільшого працюючого розміру пакета

cr0x@server:~$ for s in 1472 1464 1452 1440 1432; do echo "size=$s"; ping -M do -s $s -c 1 203.0.113.10 | tail -n 2; done
size=1472
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
size=1464
1 packets transmitted, 1 received, 0% packet loss, time 0ms
size=1452
1 packets transmitted, 1 received, 0% packet loss, time 0ms
size=1440
1 packets transmitted, 1 received, 0% packet loss, time 0ms
size=1432
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Значення: 1464 працює, 1472 не працює. Це вказує на ефективний MTU ≈ 1492 (бо 1464 + 28 байт заголовків ≈ 1492).

Рішення: Перестаньте сперечатися про теорію. Встановіть MTU/MSS відповідно до того, що реально працює.

Завдання 4: Перевірте route MTU / підказки PMTU cache

cr0x@server:~$ ip route get 203.0.113.10
203.0.113.10 via 198.51.100.1 dev ppp0 src 198.51.100.20 uid 1000
    cache mtu 1492

Значення: Linux має кешований PMTU 1492 для того призначення на ppp0.

Рішення: Якщо PMTU несподівано малий — шукайте, де відбувається інкапсуляція (PPPoE, VPN, оверлей). Якщо PMTU великий, але пакети все одно зависають, можливо ICMP блокується й кеш не оновлюється.

Завдання 5: Шукайте ретрансляції та «застої» на реальному з’єднанні

cr0x@server:~$ ss -ti dst 203.0.113.10:443
ESTAB 0 0 198.51.100.20:53124 203.0.113.10:443
	 cubic wscale:7,7 rto:204 rtt:38.5/4.2 ato:40 mss:1460 pmtu:1500 rcvmss:536 advmss:1460 cwnd:10 bytes_acked:1543 bytes_received:2010 segs_out:35 segs_in:33 retrans:7/18

Значення: Ретрансляції ненульові й зростають. pmtu:1500 може бути неправильним, якщо є чорна діра. rcvmss:536 також натякає на дивну поведінку шляху.

Рішення: Якщо ретрансляції зростають під час масових передач, а дрібний трафік OK — підозрюйте MTU/PMTUD. Перейдіть до пакетного захоплення або MSS clamp.

Завдання 6: Зачекайте ICMP «fragmentation needed» (або його відсутність)

cr0x@server:~$ sudo tcpdump -ni any '(icmp and (icmp[0]=3 and icmp[1]=4)) or (icmp6 and ip6[40]=2)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

Значення: Для IPv4 ви дивитесь ICMP тип 3 код 4. Для IPv6 — ICMPv6 тип 2 (Packet Too Big).

Рішення: Якщо ви відтворюєте проблему й ніде не бачите ICMP PTB/frag‑needed повідомлень, фаєрвол або middlebox може їх відкидати.
Якщо бачите — PMTUD працює і слід зосередитися на неправильному локальному MTU/MSS.

Завдання 7: Відтворіть за допомогою curl і слідкуйте за зависанням після «upload completely sent off»

cr0x@server:~$ curl -v --max-time 10 -o /dev/null https://203.0.113.10/large-object
*   Trying 203.0.113.10:443...
* Connected to 203.0.113.10 (203.0.113.10) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
> GET /large-object HTTP/1.1
> Host: 203.0.113.10
> User-Agent: curl/8.5.0
> Accept: */*
* Operation timed out after 10001 milliseconds with 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 10001 milliseconds with 0 bytes received

Значення: TCP‑підключення і TLS‑handshake можуть пройти, але потім шлях для запиту/відповіді зависає на більших пакетах або для певних розмірів записів.

Рішення: Підтвердіть DF ping і потім пом’якшіть (MSS clamp або правильний MTU). Не витрачайте годину на «оптимізацію TLS».

Завдання 8: Виміряйте реальну пропускну здатність і втрати за допомогою iperf3

cr0x@server:~$ iperf3 -c 203.0.113.10 -t 10 -i 1
Connecting to host 203.0.113.10, port 5201
[  5] local 198.51.100.20 port 45436 connected to 203.0.113.10 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  3.12 MBytes  26.2 Mbits/sec   28   61.5 KBytes
[  5]   1.00-2.00   sec  2.50 MBytes  21.0 Mbits/sec   31   52.3 KBytes
[  5]   2.00-3.00   sec  1.75 MBytes  14.7 Mbits/sec   44   43.1 KBytes
[  5]   3.00-4.00   sec  1.12 MBytes  9.40 Mbits/sec   56   32.8 KBytes
[  5]   4.00-5.00   sec  0.88 MBytes  7.38 Mbits/sec   61   26.9 KBytes
[  5]   0.00-10.00  sec  15.2 MBytes  12.8 Mbits/sec  472             sender
[  5]   0.00-10.00  sec  14.5 MBytes  12.1 Mbits/sec                  receiver

Значення: Ретрансляцій багато і cwnd колапсує. Це не норма для стабільного шляху.

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

Завдання 9: Перевірте NIC‑offloads, що можуть збивати пакетні захоплення

cr0x@server:~$ ethtool -k eth0 | egrep 'tso|gso|gro|lro'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off

Значення: Offloads увімкнені. Це нормально, але може змусити tcpdump показувати «великі» пакети, які фактично не відправляються по дроту.

Рішення: Не «виправляйте» MTU на підставі оманливого захоплення. Якщо вам потрібні коректні розміри пакетів для налагодження, тимчасово вимкніть offloads на тестовому хості.

Завдання 10: Тимчасово вимкніть offloads на тестовому хості (для ясності)

cr0x@server:~$ sudo ethtool -K eth0 tso off gso off gro off

Значення: Ядро більше не буде зливати/сегментувати так, щоб плутати інструменти захоплення.

Рішення: Робіть це тільки на тестовому хості або в контрольоване вікно. Offloads можуть бути критичними для продуктивності на завантажених хостах.

Завдання 11: Перевірте IPv6 PMTUD (ICMPv6 Packet Too Big) чи не блокується

cr0x@server:~$ ping6 -c 2 -s 1452 -M do 2001:db8::10
PING 2001:db8::10(2001:db8::10) 1452 data bytes
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280

--- 2001:db8::10 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1023ms

Значення: Щось на шляху (або локально) встановлює MTU 1280 (мінімум для IPv6). Це реальна річ, але й катастрофічно б’є по продуктивності, якщо несподівано.

Рішення: Якщо IPv6 PMTU несподівано знизився — знайдіть тунель/сегмент, який це спричиняє. Не вимикайте IPv6 просто так, якщо ви не фанат повторних інцидентів.

Завдання 12: Обмежте TCP MSS через iptables (швидке пом’якшення)

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Значення: Для форвардованих TCP‑з’єднань SYN‑пакети будуть переписані так, щоб сторони домовилися про MSS, що поміщається у виявлений PMTU.

Рішення: Застосовуйте це на краях (VPN‑шлюзи, роутери, фаєрволи), коли не можете швидко виправити блокування ICMP або невідповідність MTU. Потім заплануйте реальне виправлення.

Завдання 13: Обмежте TCP MSS через nftables (для сучасних систем)

cr0x@server:~$ sudo nft add table inet mangle
cr0x@server:~$ sudo nft 'add chain inet mangle forward { type filter hook forward priority mangle; policy accept; }'
cr0x@server:~$ sudo nft add rule inet mangle forward tcp flags syn tcp option maxseg size set rt mtu

Значення: Та сама ідея: підлаштувати MSS відповідно до MTU маршруту. Синтаксис залежить від дистрибутива/ядра; тестуйте обережно.

Рішення: Надавайте перевагу перевіреному правилу з рев’ю. Не експериментуйте з nftables у продакшені, якщо не хочете експрес‑інцидентів.

Завдання 14: Встановіть MTU на інтерфейсі (постійно, коли це правильно)

cr0x@server:~$ sudo ip link set dev wg0 mtu 1380
cr0x@server:~$ ip link show wg0 | head -n 1
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1380 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000

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

Рішення: Якщо ви контролюєте обидва кінця, це часто найчистіше виправлення. Перевірте DF ping через тунель і справжню передачу аплікації.

Завдання 15: Перевірте лічильники ядра на фрагментацію і проблеми зі збиранням

cr0x@server:~$ netstat -s | egrep -i 'fragment|reassembl'
    0 fragments received ok
    0 fragments created
    12 packets reassembled ok
    3 packet reassembly failures

Значення: Помилки збирання можуть вказувати на проблеми з фрагментацією шляху або втратою фрагментів.

Рішення: Фрагментація — запах проблеми. Уникайте її, встановивши правильний MTU/MSS. Якщо ви бачите помилки збирання в інцидент‑вікні, MTU — вагомий підозрюваний.

Завдання 16: Перевірте MTU наскрізь зсередини Kubernetes (реальність оверлея)

cr0x@server:~$ kubectl run -it --rm netdebug --image=busybox:1.36 -- sh
/ # ip link show eth0 | head -n 1
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default
/ # ping -M do -s 1422 -c 1 10.96.0.1
PING 10.96.0.1 (10.96.0.1): 1422 data bytes
1430 bytes from 10.96.0.1: seq=0 ttl=64 time=0.632 ms

--- 10.96.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss

Значення: Pod MTU — 1450 (поширено в VXLAN‑налаштуваннях). Ваша «звична 1500» всередині кластера вже не актуальна.

Рішення: Якщо поди говорять з зовнішніми сервісами через тунелі або шлюзи — врахуйте додаткові накладні витрати. Виправляйте в конфігурації CNI або ставте MSS clamp на шлюзі.

Шаблони виправлень, які працюють (і чому)

Шаблон 1: Повторно забезпечте роботу PMTUD (доросле рішення)

PMTUD існує для того, щоб кінцеві точки могли адаптуватися. Коли воно працює, ви отримуєте максимальні розміри пакетів без ручного налаштування.
Коли воно зламане, люди починають жорстко прописувати MTU по всіх пристроях, ніби це 1997 рік.

Типовий злам — фільтрація ICMP. Для IPv4 треба дозволити ICMP тип 3 код 4 назад до відправника.
Для IPv6 ICMPv6 Packet Too Big є обов’язковим для базової роботи. Блокування цього — не «безпека». Це самонашкодження.

Що робити: дозволити конкретні ICMP‑повідомлення, встановити розумні rate‑limits і логувати відкидання. Якщо ваше security‑плюг‑інструмент
вимагає тотального відкидання ICMP, погодьте виняток з доказами: пакет‑захопленнями, ретрансляціями й чітким тестом до/після.

Шаблон 2: Clamp TCP MSS на межах (практичне виправлення)

MSS clamping переписує TCP SYN, тож обидві сторони погоджуються на менший розмір сегмента. Це обхід PMTUD у випадках, коли PMTUD
ненадійне через middlebox’и, які ви не контролюєте (партнерська мережа, оператор, корпоративний фаєрвол).

Це також найшвидше «15‑хвилинне» виправлення, бо ви можете застосувати його на краю, не торкаючись усіх хостів.
Мінуси: допомагає тільки TCP, не UDP. Може також замаскувати реальну проблему настільки, що вона знову з’явиться після зміни топології.

Шаблон 3: Встановіть правильний MTU на тунелях та оверлеях (структурне виправлення)

Тунелі зменшують ефективний MTU, бо додають заголовки. Якщо ваш underlay 1500, а тунель додає 60 байт накладних витрат,
MTU тунелю має бути 1440 або менше, якщо ви хочете уникнути фрагментації/чорних дір.

Правильне значення залежить від типу інкапсуляції й опцій (ESP‑накладні IPsec змінюються; у WireGuard є типовий overhead; VXLAN додає свій).
Не запам’ятовуйте числа. Виміряйте DF ping через тунель, а потім оберіть значення з невеликим запасом.

Шаблон 4: Перестаньте ставити jumbo frames як рису характеру

Jumbo frames корисні в контрольованому L2‑домені: storage‑мережі, HPC, певні east‑west сценарії.
Але jumbo через змішану інфраструктуру — це коли мрії перетворюються на засідання Change Advisory Board.

Якщо ви ввімкнули MTU 9000 на деяких комутаторах і забули один hypervisor vSwitch або один інтерфейс фаєрвола, ви створили
режим відмови, який виглядатиме як «періодична повільність» вічно. Або робіть jumbo end‑to‑end у сегменті, або не робіть їх взагалі.

Короткий жарт №2: Якщо ви ввімкнули jumbo frames без плану end‑to‑end, ви не «оптимізували мережу», ви просто винайшли нове хобі для вашого on‑call.

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

Міні‑історія 1: Інцидент через неправильне припущення

Середня SaaS‑компанія мала гібрид: офісні користувачі на керованому ISP‑каналі, робочі навантаження в публічній хмарі.
Вони розгорнули новий «secure web gateway» appliance. План розгортання був простий: направити трафік корпорації через appliance,
перевірити веб‑браузинг, потім масштабувати.

На перший день служба підтримки отримала дивні тікети. Деякі співробітники писали «усе повільно».
Інші — «тільки завантаження не працює». Хтось казав, що Slack ок, але внутрішній CRM (за VPN) тайм‑аутиться під час логіну.
Графіки мережі виглядали нормально. CPU на gateway був у нормі. Вендор пропонував збільшити TCP‑буфери. Класика.

Неправильне припущення було тонким: команда вважала appliance простим L3/L4‑форвардером, тобто «MTU залишається 1500».
Насправді appliance встановлював IPsec‑тунель до cloud POP для інспекції. Це додавало накладні витрати. Appliance
ще приймав 1500‑байтні пакети на LAN‑боці, але не міг їх форвардити без фрагментації на тунельному боці.
І шлях тунелю мав ICMP frag‑needed, відфільтрований на провайдерському краю.

Виправлення не було героїчним. Вони відтворили зависання DF ping, побачили ефективний MTU ≈ 1410 по новому шляху,
і застосували MSS clamp на gateway для вихідних TCP. Відразу CRM‑логіни перестали тайм‑аутитись. Потім запланували реальне виправлення:
налаштувати MTU тунелю й координувати дозволи ICMP з провайдером.

Урок: «Ethernet = 1500» — не факт; це значення за замовчуванням. Як тільки ви тунелюєте, інкапсулюєте або проходите через кероване security‑обладнання,
MTU стає параметром проєктування, а не приміткою.

Міні‑історія 2: Оптимізація, яка обернулася проблемою

Команда платформи даних хотіла підвищити пропускну здатність реплікації між двома дата‑центрами. Вони штовхали великі об’єкти і бачили навантаження на CPU
на хостах під час піку. Хтось запропонував jumbo frames: підняти MTU до 9000 на storage VLAN, зменшити накладні витрати на пакет — перемога.

Зміни зробили на ToR‑комутаторах і storage‑серверах. Початкові тести на кількох хостах виглядали чудово. Пропускна здатність зросла.
CPU знизився. Вони тихо святкували, бо голосні святкування дратують богів мережі.

Через два тижні інша команда перемістила hypervisor‑кластер у ту ж VLAN. Його vSwitch порт‑група лишилась на MTU 1500.
Нічого не вибухнуло відразу. Замість цього з’явився безлад: деякі VM могли монтувати storage, але періодично зависали під час великих читань.
Резервні копії почали тайм‑аутитись. Деякі NFS‑клієнти зависали при переліку директорій, що містили великі мета‑дані.

Оскільки багато дрібних пакетів все ще працювали, люди бігали за фантомними проблемами: «настройка NFS», «ZFS arc», «ESXi bug», «можливо масив переповнений».
Це зайняло час, поки простий DF ping з VM не виявив правду: VM не могла пройти пакети більші за 1500, а storage‑сервери вільно відправляли jumbo.
Десь посередині відбувалась фрагментація або падіння залежно від шляху і поведінки offload.

Виправлення було нудним: або зробити jumbo справді end‑to‑end (комутатори, hypervisor, vSwitch, NIC, storage),
або повернути VLAN до 1500 і прийняти трохи більшу завантаженість CPU. Вони обрали поділ: виділений ізольований jumbo‑сегмент для підтримуваних хостів
та окремий стандартний MTU‑сегмент для змішаної інфраструктури.

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

Фінтех мала десятки site‑to‑site VPN для партнерів. Вони вже попалилися на PMTUD чорних дірах, тож мали політику:
кожен новий тунель має супроводжуватися документованим тестом ефективного MTU і явним правилом MSS clamp на VPN‑краю, валідованим прогоном аплікації.
Не «ми думаємо, що все ок». Докази.

Одної п’ятниці великий партнер змінив модель фаєрвола. Без повідомлення. Раптом передачі файлів розрахунків почали періодично падати.
Партнер наполягав, що нічого не міняв «у VPN». Їхній моніторинг казав, що тунель ап. Всі були технічно праві і операційно марні.

У фінтех‑команди було дві переваги. По‑перше, у них вже був MSS clamp на своїй стороні, тому більшість TCP‑трафіку продовжувала працювати.
По‑друге, був стандартний рукбук: DF ping тести в обидва боки, tcpdump для ICMP і швидка перевірка переговореного MSS на тестовій TCP‑сесії.
За годину вони мали докази, що ICMP frag‑needed більше не повертається з боку партнера.

Не потрібно було проектувати мережу заново під час інциденту. Тимчасовий захист уже був на місці. Вони трохи посилили MSS clamp
(за виміряним ефективним MTU), відновили надійність передач файлів і відправили партнеру короткий звіт з пакет‑захопленнями.
Партнер згодом виправив політику фаєрвола, дозволивши потрібний ICMP, і фінтех відкотив зайву консервативність.

Урок: нудні контролі — документовані MTU‑тести, дефолтний MSS clamp на VPN‑краях і «задані» відомі гарні сценарії — перетворюють загадкові відмови на рутинне обслуговування.

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

1) «Деякі сайти завантажуються, інші зависають» → PMTUD чорна діра → дозволити ICMP / clamp MSS

Симптом: Нестабільний веб‑браузинг; великі сторінки зависають; дрібні працюють.
Корінна причина: Path MTU менший, ніж передбачалося, і ICMP frag‑needed / packet‑too‑big блокується.
Виправлення: Дозвольте конкретні ICMP‑повідомлення на фаєрволах; як швидке пом’якшення — clamp TCP MSS на egress‑шлюзі.

2) «VPN підключений, але передачі файлів зависають» → накладні витрати тунелю не враховано → зменшити MTU тунелю

Симптом: Малі pings і RDP/SSH працюють; SMB/NFS/HTTPS‑завантаження фризять.
Корінна причина: IPsec/WireGuard/GRE накладні витрати знижують ефективний MTU; кінці все ще штовхають пакети близько до 1500.
Виправлення: Встановіть MTU тунелю на виміряне безпечне значення; clamp MSS на VPN‑шлюзі.

3) «Kubernetes image pulls тайм‑аутяться» → MTU оверлея завелике → виправити CNI MTU і узгодженість MTU на вузлах

Симптом: Pod може вирішувати DNS і звертатись до дрібних endpoint’ів, але завантаження великих шарів падає.
Корінна причина: CNI overlay MTU не узгоджений з underlay або різні MTU на вузлах.
Виправлення: Налаштуйте MTU CNI правильно (наприклад, 1450/1440 залежно від інкапсуляції); забезпечте відповідність вузлів і vSwitch.

4) «Jumbo frames увімкнені, випадкові фризи» → не end‑to‑end jumbo → або зробити універсальним, або відкотити

Симптом: Лише деякі хости/VM мають проблеми; часто під час великих передач; моніторинг показує «ап».
Корінна причина: Один хоп все ще 1500 (vSwitch, фаєрвол, NIC, проміжний комутатор).
Виправлення: Перевірте MTU на кожному хопі; якщо не можете гарантувати — залиште сегмент на 1500.

5) «Пакетні захоплення показують величезні кадри» → артефакти offload → вимкніть offloads для налагодження

Симптом: tcpdump показує гігантські пакети, яких не повинно бути; висновки стають дивними.
Корінна причина: TSO/GSO/GRO роблять захоплення на хості схожими на пере‑великі пакети.
Виправлення: Тимчасово вимкніть offloads на тестовому хості або захоплюйте на комутаторі/порті mirror.

6) «UDP‑аплікація ламається; TCP після MSS clamp ок» → clamp допомагає лише TCP → настройте аплікацію або зменшіть MTU

Симптом: VoIP, ігри або власний UDP‑протокол все ще падає, тоді як веб‑аплікації відновились.
Корінна причина: MSS clamp не застосовується до UDP; UDP‑датаграми можуть перевищувати path MTU і відкидатися.
Виправлення: Зменшіть розмір UDP‑payload в аплікації, обережно увімкніть фрагментацію (рідко ідеально) або знизьте MTU на інтерфейсі/тунелі.

7) «IPv6 ненадійний; IPv4 ок» → ICMPv6 PTB блокується → дозволити ICMPv6 правильно

Симптом: Dual‑stack хости показують періодичні зависання через IPv6; IPv4 працює.
Корінна причина: ICMPv6 Packet Too Big блокується; IPv6 не може спиратися на фрагментацію маршрутизаторами.
Виправлення: Дозвольте потрібні типи ICMPv6; перевірте ping6 DF‑тести і tcpdump.

Контрольні списки / покроковий план

15‑хвилинний план «припинити кровотечу»

1. Доведіть залежність від розміру: виконайте DF pings з наростаючими розмірами до місця, що падає (Завдання 2–3).
2. Перевірте MTU інтерфейсів: underlay і тунельні інтерфейси (Завдання 1).
3. Перевірте route PMTU: ip route get для підказки (Завдання 4).
4. Підтвердіть ретрансляції: ss -ti на активному потоці (Завдання 5) і за бажанням iperf3 (Завдання 8).
5. Захопіть ICMP PTB/frag‑needed: підтвердіть, чи існують PMTUD‑повідомлення чи зникають (Завдання 6).
6. Швидке пом’якшення: clamp MSS на краю (Завдання 12 або 13).
7. Перевірте реальним трафіком: curl великий об’єкт, scp файл, витягніть образ контейнера (Завдання 7 + ваш робочий кейс).
8. Запишіть виміряний працюючий MTU: не покладайтеся на пам’ять; ваше майбутнє «ви» вже втомлене.

План постійного виправлення (щоб запобігти новим інцидентам)

1. Змапіть інкапсуляції: перелік кожного тунелю/оверлея та його накладних витрат (VPN, VXLAN, Geneve, GRE, IP‑in‑IP).
2. Встановіть MTU там, де потрібно: тунельні інтерфейси і CNI на значення, що поміщаються в underlay з запасом (Завдання 14).
3. Відновіть PMTUD‑сигнали: налаштуйте правила фаєрвола, щоб дозволити ICMP тип 3/4 (IPv4) і ICMPv6 PTB (IPv6).
4. Уніфікуйте MSS clamp на краях: тримайте його як defense‑in‑depth для партнерських мереж, які ви не контролюєте.
5. Додайте синтетичну перевірку, що передає реальні байти: не лише ping; щось, що ламається, коли MTU ламається.
6. Документуйте «відомо добрий» MTU для кожного сегмента: вказуйте власника і процес змін.

Чого уникати під час інциденту

• Не «підвищуйте MTU для продуктивності» у випадку уповільнення. Так ви перетворите частковий інцидент на повний.
• Не відключайте ICMP загалом. Якщо фільтруєте — робіть це цілеспрямовано й дозволяйте PMTUD‑критичні повідомлення.
• Не вважайте один успішний ping доказом, що шлях здоровий. Помилки MTU люблять ваш примітивний моніторинг.

FAQ

1) У чому різниця між MTU і MSS?

MTU — це максимальний розмір IP‑пакета на лінку. MSS (Maximum Segment Size) — це максимальний розмір TCP‑корисного навантаження.
MSS приблизно дорівнює MTU мінус IP+TCP‑заголовки. Виправлення MTU вирішує все; clamp MSS вирішує лише TCP.

2) Чому невідповідність MTU виглядає як «повільний інтернет», а не як відмова?

Бо лише пакети певного розміру падають. Дрібні запити, ACK, DNS і деякі елементи сторінки працюють.
Великі відповіді, завантаження або окремі протокольні повідомлення зависають і повторюються. Люди інтерпретують «повторні спроби» як «повільно».

3) Чому блокування ICMP — проблема? Хіба ICMP не небезпечний?

Проблема — тотальне блокування. PMTUD покладається на ICMP‑помилки, щоб інформувати відправників про MTU‑обмеження.
Для IPv6 ICMPv6 Packet Too Big є критичною. Ви можете rate‑limit і фільтрувати певні типи, але «ніякого ICMP» ламає реальний трафік неочевидно.

4) Як обрати правильний MTU для VPN‑тунелю?

Вимірюйте. Почніть з underlay MTU (часто 1500), відніміть накладні витрати інкапсуляції, потім валідуйте DF ping через тунель.
Додайте запас, якщо шлях проходить через невідоме провайдерське устаткування. Якщо не можете надійно виміряти — clamp MSS на краю.

5) Чи знижує продуктивність MSS clamp?

Може трохи збільшити CPU і кількість пакетів, бо надсилаються дрібніші сегменти. Але зазвичай це покращує реальний throughput у порівнянні з чорними дірами,
де ви постійно ретранслюєте великі сегменти. Думайте: «менш елегантно, але більш функціонально».

6) Чи можуть проблеми MTU торкатися лише одного напрямку?

Так. Одна сторона може вміти надіслати ICMP PTB назад, інша — ні. Або лише один напрямок проходить через тунель.
Асиметрія поширена в корпоративних мережах з кількома виходами та «допоміжними» security‑пристроями.

7) Чому IPv6 іноді ламається, а IPv4 працює?

IPv6 покладається на PMTUD, бо маршрутизатори не фрагментують пакети в транзиті. Якщо ICMPv6 PTB блокується, IPv6‑потоки зависають
на більших пакетах. IPv4 може «волочитися» завдяки фрагментації на деяких шляхах, маскуючи проблему.

8) Чи варто використовувати jumbo frames?

Вони виправдані в строго контрольованих сегментах, де кожен хоп перевірено (storage‑мережі, певні east‑west домени).
Вони не варто використання через різнорідну інфраструктуру або партнерські мережі. Якщо ви не можете гарантувати end‑to‑end MTU — залишайтеся на 1500.

9) Як тестувати MTU, не ламуючи продакшен?

Використовуйте DF ping до відомої цілі, запускайте off‑peak і не міняйте MTU на завантажених інтерфейсах необачно.
Для пакетних захоплень вимикайте offloads тільки на тестовому хості. В якості зворотного заходу використовуйте MSS clamp, який легко відкотити.

10) Який найшвидший «маркер», що це MTU, а не затори?

DF ping, який ламається при сталому порозі розміру, плюс TCP‑ретрансляції під час великих передач, тоді як дрібні запити в нормі.
Затори рідко створюють різкий розмірний поріг. Проблеми MTU — роблять.

Висновок: наступні кроки, які можна зробити сьогодні

Інциденти MTU не афішують себе. Вони переодягаються в «мережа повільна» і марнують вам післяобідній час.
Виправлення рідко складне, але точне: виміряйте реальний працюючий розмір пакета, знайдіть, де шлях звузився,
і або відновіть PMTUD, або clamp MSS, поки не зможете зробити реальне виправлення.

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

• Додайте крок у рукбук: DF ping тест + ss -ti перевірка ретрансляцій перед будь‑яким «тюнінгом продуктивності».
• Уніфікуйте MSS clamp на VPN/edge шлюзах як страховку для партнерських мереж.
• Аудитуйте правила фаєрвола на предмет ICMP frag‑needed (IPv4) і Packet Too Big (IPv6). Дозвольте їх з розумними rate‑limits і логуванням.
• Документуйте MTU для кожного сегмента (underlay, тунелі, оверлеї). Ставте це як залежність SLO, а не як дрібницю.

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