Иногда, когда трафик проходит через GRE туннель, вы можете успешно пинговать любой хост в Интеренте, но не может просматривать Web-страницы или передавать файлы используя протокол FTP. В данном документе мы рассмотрим обычные причины этой проблемы, и предложим несколько решений. Прежде чем приступить к обсуждению данной проблемы (проблема DF бита), рекомендуем ознакомится со статьями Протокол GRE и Конфигурация GRE туннелей, чтобы иметь представление о том, что такое GRE протокол и зачем он нужен.
Фрагментация пакетов и сообщения ICMP
Рассмотрим сетевую диаграмму показанную ниже. Два роутера R1 и R2 сформировали GRE туннель.
Проблема DF бита и фрагментации в GRE туннелях
В этой диаграмме, когда Клиент желает получить доступ к web странице в Интернете, он устанавливает TCP сеанс с Web-сервером. Во время этого процесса, Клиент и Web-сервер анонсируют друг другу свой максимальный размер сегмента (Maximum Segment Size, MSS), указывая, что они могут принимать TCP сегменты вплоть до этого размера. После получения опции MSS, каждое устройство вычисляет размер сегмента, который можно послать. Это называется Посылкой Сегмента Максимального Размера (Send Max Segment Size, SMSS), и она равна наименьшему значению из двух MSS. Для нашего примера, пусть, Web-сервер решает, что он может посылать пакеты длинной до 1500 байтов. Поэтому он посылает 1500-байтовый пакет Клиенту, и, в IP заголовке он устанавливает бит DF (don't fragment), т.е. пакет не может быть фрагментирован. Когда пакет достигает R2, маршрутизатор пытается инкапсулировать его в туннельный пакет. В случае туннельного интерфейса GRE, IP MTU на 24 байта меньше чем IP MTU реального исходящего интерфейса. Для исходящего Ethernet интерфейса, это означает, что IP MTU на туннельном интерфейсе будет 1500 минус 24, или 1476 байт.
R2 пробует засунуть 1500-байтовый IP пакет в 1476-байтовый IP MTU интерфейс. Так как это не возможно, R2 должен фрагментировать пакет, создавая один пакет 1476 байт (данные и IP заголовок) и один пакет 44 байт (24 байта данных и нового IP заголовка в 20 байт). Затем R2 инкапсулирует оба этих пакета, чтобы получить пакеты размером 1500 и 68 байт, соответственно. Эти пакеты теперь могут быть отосланы через реальный интерфейс, который имеет 1500-байтовый IP MTU.
Однако, вспомним, что пакет, принятый маршрутизатором R2 имеет установленный бит DF. Таким образом, R2 не может фрагментировать пакет, и взамен, он инструктирует Web-сервер посылать пакеты меньшего размера. Он делает это, посылая Web серверу ICMP пакет типа 3 с кодом 4 (Destination Unreachable; Fragmentation Needed and DF set), что означает заданный узел не доступен, необходима фрагментация, но установлен DF бит. Это сообщение ICMP содержит правильный MTU для Web-сервера, который должен получить его и соответственно настроить размер пакета.
Мы можем посмотреть на ICMP пакеты оправляемые с R2, с помощью команды
debug ip icmp. ICMP: dst (10.10.10.10) frag. needed and DF set unreachable sent to 10.1.3.4
Обычно проблема происходит, когда сообщения ICMP блокированы по направдению к Web-серверу. Когда это случается, пакет ICMP никогда не достигает Web-сервера, таким образом, препятствуя прохождению данных между клиентом и сервером. Решить данную проблему можно любым из четырех способов:
* Выяснить где блокированы сообщения ICMP, и посмотреть можем ли мы разрешить их прохождение.
* Установить MTU на интерфейсе Клиента в 1476 байт, вынуждая SMSS быть меньшим, таким образом пакеты не должны будут фрагментироваться, когда они достигнут R2. Однако, если Вы изменяете MTU для Клиента, Вы должны также изменить MTU для всех устройств, которые находятся в этой сети с этим Клиентом. На Ethernet сегменте может находиться достаточно большое количество устройств.
* Использовать прокси-сервер между R2 и вашим шлюзом.
* Если туннель GRE работает по каналам, которые могут иметь больше MTU чем 1500 байтов плюс туннельный заголовок, то другое решение состоит в том, чтобы увеличить MTU до значения 1524 (1500 плюс 24 для GRE) на всех интерфейсах и каналах между маршрутизаторами формирующими GRE
Если вышеупомянутые варианты не выполнимы тогда нижеследующие решения могут быть полезными:
1) Использовать полиси роутинг (PBR), чтобы сбросить бит DF в IP пакетах
interface ethernet0 .. ip policy route-map clear-df route-map clear-df permit 10 match ip address 101 set ip df 0 access-list 101 permit tcp 10.1.3.0 0.0.0.255 any
Такая конфигурация позволит фрагментировать IP пакет прежде, чем он инкапсулируется в GRE. Принимающий хост должен тогда будет собрать IP пакеты из фрагментов. Это - обычно не проблема.
2. Изменить значение опции TCP MSS в SYN пакетах, которые проходят через маршрутизатор. Он уменьшит значение MSS в пакете TCP SYN так, что оно будет меньше или равным значению в команде ip tcp adjust-mss, в данном случае 1436 (MTU минус размер IP, TCP, и заголовков GRE). Теперь конечный хост будет посылать пакеты TCP/IP, не большие чем это значение.
interface tunnel0 ... ip tcp adjust-mss 1436
3. Заключительный выбор состоит в том, чтобы увеличить IP MTU на туннельном интерфейсе до значения 1500. Однако, увеличение туннельного IP MTU приведет к тому, что туннельные пакеты будут фрагментированными, потому что бит DF первоначального пакета не копируется в GRE заголовок.
В этом сценарии, маршрутизатор на другом конце GRE туннеля должен повторно собрать GRE пакет прежде, чем он может удалить заголовок GRE и переслать внутренний пакет.
interface tunnel0 ... ip mtu 1500
Сборка IP пакета выполняется на CPU и активно использует память роутера. Поэтому, этот выбор может значительно сократить пропускную способность пакетов через GRE туннель.
И в заключение, самая общая причина неспособности просматривать Интернет странички по туннелю GRE происходит из-за вышеупомянутой проблемы фрагментации. Решение состоит в том, чтобы разрешить прохождение ICMP или применить обходное решение ICMP проблемы любым из вышеупомянутых способов.
По материалам: www.cisco.com Публикация статьи с сайта разрешена только при обязательном указании источника www.ciscolab.ru
