Windows IP MTU и размер пакета ICMP ping

Сказ о разрушении некоторых стереотипов.

Итак, ты злой гений, решивший проверить какого максимального размера пакет пройдет через устройство, в котором ты сомневаешься. Скорее вего, какой-нибудь маршрутизатор где-нибудь в сети. И вот ты сел перед своим монитором, провод от которого тянется в железку, на котором установлена, скажем,  windows 7, положил пальцы на клавиатуру, открыл черный экран и ввел там нечто подобное:

ping 10.103.75.8 -n 1 -l 20000

Т.е. ты сейчас попытаешься отправить в сеть один пакет размером 20000 байт, адресованный какому-то хосту в другой подсети и посмотреть, пройдет ли он.

После этого ты нажал Enter и увидел следующее:

widnows_7_ping_packet_size

Что ты подумал? Наверное что-то такое:

«Зашибись! Пакет, размером 20000 байт прошел, теперь попробую послать пакет в 30000 байт!»

Т.е. 20000байтный пакет вполне себе влез во все интерфейсы всех устройств, лежащих на его пути. Так? А вот и хер там плавал ни разу не так.

Во первых, с учетом того, что стандартный MTU в сети Еthernet, как правило, равен 1500 байт (т.е. в 13.3 меньше чем заданные 20000), для многих очевидно, что для того, чтобы пакет такого размера прошел, он должен быть кем-то фрагментирован. Но далеко не для всех очевидно, что на деле фрагментирован этот пакет будет уже на хосте, с которого отправлен. Т.е. в сеть сразу попадут пакеты, порубленные на куски, не больше 1500 байт.

Вот например, посмотрим, какой по умолчанию MTU установлен интерфейсах хоста под windows 7, с которого ты послал icmp echo размером 20000 байт. А чтобы на windows 7 узнать MTU интерфейсов, нужно выполнить команду:

netsh interface ipv6 show subinterfaces

И послее ее выполнения, увидим:

windows 7 показать MTUТут работающий интерфейс тот, который указан в перовой строке. MTU у него всего лишь 1300 байт! Это значит, что тот самый один пакет в 20 000 байт, превратится в 16 пакетов, которые и будут отправлены сетевой картой и дальше, естественно, пройдут весь путь без препятствий (если, конеш, фрагменты нигде не фильтруются). В командной строке ты этого не увидишь, а увидишь, то, что увидел ранее, что пакет ушел, и ответ был получен, а round trip составил 19 миллисекунд. А дабы увидеть то, что происходит в действительнсти, достаточно просто запустить Wireshark на нужном  интерфейсе. Так и сделаем, и еще раз отправим «пакет размером 20000 байт»:

widnows_7_ping_packet_sizeВ CLI все хорошо — отправлено: 1, получено: 1, время: 19msec.

Смотрим что показывает wireshak (кликабельно):

Wireshark IP Fragmentation

А Wireshark показывает, что отправка одного большого пакета явилась причиной хорошей такой переброски пакетов в сеть. Этот изначальный пакет в 20000 байт был, как посчитали ранее, разбит на 15 пакетиков помельче (посчитай строки до той, которая ярко выделена цветом, включая ее), размер каждогоиз которых, за исключением последнего, составил 1300 байт = MTU интерфейса. Последний пакет был собран из остатка и потом оказался помельче. Хост на том конце все эти 15 пакетов собрал в один и после этого ответил, также выполняя фрагментацию со своей стороны (на картинке, те пакеты, которые идут после ярко выделенной строки).

Мораль басни, думаю, ясна. Отправляя в сеть, как ты думаешь, большые пакеты, ты в действительности отправляешь туда фрагменты. Чтобы пакет не рубился, нужно чтобы в IP заголовке такого бакета бит DF был установлен в единицу. Чтобы на том же windows 7 отправить icmp пакет, который не может быть фрагментирован, нужно к прежней команде добавить ключ -f. Это будет означать, что пакет фрагментировать нельзя. Пример, где сначала выставляем размер 20 000 >> MTU и затем 1200 < MTU:

ip_fragmentation_df_bit

Ну и видим, что пакет 20000 оказался слишком большим и даже не выполз из сетевого интерфейса. Если в это время на интерфейсе запущен Wireshark, то он ничего не покажет, т.к. он фиксирует только пакеты, покинувшие интерфейс.

После того, как размер пакета был уменьшен до 1200 байт, что меньше MTU интерфейса, он успешно смог слетать туда и обратно.

Вообще, большинство приложений и операционных систем работают так, что пакеты, ими отправляемые, уже имеют бит DF установленным в единицу, т.е. они не фрагментируются. Это нужно для работы механизма Path MTU Discovery, о котором подробно написано здесь. Но это, как оказывается, не относится к виндовым icmp echo пакетам, которые, как видим, по умолчанию фрагментируются.

 


Не забывайте оставлять комментарии, если пост был вам полезен!
Опубликовано в Сети Метки: , , ,
0 comments on “Windows IP MTU и размер пакета ICMP ping
11774 Пинги/Обратные ссылки для "Windows IP MTU и размер пакета ICMP ping"