О настройках MTU в машинах и переключателе

Вы не указывали, о каких сетевых технологиях Вы говорили, таким образом, я собираюсь принять Ethernet и IP[v4].

Ethernet всегда определял свой диапазон приемлемых длин полезной нагрузки, чтобы быть от 46 до 1 500 байтов и требует, чтобы все устройства (хосты и переключатели) на LAN смогли принять кадры с 1 500-байтовыми полезными нагрузками. Из-за этого Ethernet не обеспечивает механизм фрагментации, и при этом он не обеспечивает механизм для передачи или согласования MTUs (или, что еще более важно, MRUs - Максимум Получает Единицы) между устройствами. На самом деле термин "MTU" или "максимальный блок передачи" не появляется нигде в спецификации IEEE 802.3.

Поэтому давайте добавим IP в изображение. IP имеет понятие MTU, и самые современные стеки IP позволяют Вам установить MTUs на основе на интерфейс (и больше). Но Ваш вопрос, как указано не вполне удается в контексте IP также, потому что IP имеет минимальный MTU 576. Поэтому позвольте мне вновь заявлять о своем вопросе, поскольку "M1 имеет MTU 600, и M2 имеет MTU 1200". Но что MTU мы скажем, что "Переключатель" имеет? Ну, если Переключатель является просто Ethernet-коммутатором Уровня 2, он не имеет понятия устанавливаемого MTU. Таким образом для разбирания вопроса работают в контексте IP, мы должны будем превратить тот переключатель в маршрутизатор. Поэтому давайте назовем это "Маршрутизатором" и скажем, что это имеет два интерфейса Ethernet, один присоединенный к M1 и один присоединенный к M2. Давайте также скажем, что это имеет MTUs набора 1200 года в обоих из его интерфейсов.

1. Когда M1 передает кадр с 600-байтовой полезной нагрузкой к M2, не было бы никакой проблемы.
2. Когда M2 передает кадр с 1 200-байтовой полезной нагрузкой к M1, все еще не было бы никакой проблемы. Почему нет? Поскольку установка M1's MTU не обязательно изменила свой MRU, и по моему опыту MTUs и MRUs являются отдельными, и реализации не дают Вам способ изменить Ваш MRU. Таким образом, M1 MRU в том интерфейсе был бы 1500, так как это - Ethernet.
3. Маршрутизатор не знал бы, что должен фрагментировать кадры от M2, потому что он полагает всем хостам на Ethernet LAN, что M1 идет, могут принять кадры с 1 200-байтовыми полезными нагрузками, потому что он был настроен для 1 200-байтового MTU в том интерфейсе. К счастью это все еще, вероятно, удалось бы прекрасный, как я обсудил в (2).

Хорошо, все еще пытаясь найти и ответить на истинный дух Вашего вопроса, скажем, ссылкой между M1 и Маршрутизатором является на самом деле PPP вместо Ethernet. Протокол PPP позволяет хостам связываться/согласовывать свой MRUs. Скажем, это, M1 сказал Маршрутизатору, что M1 имеет 600-байтовое ограничение MRU, таким образом, Маршрутизатор установил свой MTU для той ссылки на 600 байтов.

Теперь, в этом случае, если M2 отправляет 1 200-байтовую дейтаграмму IP в M1 (не устанавливая "не Фрагментируют" бит в заголовке IP), Маршрутизатор получит его очень хорошо и поймет, что это должно фрагментировать его для отправки его в M1. Действительно ли Маршрутизатор фрагментирует его в два 600-байтовых фрагмента? Ну, нет, дело не в этом простой по паре причин.

Одна причина состоит в том, что каждый фрагмент должен иметь свой собственный заголовок IP, который добавляет 20 байтов к размеру каждого фрагмента после первого. Другая причина состоит в том, что фрагментация IP смещала полевые количества в 8-байтовых блоках вместо отдельных байтов.

Таким образом, скажем, 1 200-байтовая датаграмма была конкретно 1 172 байта данных приложения в датаграмме UDP (8 байтов заголовков UDP, 20 байтов заголовков IP). После фрагментации первый фрагмент содержал бы 20-байтовый заголовок IP, 8-байтовый заголовок UDP, и первые 568 байтов данных приложения, для в общей сложности 586 байтов. Второй кадр содержал бы другой 20-байтовый заголовок IP, никакой заголовок UDP, и следующие 576 байтов данных приложения, для в общей сложности 586 байтов. Это оставляет 28 байтов данных приложения перенесенными для заключительного фрагмента, который, с его добавленным заголовком IP, составил бы 48 байтов.

Обновление на основе обновления Kavin, что он говорил о Крупных кадрах:
Крупные кадры - что-то, что некоторые поставщики продуктов Gigabit Ethernet создали независимо во время, GigE был создан, и это было (я верю), впоследствии отклоненный или проигнорированный IEEE, и кажется маловероятным когда-либо стать частью 802,3 стандартов Ethernet. Даже IEEE 802.3-2008, который включает не только 1000BASE-T, но и 10GBASE-T, ничего не содержит приблизительно 9 000-байтовые полезные нагрузки кадра.

Поставщики, которые придумали крупные кадры, не обеспечили вида механизма автоматического согласования или механизма связи для поддержки крупных кадров, и при этом они не создавали метод фрагментации уровня Ethernet для обработки (очень общего) случая, который Вы проиллюстрировали. Если Вы хотите выполнить свой Ethernet LAN в этом нестандартном режиме, необходимо удостовериться, что все хосты и включают крупные кадры поддержки LAN.

Если NIC M1 не будет способен к приему крупных кадров, то он будет полагать, что крупный кадр "бессмысленные данные Ethernet" - поврежденное устройство, которое "продолжает передавать бессмысленные данные вперед и вперед"; продолжает отправлять биты далеко за пределами конца максимального допустимого 1500 (действительно 1518) - кадр байта. Обратите внимание, что это значение бессмысленных данных является термином для своего рода неправильного функционирования Ethernet и не должно быть перепутано с так же названным интернет-система чата "Бессмысленных данных". Необходимо будет решить, хотите ли Вы прекратить использовать крупные кадры в этой сети, или если Вы хотите обновить M1, чтобы иметь NIC, который поддерживает крупные кадры.

Если NIC M1 способен к приему крупных кадров, я подозреваю, что установка его MTU IPv4 для того интерфейса вниз к 1500 гарантирует, что это не передает измеренных дейтаграмм IP гиганта в единственном гигантском кадре Ethernet, но это, скорее всего, сможет получить большие дейтаграммы IP в единственных гигантских кадрах Ethernet без проблем, потому что снова, MTU не является MRU и установкой IPlayer, MTU не влияет на то, какие кадровые буферы размера NIC позволяет. Теперь, если Вы настраиваете установку NIC/driver, чтобы сказать NIC только использовать 1 500-байтовые буферы вместо 9 000-байтовых буферов, это - изменение уровня Ethernet и вероятно заставило бы Ваш NIC действовать, как будто это не поддерживало 9 000-байтовые буферы.