Ubuntu 24.04: Джамбо-фрейми ламають «тільки деякий» трафік — як безпечно протестувати та виправити MTU

October 28, 2025 • February 3, 2026 • Читання: 6 хв • Views: 8

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

Ви піднімаєте MTU до 9000, бо сховище «повільне», і раптом світ стає дивним: SSH працює, DNS відповідає, але «деякі» HTTPS-сайти зависають,
певні API-запити застрягають назавжди, а ваш трафік Ceph або NFS перетворюється на театралізовану постановку Waiting for ACK.

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

Чому джамбо-фрейми ламають «тільки деякий» трафік

«Тільки деякий трафік» ламається — це не парадокс. Так відбувається, коли мережа пропускає малі фрейми (наприклад TCP ACK, SYN, DNS-пакети, невеликі HTTP
запити), але відкидає або загублює більші фрейми (наприклад TLS-записи, gRPC-відповіді, читання SMB, реплікацію сховища, payload контейнерних оверлеїв).

Кореневий шаблон зазвичай виглядає як один із цих:

Розбіжність MTU між інтерфейсами в межах одного L2-домену (один хоп застряг на 1500, інші встановлені на 9000). Результат: великі фрейми
відкидаються на тому хопі. Малі фрейми виживають. Отримуєте «працює для мене» трафік… поки payload не стане великим.
Пошкоджений Path MTU Discovery (PMTUD): десь відкидають ICMP-повідомлення «потрібна фрагментація», тож кінці не дізнаються справжній MTU.
TCP продовжує штовхати великі сегменти, які гинуть. З’єднання не завжди падає одразу; воно зависає. Ось чому ця помилка здається привидом.
Тунелі/оверлеї зменшують ефективний MTU (VXLAN, GRE, WireGuard, IPsec, cloud VPN). Ваш NIC може бути 9000, але тунель має накладні витрати.
Якщо ви не зменшите MTU відповідно, ви просто створили шредер для пакетів.
Взаємодія з offload (TSO/GSO/GRO/LRO) може приховувати поведінку фрагментації та робити захоплення пакетів оманливими. Ядро може «вдавати», що
відправило великі пакети, тоді як NIC фактично їх сегментує — поки шлях цього не дозволяє.
Політичні пристрої (файрволи, балансувальники навантаження, NAT-шлюзи), які неправильно обробляють ICMP, некоректно обрізають MSS, або
примусово встановлюють несподіваний MTU лише в одному напрямку. Асиметричні шляхи — місце, де прості істини вмирають.

Практичний висновок: джамбо-фрейми — це не одиночний параметр; це контракт end-to-end. Якщо будь-який хоп незгоден, покарані будуть ті пакети, що перевищують
найменший MTU. Все інше працює й вам брешуть монітори.

Жарт №1: баги MTU — як офісні мікрохвильовки — гарні для дріб’язку, але поклади щось велике й раптом дим та звинувачення.

Факти та історичний контекст (що пояснює біль)

Ethernet «1500 MTU» — це конвенція, а не фізика. Вона стала дефолтною частково тому, що збалансовувала ефективність та обмеження буферів у ранньому обладнанні.
«Джамбо-фрейми» ніколи не мали одного універсального розміру. 9000 — поширений, але 9216 і 9600 теж з’являються, бо вендори хотіли запасу для VLAN і внутрішнього фреймінгу.
PMTUD покладається на ICMP, який у корпоративних мережах люблять блокувати. Це повторюваний режим відмови з 1990-х і досі отримує нагороди за «найбільш уникальний простий збій».
RFC 4821 (Packetization Layer PMTUD) існує, бо класичний PMTUD був крихким, коли ICMP фільтрується; багато стеків лише частково реалізували «більш стійкий» підхід.
VLAN-тегування зменшує payload MTU, якщо ви не врахували це. Один 802.1Q тег додає 4 байти; QinQ додає 8. Деякі свічі компенсують; деякі — ні.
VXLAN та подібні технології зробили MTU-математику операційною. Оверлейні мережі перенесли MTU із «фічі свічу» у «кожен вузол має погодитись», особливо в Kubernetes та мультиорендних середовищах.
Джамбо-фрейми допомагають здебільшого з ефективністю CPU, а не з сирою лінійною швидкістю. Менше пакетів з тими ж байтами означає менше переривань і накладних витрат на пакет — корисно при високій пропускній здатності.
Мережі сховищ рано прийняли джамбо-фрейми (iSCSI, NFS, Ceph replication), оскільки вони переміщують великі послідовні payload-и і виграють від меншої кількості пакетів.

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

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

Спочатку: підтвердіть, що це MTU, а не «те, що додаток»

Запустіть DF-пінг від клієнта до сервера з payload-розміром, що має проходити при 1500 і впасти при джамбо (деталі в розділі завдань). Якщо 1472 працює, а ~8972 ні, вітаємо: це MTU.
Якщо малі запити працюють, але великі завантаження зависають, протестуйте з curl --http1.1 і відомою великою відповіддю. Застої під час передачі плюс провал DF-пінгу — класика.

По-друге: знайдіть найменший hop MTU на реальному шляху

Перевірте MTU на NIC хоста, bond, VLAN-підінтерфейсі, bridge та кінцях тунелів. Перемагає найменший — подобається вам чи ні.
Підтвердіть, що профіль switchport дійсно дозволяє джамбо. Не довіряйте «ми налаштували це минулого року». Це речення закінчувало кар’єри.

По-третє: перевірте, чи працює PMTUD

Шукайте ICMP «frag needed», що повертаються, коли ви надсилаєте DF-пакети занадто великі. Якщо їх немає, щось їх відкидає.
Тимчасово обріжте TCP MSS на межах (файрвол, VPN, тунель) як пом’якшення, а потім виправте реальне вирівнювання MTU.

По-четверте: перевірте оверлеї та offload

У Kubernetes/VXLAN встановіть MTU для pod нижче, ніж MTU вузла, з урахуванням накладних витрат інкапсуляції.
Тимчасово вимкніть TSO/GSO для налагодження, якщо захоплення пакетів плутає, потім знову увімкніть для продуктивності, коли ви зрозумієте шлях.

Практична модель MTU (шари, накладні витрати і де це йде не так)

MTU — це максимальний розмір L3 payload, який ваш інтерфейс нестиме без фрагментації. В Ethernet люди звично кажуть «MTU 1500», маючи на увазі
1500 байт IP-пейлоаду всередині Ethernet-фрейму. Сам Ethernet-фрейм більший (заголовки, FCS, преамбула), але налаштування MTU в Linux зазвичай стосується саме L3.

Найкорисніше пам’ятати: MTU задається на кожному хопі і на кожному інтерфейсі. Ви можете мати:

NIC MTU = 9000
Bond MTU = 9000
VLAN-підінтерфейс MTU = 9000
Linux bridge MTU = 1500 (ой)
VXLAN device MTU = 1450 (ймовірно правильно для underlay 1500)

І потім всі сперечаються про «той MTU», ніби він один. Його немає. Є ланцюжок, і найслабша ланка задає ефективний MTU.

Чому TCP «нібито працює», навіть коли MTU зламана

TCP може уникати фрагментації, вибираючи менші сегменти. Воно вчиться, який розмір безпечно відправляти через PMTUD: надсилає пакети з DF (don’t fragment),
і якщо хоп не може їх перенести, той хоп повертає ICMP «потрібна фрагментація» з MTU наступного хопу. Тоді TCP зменшує свій сегмент.

Коли ICMP блокується, TCP не отримує повідомлення. Воно продовжує штовхати великі сегменти, які відкидаються. Відбуваються повтори. Включається backoff. Додатки тайм-аутять.
Тим часом малі пакети (ACK, keepalive, малі запити) все ще тече, що робить усе «в цілому гаразд» з базових моніторів.

Ось чому баги MTU проявляються як:

Переривчасті зависання (не жорсткі відмови)
Різкі стрибки латентності у довгому хвості
Працює на одному мережевому шляху, але не на іншому (асиметрична маршрутизація, різна політика файрволу)
«Ламається лише коли ми завантажуємо/відвантажуємо щось велике»

Накладні витрати оверлею: ваш прихований MTU-податок

Інкапсуляція додає заголовки. Ці байти повинні вміститися під підкладним MTU. Якщо ваш underlay 1500 і ви використовуєте VXLAN, ефективний payload MTU
зазвичай близько 1450 (залежить від точних заголовків). Якщо ви встановите оверлей на 1500 у будь-якому випадку, ви просите underlay нести >1500, що означає
або фрагментацію (погано), або відкидання (гірше).

Джамбо-фрейми також можуть допомагати оверлеям, але лише якщо весь underlay їх підтримує. Інакше потрібно зменшити MTU на оверлеї та/або обрізати MSS.

Одна цитата, щоб тримати її на стіні поруч із календарем змін: Надія — не стратегія. — Gene Kranz

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

Це завдання, які я реально запускаю, коли «деякий трафік» ламається після зміни MTU на Ubuntu 24.04. Кожне завдання включає: команду, що означає вивід,
і рішення, яке прийняти.

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

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> mtu 65536
enp3s0           UP             3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000
bond0            UP             3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000
br-storage       UP             7a:11:22:33:44:55 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

Значення: Міст має MTU 1500, тоді як усе інше — 9000. Це класичний частковий збій: трафік, що проходить через міст, змушений
опуститись до 1500 або відкинутий, якщо встановлено DF.

Рішення: Вирівняти MTU по всьому ланцюгу (NIC → bond → VLAN → bridge → veth/tap) або свідомо встановити все на найменше, що ви можете підтримувати end-to-end.

Завдання 2: Підтвердити дефолтний маршрут і реальний egress інтерфейс (щоб не дебажити не той шлях)

cr0x@server:~$ ip route get 10.50.12.34
10.50.12.34 dev bond0 src 10.50.12.10 uid 1000
    cache

Значення: Трафік до цього призначення виходить через bond0. Якщо ви дивилися на налаштування enp3s0, ви дебажите фанфікшн.

Рішення: Зосередьте перевірки MTU і захоплення пакетів на фактичному egress інтерфейсі(ах) і зворотному шляху від віддаленого вузла.

Завдання 3: Тест L3 MTU до пира з DF ping (IPv4)

cr0x@server:~$ ping -M do -s 1472 -c 2 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 1472(1500) bytes of data.
1480 bytes from 10.50.12.34: icmp_seq=1 ttl=63 time=0.412 ms
1480 bytes from 10.50.12.34: icmp_seq=2 ttl=63 time=0.401 ms

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

Значення: IP-пакети 1500 байт працюють. Це не доводить, що джамбо працює; це лише підтверджує, що базовий Ethernet не зламаний.

Рішення: Тепер протестуйте джамбо-розмір пакета, який має пройти, якщо MTU 9000 справді end-to-end.

Завдання 4: Тест джамбо MTU з DF ping (IPv4) і подивіться, як він чисто падає

cr0x@server:~$ ping -M do -s 8972 -c 2 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 8972(9000) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1018ms

Значення: Локальний стек вважає вихідний інтерфейс MTU=1500 для цього маршруту, незважаючи на те, що ви думали встановили. Це поки що не проблема шляху; це локальна конфігурація.

Рішення: Знайдіть, який пристрій у ланцюгу egress має MTU 1500 (часто це міст, VLAN, VRF або тунельний пристрій).

Завдання 5: Якщо він падає без локальної помилки — у вас path blackhole (PMTUD або проміжний хоп)

cr0x@server:~$ ping -M do -s 8972 -c 2 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 8972(9000) bytes of data.

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1013ms

Значення: Хост готовий відправляти 9000, але ніхто не відповідає. Зазвичай це означає, що якийсь хоп відкинув великий фрейм. Якщо ICMP «frag needed»
не повертається, PMTUD не може виправити це.

Рішення: Захопіть трафік і шукайте ICMP-помилки; якщо їх немає, виправте фільтрацію ICMP або обріжте MSS як пом’якшення.

Завдання 6: Тест поведінки IPv6 MTU (воно відрізняється; фрагментація лише на кінці)

cr0x@server:~$ ping -6 -M do -s 1452 -c 2 2001:db8:10::34
PING 2001:db8:10::34(2001:db8:10::34) 1452 data bytes
1460 bytes from 2001:db8:10::34: icmp_seq=1 ttl=63 time=0.588 ms
1460 bytes from 2001:db8:10::34: icmp_seq=2 ttl=63 time=0.570 ms

--- 2001:db8:10::34 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Значення: IPv6-шлях тут підтримує принаймні ~1500-байтні пакети. В IPv6 маршрутизатори не фрагментують; вони надсилають ICMPv6 «Packet Too Big».
Якщо це блокується, IPv6 швидко стає крихким.

Рішення: Переконайтеся, що ICMPv6 дозволений end-to-end. Блокування його ламає реальний трафік, а не лише «ping».

Завдання 7: Перевірити TCP MSS у живих сесіях (виявити обрізання або його відсутність)

cr0x@server:~$ sudo ss -ti dst 10.50.12.34 | head -n 20
ESTAB 0 0 10.50.12.10:44218 10.50.12.34:443
	 cubic wscale:7,7 rto:204 rtt:1.21/0.12 ato:40 mss:8960 pmtu:9000 rcvmss:536 advmss:8960 cwnd:10 bytes_acked:12983 bytes_received:44112 segs_out:112 segs_in:98 data_segs_out:64 data_segs_in:71

Значення: Цей потік вважає, що PMTU = 9000 і MSS = 8960. Якщо шлях фактично не може нести 9000, це рецепт для зависань.

Рішення: Або зробіть шлях справжнім 9000 end-to-end, або обріжте MSS до безпечного значення на межі, де MTU менший.

Завдання 8: Дивіться на PMTUD ICMP-повідомлення з tcpdump

cr0x@server:~$ sudo tcpdump -ni bond0 'icmp and (icmp[0]=3 and icmp[1]=4)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:22:31.201983 IP 10.50.12.1 > 10.50.12.10: ICMP 10.50.12.1 unreachable - need to frag (mtu 1500), length 556

Значення: Мережа каже вам, що хоп MTU = 1500. PMTUD працює, але ваші кінці все ще можуть поводитися неправильно, якщо політики відкидають деякі
ICMP або якщо тільки на деяких шляхах повертається помилка.

Рішення: Виправте невідповідність: або зменшіть MTU/MSS до 1500-безпечних значень для цього маршруту, або оновіть шлях до джамбо послідовно.

Завдання 9: Перевірити, чи ICMP фільтрується локально (правила файрволу)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state established,related accept
		iif "lo" accept
		ip protocol icmp accept
		ip6 nexthdr icmpv6 accept
		tcp dport { 22, 443 } accept
	}
}

Значення: ICMP/ICMPv6 дозволені. Це добре. Якщо ви не бачите таких дозволів, PMTUD може зазнати невдачі навіть якщо мережа надсилає правильні повідомлення.

Рішення: Дозвольте ICMP «frag needed»/«packet too big» та суміжні повідомлення. Не «захищайте» мережу, руйнуючи її роботу.

Завдання 10: Перевірити NIC offload, що може плутати розслідування (не завжди корінь проблеми)

cr0x@server:~$ sudo ethtool -k enp3s0 | egrep 'tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Значення: Offload ввімкнено. Захоплення пакетів на хості може показувати великі «супер-пакети», що ніколи не існують у дроті.

Рішення: Якщо налагодження незрозуміле, тимчасово відключіть TSO/GSO/GRO на тестовому вузлі, перевірте поведінку, потім відновіть. Не залишайте продуктивність на підлозі постійно.

Завдання 11: Тимчасово вимкнути TSO/GSO/GRO (діагностичний крок)

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

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

Рішення: Повторно протестуйте DF-пінги та реальний додаток. Якщо симптоми сильно зміняться, врахуйте offload у вашому фіксі, потім знову увімкніть offload для продуктивності.

Завдання 12: Перевірити MTU bridge та його учасників (поширений «прихований 1500» винуватець)

cr0x@server:~$ ip -d link show br-storage
7: br-storage: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 7a:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 9000 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

Значення: MTU мосту явно 1500, хоча він міг би бути до 9000. Цей міст обмежить трафік, що через нього проходить.

Рішення: Встановіть MTU мосту відповідно до underlay, якщо всі підключені сегменти підтримують джамбо; інакше залиште 1500 і прийміть цю реальність.

Завдання 13: Підтвердити вирівняність VLAN інтерфейсів (VLAN — місце, куди йдуть припущення)

cr0x@server:~$ ip -d link show bond0.120
12: bond0.120@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff promiscuity 0
    vlan protocol 802.1Q id 120 <REORDER_HDR>

Значення: VLAN-пристрій має MTU 9000. Якби він був 1500, тоді як батько 9000, ви б отримували маршрутно-специфічні відмови і дивну асиметрію.

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

Завдання 14: Виміряти реальну поведінку додатку з curl (патерни зависань важливі)

cr0x@server:~$ curl -v --max-time 10 http://10.50.12.34:8080/largefile.bin -o /dev/null
*   Trying 10.50.12.34:8080...
* Connected to 10.50.12.34 (10.50.12.34) port 8080
> GET /largefile.bin HTTP/1.1
> Host: 10.50.12.34:8080
> User-Agent: curl/8.5.0
> Accept: */*
* Request completely sent off
* Operation timed out after 10000 milliseconds with 0 bytes received
curl: (28) Operation timed out after 10000 milliseconds with 0 bytes received

Значення: Підключення встановлено, запит відправлено, відповідь так і не прийшла. Це узгоджується з тим, що великі пакети сервер→клієнт відкидаються,
або PMTUD у зворотному напрямку не працює.

Рішення: Протестуйте також зворотний напрямок (запустіть те саме з іншого хоста) та захопіть пакети на обох кінцях; підозрюйте асиметричний MTU/політику ICMP.

Завдання 15: Перевірити лічильники ядра, пов’язані з MTU/PMTUD (чи бачимо фрагментацію або помилки?)

cr0x@server:~$ netstat -s | egrep -i 'fragment|reassembl|MTU|icmp.*frag' | head -n 30
Ip:
    0 outgoing packets dropped
    12 fragments dropped after timeout
    0 reassemblies required
Icmp:
    4 destination unreachable messages received

Значення: Лічильники, пов’язані з фрагментами, можуть вказувати на реальну фрагментацію або чорні діри. Це не ідеально, але дає підказку.

Рішення: Якщо ви бачите збільшення reassembly або fragment drops під час тестів, вирівняйте MTU і не покладайтеся на фрагментацію для продуктивного трафіку.

Завдання 16: Перевірити постійну конфігурацію MTU в Ubuntu 24.04 (netplan)

cr0x@server:~$ sudo cat /etc/netplan/01-bond.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      mtu: 9000
    enp4s0:
      mtu: 9000
  bonds:
    bond0:
      interfaces: [enp3s0, enp4s0]
      mtu: 9000
      parameters:
        mode: 802.3ad
        mii-monitor-interval: 100

Значення: Netplan явно встановлює MTU. Якщо робочий MTU не збігається, може бути інший файл, що це перекриває, або runtime-зміна.

Рішення: Консолідуйте netplan-конфігурацію і застосовуйте обережно (див. план безпечного розгортання), щоб уникнути несподіваних переналаштувань під час інциденту.

Як безпечно виправити MTU (без «ой» простоїв)

Є дві загальні стратегії. Виберіть одну і дотримуйтеся. Напів-джамбо — шлях до напівпрацюючих мереж.

Стратегія A: Зробити джамбо справді end-to-end (переважно для кластерів сховищ)

Це правильно, коли ви контролюєте весь L2/L3 шлях: NIC, bond, bridge, свічі та будь-які проміжні апарати.

Встановіть MTU послідовно на кожному Linux-інтерфейсі, що несе трафік: фізичні NIC, bond, VLAN-підінтерфейси, bridge, і будь-які veth/tap для VM/контейнерів.
Переконайтеся, що порти свічів і транки налаштовані на прийом джамбо-фреймів. Слідкуйте за «baby giant» налаштуваннями, якщо залучені VLAN-теги.
Підтвердіть, що PMTUD все ще працює (не блокуйте ICMP), навіть з увімкненим джамбо. Ви хочете PMTUD як страховку, а не як жертву.
Запустіть DF-ping тести для 1500 і джамбо-розмірів між всіма критичними пирами (не лише між однією парою).

Стратегія B: Тримати underlay на 1500, налаштувати оверлеї та обрізати MSS (переважно для змішаних корпоративних мереж)

Якщо ви проходите через VPN, cloud gateways або невідомі middlebox-и, джамбо-фрейми часто програють реальності.

Залиште underlay MTU на 1500 (або на найменшому хопі, що вимагається).
Встановіть MTU тунелю/оверлею правильно (звичайно менше за underlay на величину накладних витрат).
Обріжте TCP MSS на межі, щоб TCP ніколи не намагався відправляти сегменти, що не вміщуються. Це пом’якшує PMTUD-чорні діри.

Безпечна механіка змін на Ubuntu 24.04

Ubuntu 24.04 зазвичай використовує netplan з systemd-networkd або NetworkManager. На серверах часто це networkd. Зміни MTU можуть перезапустити інтерфейси. Якщо це
той самий інтерфейс, через який ви підключені по SSH, потрібен захист.

Золоті правила для змін MTU у продакшені

Ніколи не змінюйте MTU на єдиному management-шляху без консолі поза смугою або таймованого відкату.
Змінюйте найвужчий домен першим: якщо switchport 1500, підняття хоста до 9000 нічого не дає, лише плутає.
Розгортайте по кільцях: один хост, потім пара, потім стойка/зона, потім флот.
Вимірюйте реальним трафіком: реплікацію сховища, оверлей трафік контейнерів, великі HTTP-передачі — не лише пінги.

Жарт №2: «Ми просто встановимо MTU 9000 скрізь» — мережевий еквівалент «я просто швидко перезапущу продакшн».

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

Міні-історія 1: Інцидент через хибне припущення

Середня компанія мала приватний віртуалізаційний кластер: гіпервізори на Ubuntu, трафік сховища на виділеному VLAN, і стек топ-of-rack свічів, що «підтримував джамбо».
Хтось вирішив увімкнути джамбо-фрейми, щоб зменшити CPU на гіпервізорах, бо графіки показували високі softirq під час вікон бекапів.

Інженер змінив MTU до 9000 на bond-ах гіпервізора і на інтерфейсах storage VLAN. Декілька тестових пінгів пройшли (при 1500), VM працювали, і всі розійшлися додому.
Наступного ранку лише деякі VM мали зламані бекапи. Деякі NFS-монти були в порядку. Інші зависали під час великих читань. Виглядало як проблеми з масивом сховища — популярний козел відпущення.

Хибне припущення: «Стек свічів підтримує джамбо, отже порти мають бути налаштовані.» Насправді свіч мав джамбо глобально увімкнений, але один транк до storage мережі
мав старий профіль з максимумом близько 1500. Трафік в межах стояка залишався джамбо-спроможним; трафік, що перетинав той транк, натрапляв на менший MTU і почав чорні діри великих фреймів.

Діагностика зайняла більше часу, ніж треба, бо базові чек-карти були зелені: SSH, малі RPC, heartbeat кластера. Перша по-справжньому корисна підказка була DF-ping, що падав лише між стойками,
і tcpdump, що показував ICMP «frag needed» в одному напрямку, але не в іншому (асиметрично фільтроване).

Виправлення було нудним: вирівняти MTU транку свічів, перевірити DF-ping між представницькими вузлами, і припинити трактувати «підтримує джамбо» як «налаштовано на джамбо».
Пост-інцидентне завдання було ще нудніше: вести просту матрицю MTU по VLAN і примусово перевіряти її конфігурацію. Це спрацювало.

Міні-історія 2: Оптимізація, що повернулася бумерангом

Інша організація запускала Kubernetes на Ubuntu з CNI на базі VXLAN. Вони мали швидку east-west мережу і хотіли «максимальної продуктивності», тому встановили MTU NIC вузлів на
9000 і припустили, що все інше автоматично виграє. Поди зберегли дефолтний MTU, і автодетекція MTU CNI на частині вузлів неправильно вгадала.

Тиждень нічого очевидно не ламалося. Потім розгорнули сервіс, що стрімить великі відповіді (наприклад артефакти, ML-моделі, великі JSON-блоби). Раптом лише деякі поди на деяких вузлах мали величезні
затримки і тайм-аути. Ретрай маскував проблему, тож графіки показували «повільніше, але загалом ок», що саме по собі тихо їло гроші.

Оптимізація повернулась бумерангом через накладні витрати інкапсуляції. Декілька шляхів pod→pod ефективно перевищували underlay MTU через заголовки VXLAN, і PMTUD був ненадійним через правила файрволу,
що ставилися підозріло до ICMP. Отже поди відправляли пакети, що на вузлі були ок, але були занадто велики поза вузлом.

Остаточне рішення — встановити коректний, явний MTU для CNI (нижчий за underlay на гірший випадок накладних витрат) і робити underlay MTU послідовним по всіх релевантних інтерфейсах.
Джамбо все ще використовувалися в фізичній мережі, але MTU оверлею обирали навмисно, а не «чому б і ні».

Найцінніший урок не був «не використовуйте джамбо». Це був урок: не впроваджуйте зміни продуктивності, які ви не можете перевірити end-to-end і не маєте плану відкату.
Робота з продуктивністю — це робота в продакшені. Ставтесь до неї з тією ж дисципліною.

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

Команда фінансових сервісів мала звичку: кожна мережево-важлива зміна супроводжувалася маленьким «path contract test». Це був скрипт, який запускали з канаркового хоста:
DF-ping різних розмірів, велике HTTPS-завантаження і sanity-check реплікації сховища. Він логував результати в загальнодоступне місце.

Одного кварталу команда мереж замінила пару файрволів. План міграції був твердий, але посеред довгого вікна змін хтось відновив дефолтну політику, яка ненавмисно відкидала певні ICMP unreachable-повідомлення.
З’єднання залишилося, моніторинг був зелений. Така зелень часто вводить в оману.

Канарковий тест спрацював миттєво. DF-ping джамбо-розмірів перестав отримувати «frag needed» відповіді; великі завантаження зависли; поведінка PMTUD змінилася. Нікому не довелося чекати дзвінків клієнтів.

Вони навіть не відмовилися від cutover файрволу. Вони поправили політику, дозволили необхідні ICMP, повторно запустили тести і пішли далі.
Практика не була гламурною. Вона не заробила доповідей на конференціях. Але вона врятувала день.

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

1) Симптом: SSH працює, але великі завантаження зависають або скидаються

Корінь проблеми: PMTUD blackhole. Великі TCP-сегменти перевищують MTU хопу; ICMP «frag needed» блокується.

Виправлення: Дозвольте ICMP fragmentation-needed/packet-too-big через файрволи. Як пом’якшення — обріжте TCP MSS на межі.

2) Симптом: Після ввімкнення джамбо ламається лише крос-підмережний трафік

Корінь проблеми: L3-пристрій (роутер, файрвол, шлюз) все ще на 1500, тоді як локальний L2 — джамбо.

Виправлення: Або зробіть маршрутизований шлях джамбо-спроможним end-to-end, або тримайте MTU сервера на 1500 для того маршрутизованого сегмента і використовуйте джамбо лише в ізольованих VLAN для сховищ.

3) Симптом: East-west трафік pod у Kubernetes нестабільний; ping між вузлами хороший

Корінь проблеми: MTU оверлею не зменшено для накладних витрат VXLAN/Geneve, або непослідовний CNI MTU між вузлами.

Виправлення: Встановіть послідовний CNI MTU (наприклад, 1450 для underlay 1500, або більше, якщо underlay джамбо). Перевірте DF-тести між подами на різних вузлах.

4) Симптом: VMs на Linux-bridge ламаються, але хост в порядку

Корінь проблеми: Bridge MTU або tap/vnet пристрої на 1500; NIC хоста на 9000. Трафік VM натрапляє на менший MTU.

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

5) Симптом: Один напрямок повільний, інший — в порядку

Корінь проблеми: Асиметрична маршрутизація або асиметричне фільтрування ICMP; PMTUD працює в одному напрямку, але не в зворотному.

Виправлення: Захопіть трафік з обох кінців; вирівняйте політики MTU; дозвольте ICMP в обидва напрямки; перевірте симетрію шляхів для критичних потоків.

6) Симптом: «Ми встановили MTU 9000, але ping каже mtu=1500»

Корінь проблеми: Маршрут використовує інший інтерфейс (VRF, VLAN, bridge), що все ще на 1500, або перекриття конфігурації скидає MTU при піднятті лінка.

Виправлення: Використайте ip route get щоб підтвердити egress-пристрій; перевірте MTU на всьому стеку інтерфейсів; виправте netplan/systemd-networkd конфіг для коректного збереження.

7) Симптом: Продуктивність погіршилась після увімкнення джамбо

Корінь проблеми: Мікро-сплески та тиск на буфери свічів/NIC або проблеми драйвера/оффлоаду. Джамбо зменшує кількість пакетів, але може збільшувати серіалізацію та сплески.

Виправлення: Перевірте пропускну здатність і затримки, слідкуйте за drop-ами на свічах/NIC, розгляньте трохи менші джамбо-розміри (наприклад 9000 vs 9600) і тонко налаштуйте черги; не думайте, що «більше завжди швидше».

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

Чекліст: перед тим як торкатися MTU

Визначте область: який VLAN/підмережа/тунель змінюється?
Перелічіть кожен хоп: NIC серверів, bond, bridge, гіпервізор vSwitch, switchports, транки, роутери, файрволи, VPN, балансувальники навантаження.
Вирішіть цільовий MTU для домену: тільки 1500, або джамбо end-to-end.
Підтвердіть, що у вас є шлях відкату: консоль, альтернативний mgmt NIC, або таймований job, що повертає netplan.
Підготуйте тести: DF-ping розміри, велика HTTP-передача і один реальний робочий тест (реплікація сховища, завдання бекапу тощо).

Покроково: безпечне розгортання джамбо на Ubuntu 24.04 (сервери)

Виберіть канарковий хост з out-of-band доступом.
Виміряйте базову лінію:
запустіть DF-ping на 1472 і 8972 до ключових пір; зробіть велику передачу; захопіть короткий tcpdump для ICMP «frag needed».
Переконайтеся, що мережа готова:
налаштуйте switchports/trunks для джамбо, підтвердіть з мережею за їхніми інструментами. Не змінюйте хости, поки мережа не буде готова.
Змініть MTU на канарковому хості в netplan для всіх релевантних інтерфейсів (фізичні + bond + VLAN + bridge).
Застосовуйте контрольовано:
надавайте перевагу maintenance-вікну; якщо тільки віддалено, використовуйте таймований відкат (див. нижче).
Негайно перезапустіть тести:
DF-ping джамбо має пройти end-to-end; додаткова передача має завершитись; перевірте ss -ti на адекватні MSS/PMTU.
Розширюйте по кільцях:
пара хостів з інтенсивним трафіком; потім одна стойка; потім флот.
Тримайте моніторинг сфокусованим:
слідкуйте за ретрансляціями, таймаутами і затримкою сховища. Помилки MTU часто проявляються як шторм ретрансляцій, а не лінк-down події.

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

Якщо ви змінюєте MTU на інтерфейсі, через який йде ваш SSH-сеанс, налаштуйте таймований відкат перед застосуванням netplan. Приклад: заплануйте reboot або відновлення netplan
за 5 хвилин, потім скасуйте його як тільки підтвердите з’єднання. Є багато способів; суть: не ставте продакшн на карту вашого Wi‑Fi.

cr0x@server:~$ sudo systemd-run --on-active=5m --unit=mtu-rollback.service /usr/sbin/netplan apply
Running as unit: mtu-rollback.service

Значення: Цей приклад навмисне спрощений і не є повним відкатом; на практиці ви б запустили скрипт, що відновлює відомий-робочий netplan YAML і застосовує його.

Рішення: Використовуйте реальний rollback-скрипт у вашому середовищі. Ідея — операційний патерн: застосувати зміну з таймером безпеки і скасувати його після перевірки.

Часті запитання

1) Чому ping працює, а мій додаток ламається?

За замовчуванням ping використовує малі пакети. Ймовірно ваш додаток відправляє більші TCP-сегменти. Проблеми MTU кусають лише тоді, коли пакети перевищують найменший MTU на шляху,
і тоді PMTUD може або не врятувати, залежно від політик ICMP.

2) Який MTU обрати для джамбо-фреймів: 9000 чи 9216?

Обирайте значення, яке ваші свічі і NIC підтримують послідовно. 9000 — загальне для «IP MTU». Деякі пристрої рекламують 9216 як розмір фрейму. Єдина правильна відповідь:
оберіть одне, документуйте це по VLAN і протестуйте end-to-end включно з VLAN-тегуванням і транками.

3) Чи джамбо-фрейми завжди покращують продуктивність?

Ні. Вони часто зменшують навантаження на CPU при високій пропускній здатності, але можуть також збільшувати burstiness і навантаження на буфери. Якщо вузьке місце — диск, шифрування,
серіалізація додатку або однопотоковий юзерленд-процес, джамбо вам не допоможе.

4) Чи фрагментація справді така погана?

Поодинокі випадки фрагментації для дивного трафіку допускаються. Але покладатися на фрагментацію для bulk-трафіку — це податок: додатковий CPU, складність reassembly, більша чутливість до drop-ів,
і складніше дебажити. Більшість сучасних дизайнів намагаються її уникати.

5) Як найкраще виявити PMTUD blackholes?

DF-ping тести плюс захоплення пакетів для ICMP «frag needed» / «packet too big». Якщо великі DF-пакети зникають і ви ніколи не бачите ICMP-помилку, щось фільтрує.
Також шукайте застопорені TCP-потоки з високими ретрансляціями і відсутністю прогресу.

6) У Kubernetes, чи варто встановлювати node MTU на 9000?

Тільки якщо ваш underlay справді підтримує джамбо end-to-end і ви коректно встановите CNI/overlay MTU. Інакше тримайте underlay на 1500 і використовуйте нижчий MTU оверлею,
що враховує інкапсуляцію.

7) Чому проблема проявляється лише для деяких напрямків?

Різні призначення можуть йти різними мережевими шляхами з різними MTU (інші роутери, файрволи, VPN-тунелі, cloud edge). Невідповідності MTU по суті залежать від шляху.

8) Як швидко виправити, якщо я не можу змінити мережу сьогодні?

Пом’якшіть проблему, зменшивши MTU на постраждалому інтерфейсі(ах) до найменшого безпечного значення, або обріжте TCP MSS на межі, щоб кінці перестали надсилати надто великі сегменти.
Потім заплануйте справжнє виправлення: вирівнювання MTU end-to-end або виправлення політики ICMP.

9) Чи Ubuntu 24.04 робить щось «особливе» з MTU?

Звична складність походить від того, що netplan рендерить у systemd-networkd або NetworkManager, плюс вкладені інтерфейси (bonds, bridges, VLAN, тунелі).
ОС не особлива; ваша топологія — ось де вся справа. Перевіряйте MTU в runtime за допомогою ip -br link, а не лише у YAML.

10) Чи слід дозволити весь ICMP через файрвол?

Слід дозволити ті типи ICMP, що потрібні для нормально роботи, особливо fragmentation-needed/packet-too-big та суміжні unreachable-повідомлення. Блокування всього ICMP —
грубий інструмент, що ламає PMTUD і ускладнює діагностику відмов.

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

Джамбо-фрейми або працюють end-to-end, або створюють вибіркове поле спотворення реальності, де малі пакети процвітають, а великі пакети зникають. Ось чому ви бачите «тільки деякий» трафік, що ламається.

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

Запустіть DF-ping тести на 1500 і джамбо-розміри між парами, що мають значення.
Знайдіть найменший MTU на шляху, перевіривши кожен рівень інтерфейсів: NIC, bond, VLAN, bridge, тунель.
Підтвердіть PMTUD, захопивши ICMP «frag needed» / «packet too big»; виправте політики файрволу, що їх блокують.
Виберіть стратегію: справжній end-to-end джамбо для контрольованих доменів, або консервативний underlay MTU з коректним overlay MTU та обрізанням MSS.
Розгортайте по кільцях з канаркою і планом відкату. Продакшн винагороджує обачність, а не відвагу.