Path MTU Discovery или еще одна причина проблем с сетевым взаимодействием.

Раз уж я поднял проблему сетевого взаимодействия, то приведу еще один пример из моей практики, а так же поделюсь некоторыми рекомендациями связанными с особенностью работы стека TCP/IP в Microsoft Windows Server 2003.

Впервые я столкнулся с этой проблемой, когда стал массово устанавливать Windows Server 2003 Service Pack 1 на серверы. Проблема обычно выражалась в том, что хосты с Win2k3SP1 отделенные от других хостов, маршрутизаторами или сегментами сетей использующими не Ethernet среду передачи начали взаимодействовать друг с другом очень не стабильно. В скором времени выяснилось, что виной тому исправление безопасности MS05-019, которое интегрированно в SP1 как KB893066. К сожалению в коде этого исправления была допущена ошибка в алгоритме Path MTU Discovery (это описано в статье KB898060). Сам алгоритм PMTU Discovery подробно описан в RFC 1191. Кроме того, в RFC 2923 дано описание того, как даже корректная работа этого алгоритма может приводить к проблемам в сетевом взаимодействии.

Для начала два слова, что такое MTU – Maximum Transmission Unit. Как вы поняли из расшифровки аббревиатуры – это максимальная длина пакета IP, которая может быть передана через конкретный тип канала. Для сетей Ethernet MTU равен 1500. Для других протоколов значения MTU можно посмотреть в различных RFC или в статье MS KB140375.

Причиной сбоев алгоритма PMTU Discovery зачастую являются так называемые Black Hole Router-ы (KB159211). Что это такое – все просто, в соответствии с рекомендациями по применению протокола ICMP хостами и роутерами, в случае если при маршрутизации пакета IP он (пакет) не помещается в размер установленного MTU промежуточного участка трассы, пограничный роутер должен его фрагментировать (разбить его на несколько более мелких пакетов IP, отметив в специальном поле их заголовка очередность последующей сборки). Однако в заголовке пакета IP есть специальный флаг – don’t fragment (DF). Если этот флаг установлен никто не имеет права фрагментировать этот пакет. Если пакет по таблице маршрутизации надо передать в сеть, у которой MTU меньше размера этого пакета, а сам пакет отмечен флагом DF, то роутер не может выполнить такое задание, и обязан отбросить (удалить) такой "странный" пакет. При этом роутер может послать специальное ICMP оповещение тому хосту, IP-адрес которого указан в поле отпрвителя (Source Address) исходного пакета с флагом DF. Однако, как вы заметили, роутер вовсе не обязан отправлять это ICMP сообщение хосту-отправителю. В таком случае хост-отправитель не будет знать, о том, что его пакет пропал и не был доставлен до адресата.

Может показаться, что это безвыходная ситуация, однако если вспомнить, что при установлении TCP/IP соединения хосты обмениваются очень короткими пакетами SYN->, SYNACK<-, ACK-> длина которых настолько мала, что практически всегда меньше MTU большинства типов каналов связи, то проблема MTU проявиться уже при передаче данных в рамках открытого TCP-соединения и будет выявлена стандартным механизмом TCP. Загвоздка только в том, что данные через такой канал все равно не удастся передать.

Для решения подобных проблем был изобретен алгортм Path MTU Discovery, который если не вдаваться в детали работает очень просто: сначала хост посылает ICMP пакет получателю с максимально возможным MTU для своего сетевого интерфейса (например 1500). Если вместо ответа от хоста-адресата от промежуточного маршрутизатора пришло специальное ICMP сообщение Packet Too Big, то размер посылаемого пакета уменьшается и процедура повторяется, до тех пор, пока пакет не пройдет по всей трассе до конечного получателя.

Так что алгоритм весьма полезный, например он помогает в работе с NLB (WLBS) кластерами, как это описано в статье MS KB229064. Для NLB кластеров важно, что бы TCP пакеты приходили на общий NLB-адрес нефрагментированными, иначе высока вероятность (при стандартных настройках NLB), что разные фрагменты пакета попадут на разные узлы кластера NLB и вообще не будут обработаны.

В этой статье MS KB дано описание того, как можно эффективно настроить стек TCP/IP Windows Server 2003 для ситуации, когда на пути от хоста к хосту меняется MTU трассы и может быть даже меньше 576 байт: http://support.microsoft.com/kb/900926

Дополнительно в этой статье даются некоторые рекомендации по так называемой процедуре Hardening-а (усиления безопасности) для стека TCP/IP в реализации Microsoft Windows Server 2003: http://support.microsoft.com/kb/324270

Наконец в Windows Server 2003 SP2, Windows Vista и Windows Server 2008 работа алгоритма PMTU Discovery была немного изменена. Эти изменения описаны в статье MS KB925280.