LINUX.ORG.RU
Форум — General  

Теоретический вопрос про Path MTU discovery


0

0

Была у меня недавно проблема с тем, что пакеты не влезали в MTU интерфейса где то по пути…
Подробно обсуждалось вот тут: http://www.linux.org.ru/forum/general/5042600
Проблема была решена с помощью временного костыля и вроде бы все работает. Но хочется понять как это должно работать «по-настоящему».

Например, есть WEB сервер включенный в ethernet сеть. Естественно у него MTU интерфейса 1500.
И есть рабочая станция в локальной сети которая (сеть) подключена к internet через маршуртизатор с NAT
Между клиентом и сервером устанавливается TCP соединение. И у клиента и сервера MTU интерфейса 1500. Естественно они согласуют MSS = 1500 – 40 = 1460.
А если где то на маршруте от клиента к серверу есть участок с MTU 1000 и запрещена фрагментация пакетов? Ни клиент ни сервер об этом не знают!
Как это будет работать?
Вообще по опыту часто провайдеры запрещают фрагментацию пакетов?

★
← Emacs цвет скролбара
загрузка программы при старте →

В приведенный тобой теме есть ссылка на свтью на опеннете, где все подробно расписано.
Этот промежуточный узел, где MTU 1000 и запрещена фрагментация, пошлет отправителю icmp пакет типа 3:4, и отправитель перепошлет пакет меньшего размера, если конечно между отправителем и этим узлом не запрещены ICMP пакеты.

Steel901 ★
()

>А если где то на маршруте от клиента к серверу есть участок с MTU 1000 и запрещена фрагментация пакетов?

Хост на конце этого участка должен ответить ICMP 3/4 (destination unreachable, fragmentation required, MTU 1000), после чего отправитель должен соответственно уменьшить MSS и попытаться снова.

Все проблемы начинаются с того, что какой-то сервер на маршруте настроен неправильно и либо не отвечает так, либо блокирует чужие ответы. Обычно это сам VPN-сервер либо клиентский фаервол.

Вообще по опыту часто провайдеры запрещают фрагментацию пакетов?


Запрещение фрагментации определяется битом DF в IP-заголовке и является необходимым условием нормальной работы PMTU disc. Провайдеры этим не занимаются.

Зато провайдеры могут блокировать ICMP 3/4, что собственно, и является главной причиной всех проблем. Возьмут админом какого-нибудь студента, который вчера осилил установку убунту-сервер или фрибсд и теперь считает себя мега-кул-админом, и готово дело.

nnz ★★★★
()
Ответ на: комментарий от nnz

Хорошо, а если клиент расположен за NAT'ом?
Как он получит icmp пакет?

И кто в оперционке должен отслеживать приход таких icmp пакетов у уменьшать MTU?

dvalov ★
() автор топика
Ответ на: комментарий от dvalov

>Хорошо, а если клиент расположен за NAT'ом?

NAT на базе netfilter/iptables должен правильно передать всё клиенту. Насчет пионерских поделий ничего гарантировать не могу.

anonymous
()
Ответ на: комментарий от dvalov

>Другой общеизвестный факт: на конец первого квартала 2010 года доля GNU/Linux на рабочих станциях по-прежнему не превышает 1% во всех сегментах рынка РФ.

Насколько я помню, этим занимается ядро.

anonymous
()
Ответ на: комментарий от dvalov

>И кто в оперционке должен отслеживать приход таких icmp пакетов у уменьшать MTU?

Насколько я помню, этим занимается ядро.

anonymous
()
Ответ на: комментарий от dvalov

> Хорошо, а если клиент расположен за NAT'ом?

nat - stateful. пакет icmp подпадет под тот же стейт и вернется отправителю вполне нормально. невидел ни одной реализации ната, на которой бы это не работало. можно конечно руками порезать, при желании

И кто в оперционке должен отслеживать приход таких icmp пакетов у уменьшать MTU?


стек, офк. обычно PMTU и отработка ицмп 3/4 интегрирована в реализацию TCP, и эта реализация обыно - часть ядра (для справки, бывают еще юезрланд стеки, но в реальности они используются очень редко).

val-amart ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Emacs цвет скролбара
General
загрузка программы при старте →