Почему нельзя менять MTU больше 1500 байт

В интернете существует легенда, что при увеличении MTU до 9000 вырастает скорость. В некоторых случаях да, но в вашем случае все будет наоборот и я расскажу почему.

Введение

В сети Ethernet все данные передаются кадрами, на уровне IP сети это называется пакетом. Эти кадры и пакеты имеют разный размер, еще называют длиной. Далее я буду рассматривать только кадры, но называть их буду пакетами. Так лучше для понимания людей, которые не разбираются в уровнях модели OSI.

Получается, что служебные данные занимают всегда примерно одинаковый размер 28 байт без учета ethernet заголовков еще 14 байт, если есть vlan то еще 4 байта, а если есть MPLS метка то каждая так же по 4 байта. В это же время как размер полезной нагрузки может меняться от 64 до 1472 байта. Соответственно чем больше полезных данных помещается в один пакет, тем больше скорость передачи данных. И вот тут приходит миф о том, что нужно увеличить MTU как можно больше и тогда скорость будет больше. Но зачастую все получается иначе.

MTU (Maximum Transmission Unit) — это максимальный размер блока данных (в байтах), который может быть передан через сетевой интерфейс без фрагментации.

• Стандартное значение MTU: 1500 байт (включая заголовки).
• Jumbo Frames (увеличенные кадры): 9000 байт (иногда 9014 или 9216 с учетом заголовков).

MTU существует на разных уровнях сетевой модели (OSI/TCP-IP), но чаще всего рассматривается на канальном (L2) и сетевом (L3) уровнях.

• Примеры:
  • Ethernet (стандартный): 1500 байт (полезная нагрузка + заголовки).
  • Ethernet (Jumbo Frames): 9000+ байт (обычно для 10G/40G/100G сетей).
  • Wi-Fi (802.11): обычно 2304 байта, но на практике тоже ограничен 1500.
  • PPP (DSL, модемы): часто 1492 байта (из-за заголовков PPPoE).

Как ведите выше указано, что для 10G и выше сетей применяется MTU 9000 и это так же вводит людей в заблуждение.

Вся проблема в том, что в одной сети размер MTU должен быть одинаковый у всех устройств. Именно поэтому и был разработан стандарт MTU 1500. Такое значение поддерживают все устройства с Ethernet портами. Если вы меняете размер MTU на NAS до 9000, то вы должны поменять это значение на всех устройствах в вашей сети начиная от ПК и заканчивая телевизорами, умными розетками и телефонами. На большей части таких устройств просто нет возможности изменить MTU со стандартного значения 1500 байт.

Так же не забывайте, что коммутаторы и роутеры должны обрабатывать MTU 9000 если вы меняете го на сервере. В противном случаи вы рискуете получить плохо работающую сеть.

Длинный размер пакета 9000 байт передается дольше чем 1500 байтный пакет. Это важно для RealTime траика. Например в онлайн играх очень важно, что бы не возникало задержек и джитеров связанных с пакетами Jumbo Frames.

Как работают устройства с разным MTU (1500 vs 9000)?

Если два устройства в одной сети имеют разный MTU, но обмениваются данными напрямую (через коммутатор), то устройство с MTU 9000 может отправлять большие кадры, но если получатель поддерживает только 1500 это может быть как порт коммутатора так и ПК или телевизор, то пакет теряется на порту, который не поддерживает MTU больше чем размер приходящего пакета. Это может вызвать задержки в передаче информации или вообще непонятным глюкам вроде таких: утром работает, а вечером нет.

Что будет с телевизорами, смартфонами и IoT?

• Большинство потребительских устройств (TV, смартфоны, IoT) работают с MTU 1500 и не поддерживают Jumbo Frames.
• Если NAS имеет MTU 9000, а клиент (телевизор) — 1500:
  • SMB/NFS/UPnP/DLNA:
    • Некоторые протоколы (например, SMBv3) могут автоматически адаптироваться. А какой у вас протокол SMB на телевизоре?
    • Но если NAS попытается отправить кадр >1500, а клиент его не примет → возможны зависания, обрывы потокового видео, ошибки при доступе к файлам.
  • HTTP-стриминг (Plex, Emby, Jellyfin):
    • Обычно работает, т.к. использует TCP, который сам регулирует размер сегментов (MSS).
    • Но если где-то на пути есть неправильная фрагментация → возможны буферизации, рывки в видео.

3. Проблемы с другими ПК (MTU 1500)

• Если ПК с MTU 1500 обращается к NAS с MTU 9000:
  • Файловые протоколы (SMB, NFS):
    • Могут работать, но не оптимально – NAS будет дробить свои большие кадры, что снизит скорость и повысит нагрузку на сервер.
  • Синхронизация (rsync, Resilio, Syncthing):
    • Обычно нет проблем, т.к. протоколы адаптируются.
  • Другие протоколы:
    • Могут работать не стабильно, плавать скорость или вообще прерываться соединение

Что получаем в итоге:

• Телевизоры, смартфоны и IoT не поддерживают Jumbo Frames → при MTU 9000 на NAS возможны глюки (обрывы стриминга, ошибки доступа).
• Другие ПК с MTU 1500 будут работать, но неэффективно.
• Решение:
  • Или оставить MTU 1500 для всей сети (если важна универсальность).
  • Или разделить сеть (отдельный коммутатор с поддержкой Jumbo Frames).

Если сомневаешься – оставь MTU 1500. Jumbo Frames нужны только в оптимизированных сетях!

Когда можно увеличить MTU до 9000?

Думаю понятно, что не стоит увеличивать размер MTU больше 1500 байт. Так зачем же тогда сделали этот параметр и дали возможность увеличивать MTU? Все очень просто. Это сделано не для домашних сетей, а для специализированных коммутаций строго под определенные типы задач.

Например, когда вы собираете кластер Synology (Как сделать Synology кластер), то на портах кластера лучше всего выставить MTU 9000, а на портах локальной сети оставить 1500 по умолчанию. Это даст прирост к скорости обмена данными между серверами. Не забудьте сделать это с двух сторон. Так же можно увеличить MTU в отдельных сетях, где все устройства настроены на MTU 9000, в том числе и коммутатор. Тогда проблем с прохождением Jumbo Frames не будет и все будет работать корректно.

Увеличение MTU (использование Jumbo Frames) оправдано в следующих случаях:

1. Высокоскоростные локальные сети (LAN)

• 10 Гбит/с и выше – при больших скоростях снижение накладных расходов за счет уменьшения количества пакетов дает прирост производительности.
• Серверные кластеры, NAS, SAN – передача больших объемов данных (виртуализация, хранилища, резервное копирование).

2. Закрытые сегменты сети

• Все устройства поддерживают Jumbo Frames – если в пути нет маршрутизаторов или коммутаторов, которые не работают с MTU > 1500.
• Нет фрагментации – если трафик не выходит в интернет (где MTU обычно ограничен 1500).

3. Специализированные протоколы

• iSCSI, NFS, RoCE, InfiniBand – эти технологии часто используют большие MTU для повышения эффективности.

Когда нельзя трогать MTU и нужно оставить 1500?

1. Интернет-трафик и VPN

• Публичные сети – большинство интернет-провайдеров не поддерживают Jumbo Frames, что приводит к фрагментации или сбросу пакетов.
• VPN (IPSec, OpenVPN, WireGuard) – туннелирование добавляет свои заголовки, уменьшая доступный MTU.

2. Смешанные сети

• Если есть старые устройства – не все коммутаторы, маршрутизаторы и сетевые карты поддерживают MTU > 1500.
• Wi-Fi – беспроводные сети часто имеют ограничения, близкие к 1500.

3. VoIP и чувствительный к задержкам трафик

• Меньшие пакеты (1500) быстрее обрабатываются – в реальном времени (VoIP, игры) важна не только пропускная способность, но и latency.

Вывод

• Используйте Jumbo Frames (MTU 9000) в высокоскоростных локальных сетях, где все устройства поддерживают большие кадры.
• Оставляйте MTU 1500 в интернет-трафике, VPN и локальных сетях особенно с WI-FI.

Фрагментация IP-пакетов

Фрагментация — это разбиение большого IP-пакета на меньшие части, если он превышает MTU (максимальный размер) следующего участка сети.

Где возможна фрагментация?

• На маршрутизаторах (L3) → если пакет больше MTU следующего участка сети.
• На конечных хостах → если приложение отправляет данные больше MSS.
• Не происходит на коммутаторах (L2) → они работают с кадрами и не разбирают IP-пакеты.

Как работает фрагментация?

Когда маршрутизатор получает пакет, который больше MTU следующего интерфейса:

1. Он разбивает его на несколько частей.
2. Каждый фрагмент получает:
   • Один и тот же ID (для сборки на получателе).
   • Смещение (offset) — позиция фрагмента в исходном пакете.
   • Флаг “More Fragments” (кроме последнего фрагмента).
3. Получатель собирает пакет обратно.

Почему фрагментация — это плохо?

1. Большая нагрузка на маршрутизаторы

• Каждый фрагмент обрабатывается как отдельный пакет → увеличивается CPU-нагрузка.
• Если один фрагмент потеряется → весь пакет отбрасывается (повторная передача).

2. Проблемы с производительностью

• TCP-сессии могут тормозить из-за потерь фрагментов.
• UDP-трафик (VoIP, игры) страдает от джиттера и задержек.

3. Проблемы с безопасностью

• Некоторые фаерволы блокируют фрагментированные пакеты.
• Атаки типа Teardrop используют фрагментацию для обхода защиты.

Итого по фрагментации

• Фрагментация происходит на маршрутизаторах (L3), но не на коммутаторах (L2).
• Она создаёт нагрузку и снижает производительность.
• Лучшие практики:
  • Использовать стандартный MTU=1500.
  • Включать Path MTU Discovery.
  • Для VPN/PPPoE применять MSS Clamping.
  • В локальных сетях с Jumbo Frames убедиться, что все устройства поддерживают MTU=9000 в противном случаи оставляйте MTU 1500 байт.

Итог: Фрагментацию лучше избегать, правильно настраивая MTU и MSS!

Практическая часть

У меня два Synology NAS подключены друг к другу без коммутаторов на портах LAN 2. Тестировать я буду программой Iperf3 из докера. Инструкция для сервера есть тут Synology NAS установка и запуск Iperf сервера. Для клиента я взял контейнер docker networkstatic/iperf3 и запустил его с параметрами -с 192.168.69.10 -t 60 -i 5 -P 5

• -с – работать в режиме клиента и IP адрес сервера
• -t – время работы теста, я указал 60 секунд
• -i – интервал обновления
• -P – количество потоков, я указал 5 потоков

Затем я выставил MTU 1500 на портах двух NAS и провел тест. Потом выставил MTU 9000 на портах NAS и провел тест. Как видите на скриншотах ниже нет никакой разницы в скорости при разных MTU. Конечно тест не совсем корректный, потому что интерфейсы 1G, но дома у меня нет ничего большего. Могу только сказать, что и на 10G и на 100G небудет никакой разницы в этом тесте.

Затем я взял и установил с одной стороны MTU 1500, а с другой MTU 9000. Как раз на той стороне, которая посылает трафик размер MTU больше чем на той, куда этот трафик приходит. Как видите на скриншоте ниже результат почти в два раза хуже чем когда MTU было одинаковое.

Более того, во время теста скорость падала до нуля и связано это было с тем, что интерфейс с MTU 1500 просто выключался на короткое время, когда на него приходил трафик с размером 9000 байт в больших количествах. Это и приводило к потерям, но так же к потерям приводило и то, что если вы посмотрите выше на скриншот, то увидите, что некоторые потоки были в нуле. Это происходило из-за того, что TCP протокол пытался понять размер MTU на канале и подстроиться. Как итог это влияло на скорость передачи данных в отрицательную сторону.

Общий итог

Самое лучшее никогда не менять MTU 1500 байт. Это будет вашим гарантом того, что с ним нет проблем и все работает корректно. Не слушайте никого и никогда, если вам говорят поменять MTU на 9000. Это крайне неверное утверждение с плачевными последствиями. Что бы изменить MTU на значение больше 1500 вам нужно изучить вашу сеть и все устройства в ней, убедиться в возможности установки нужного значения MTU на всех устройствах и даже тогда я настоятельно не рекомендую это делать.

Размер MTU больше 1500 байт применяют только в специальных средах под узконаправленные задачи. MTU 9000 не будет хорошо работать в домашних сетях где очень много разного оборудования и кто знает какая яндекс станция завтра появится у вас.

Я как человек работающий в IP сетях уже 20 лет никогда не меняю MTU больше 1500, потму что опасаюсь непонятных проблем, что там говорить об обычном человеке, который структуру пакета то не знает. Совет бывалых админов:

1. Не трогай MTU, если не знаешь что это.
2. Даже если знаешь все равно не трогай!