При использовании IPSec необходима инкапсуляция пакетов, что ведет к увеличению их размеров.
Если размеры получившегося пакета превышают MTU, то маршрутизатор шифрует пакет, а затем его фрагментирует. Таким образом, принимающий маршрутизатор, должен сначала собрать все фрагменты воедино, а затем расшифровать получившийся пакет. Процесс сборки обычно происходит на process level, что серьезно влияет на производительность. По этой причине фрагментации пакетов желательно избегать, где это возможно. Существуют несколько способов решения данной проблемы. Некторые требуют настройки маршрутизаторов, другие предполагают изменение настроек на конечных клиентах и серверах.
1. Изменение MTU на конечных станциях. Возможно установить значение MTU на клиентах и серверах меньше, чем стандартное 1500 байт. Рекомендуемое в таком случае значение MTU равно 1300 байт. К сожалению, масштабы сети часто не позволяют легко и непринужденно поменять настройки на всех машинах. В таком случае, можно попробовать ограничиться серверами, т.к. по большей части именно они являются генераторами больших пакетов.
2. Path MTU Discovery
Эта фича была придумана, чтобы избежать необходимости фрагментации в принципе. Она позволяет узлам определить самое маленькое MTU на пути следования пакетов и использовать его в дальнейшем. В этом случае конечная станция шлет пакеты с выставленным битом DF (запрет на фрагментирование). Если на пути пакета попадается маршрутизатор, чей MTU меньше размеров пакетов, то этот маршрутизатор отсылает ICMP сообщение type 3, code 4 Fragmentation needed and DF set. В неиспользуемой части ICMP пакета содержится значение MTU, используемое маршрутизатором. Передающий хост может использовать это значение для корректировки собственного MTU. К сожалению, очень часто маршрутизаторы настроены подавлять отсылку ICMP сообщений type 3, например, с помощью популярной команды настройки интерфейса no ip unreachables. Лучше этого не делать, а если очень хочется, то использовать ip local route-map (разрешив отправку ICMP type 3, code4). Если, конечно, IOS поддерживает cef switching для route-map (и если cef для local route-map возможен в принципе?).
3. VPN Interface MTU
Можно подкорректировать, выставить значение 1300 на туннельном интерфейсе
ip mtu 1300
4. Look Ahead Fragmentation
Фундаментально решает проблемы фрагментации, изменив порядок фрагментации и шифрования. Получив пакет, маршрутизатор просчитывает размер пакета после инкапсуляции, и в случае превышения MTU сначала фрагментирует пакет, а затем шифрует получившиеся пакетики. Фича доступна с версии IOS 122(13)T и включена по умолчанию.
5. TCP Maximum Fragment Size
Единственный способ повлиять на размер входящего пакета в условиях, когда не удается договориться с админами на втором конце. TSP MSS определяет максимальный размер TCP сегмента, что, в конечном итоге, определяет размер пакета. Влияет, естественно, только на TCP трафик. UDP пакеты в основном не превышают 300 байт за исключением видео.
По историческим причинам (до изобретения PMTUD) MTU для хостов за пределами локальной сети был равен 1300 байт. Отсюда взялось ограничение TCP MSS в 1260 байт (1300 – 20-byte-IP-header – 20-byte-TCP-header). После внедрения PMTUD это ограничение было снято.
Каждый из хостов при установлении TCP соединения анонсирует свой MSS в SYNпакетах(необязательно совпадающие).
Команда конфигурирования интерфейса
ip tcp adjust-mss 1260
принудительно переводит поведение TCP сессий в до-PMTUD эпоху. При использовании этой команды на интерфейсе маршрутизатор переписывает значения MSS в TCP SYNпакетах, полученных на этом интерфейсе. Что, впрочем, заметно нагружает маршрутизатор.
Источник: ciao-cacao.blogspot.ru/2011/02/ipsec.html
Комментариев нет:
Отправить комментарий