фев 18, 2012

THE NEVER-ENDING STORY OF IP FRAGMENTATION

Впервые я столкнулся с вопросом фрагментации IP пакетов почти 15 лет назад, когда народ начал развертывать небрежно сконфигурированные фаерволлы, блокирующие весь Internet Control Messages Protocol (ICMP) трафик.  Хотелось бы надеяться, что ситуация улучшится, если сетевые архитекторы и инженеры станут опытнее, но становиться только хуже с введением новых методов инкапсуляции, таких как PPP over Ethernet (PPPoE), используемые в DSL, Ipsec шфирование и IP over IP туннели, используемые для решения проблем с маршрутизацией или реализации топологии “сервис-провайдера”.    В этой статье вы найдете причины IP фрагментации, подробное описание работы Path MTU Discovery и различных механизмов, которые можно использовать на маршрутизаторах Cisco для решения проблем с IP фрагментацией.

MTU

Основы MTU

Основной факт в области сетевых технологий, в том, что не все технологии работают на одном уровне. Одним из отличительных особенностей технологий канального layer2 уровня является максимальая полезная нагрузка передаваемого фрейма. (обычно называемый Maximum Transmission Unit - MTU). Например, обычные пакеты Ethernet могут быть до 1518 байт (в том числе CRC - байты), но они могут передать только 1500 байт полезной нагрузки если вы используйте инкапсуляцию по умолчанию.  При использовании SNAP инкапсляции размер полезной нагрузки (maximum payload блеать)  уменьшается до до 1492 байт. Token Ring и FDDI может  передавать намного большие пакеты и использовать большие размеры пакетов для уменьшения накладных расходов при выскоскоростной передаче данных в одноранговых (p2p) сетях.

Примечание.

Фреймы, большие чем 1518 байт (jumbo), применяемые в Fast Ethernet and Gigabit Ethernet environments позволили получить те же результаты.

С другой стороны, медленные последовательные линки используют меньший размер MTU чтобы уменьшить  serialization delay. Передача одного 1500-байтного пакета на 64kbps линке занимает почти 200ms. Такое поведение редко можно увидеть сегодня в связи с широким  распространением  фрагментации и чередования канала (LFI) по каналам PPP.

Инкапсуляции и туннелирования добавляют свои собственные ограничения: например, если вы используйте PPP over  Ethernet, заголовок PPPoE занимает восемь байтов из Ethernet полезной нагрузки, оставляя 1492 байт для IP пакета. Аналогично, Generic Routing Protocol (GRE) использует 24 байт заголовка, снижая MTU внутри GRE до 1476 байт. Очевидно, что сочетание различных методов инкапсуляции еще больше снижает размер MTU. MTU GRE- туннеля запущенного поверх ADSL является 1468 байт.

Технические подробности

Хотя заголовок GRE всего 4 байта (если вы не используете GRE ключ, который расширяет заголовок GRE до восьми байт), IPoverIP инкапсуляция требует дополнительный заголовок IP (20 байт), в результате 24 байта накладных расходов (overhead).  Чистый IPoverIP туннель настроенный в режиме  IPIP отнимает 20 байт.

IPSec еще больше усложняет расчеты MTU, так как размер заголовка IPSec, вставляемый в  пакет IP зависит от параметров IPSec transform sets (сочетания режима туннелирования, шифрования, использования NAT-T и паддинг 8 или 16 байтных блоков применяется.

Примечание

Оригинальная парадигма IOS, где зашифрованные пакеты проходят через тот, же интерфейс, что и зашифрованный трафик не поможет, так как MTU больше не свойство интерфейса. Размер MTU меняется в зависимости от того, зашифрован пакет или нет.

Оригинал: The never-encding story of ip fragmentation