Протокол IP : Универсальная инкапсуляция маршрутизации (GRE)

Решите фрагментацию IP, MTU, MSS и проблемы PMTUD с GRE и IPSEC

17 октября 2015 - Машинный перевод
Другие версии: PDF-версия:pdf | Перевод, выполненный профессиональным переводчиком (23 марта 2008) | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Цель этого документа состоит в том, чтобы представить, как Фрагментация IP и Открытие единицы передачи максимума пути (PMTUD) работают и обсуждать некоторые сценарии, включающие поведение PMTUD, когда объединено с различными комбинациями тоннелей IP. Текущее широкое использование тоннелей IP в Интернете принесло проблемы, включающие Фрагментацию IP и PMTUD к центру деятельности.

Фрагментация IP и повторная сборка

Протокол IP был разработан для использования на большом разнообразии связей передачи. Хотя максимальная длина дейтаграммы IP является 64K, большинство связей передачи проводит в жизнь меньший максимальный предел длины пакета, названный MTU. Ценность MTU зависит от типа связи передачи. Дизайн IP приспосабливает различия MTU, позволяя маршрутизаторам фрагментировать дейтаграммы IP по мере необходимости. Станция назначения ответственна за повторную сборку фрагментов назад в оригинальную дейтаграмму IP в натуральную величину.

Фрагментация IP включает ломку дейтаграммы во многие части, которые могут быть повторно собраны позже. Источник IP, место назначения, идентификация, полная длина и фрагмент возмещают области, наряду с "большим количеством фрагментов" и "не фрагментируют" флаги в заголовке IP, используются для фрагментации IP и повторной сборки. Для получения дополнительной информации о механике фрагментации IP и повторной сборки, посмотрите RFC 791 leavingcisco.com.

Изображение ниже изображает расположение заголовка IP.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-01.gif

Идентификация составляет 16 битов и является стоимостью, порученной отправителем дейтаграммы IP помочь в повторной сборке фрагментов дейтаграммы.

Погашение фрагмента составляет 13 битов и указывает, где фрагмент принадлежит оригинальной дейтаграммы IP. Эта стоимость является кратным числом восьми байтов.

В области флагов заголовка IP существует три бита для флагов контроля. Важно отметить, что "не фрагментируют" бит (DF), играет центральную роль в PMTUD, потому что это определяет, позволяют ли пакету быть фрагментированным.

Бит 0 зарезервирован и всегда устанавливается в 0. Бит 1 является битом DF (0 =, "может фрагментировать", 1 = "не фрагментируют"). Бит 2 является битом MF (0 = "последний фрагмент", 1 = "больше фрагментов").

Стоимость Укусил 0 зарезервированных Укусил 1 DF Бит 2 мФ
0 0 Май В последний раз
1 0 Не делать Больше

Диаграмма ниже шоу пример фрагментации. При складывании всех длин фрагментов IP стоимость превышает оригинальную дейтаграммную длину IP на 60. Причина, что полная длина увеличена на 60, состоит в том, потому что три дополнительных заголовка IP были созданы, один для каждого фрагмента после первого фрагмента.

Первый фрагмент имеет погашение 0, длина этого фрагмента является 1500; это включает 20 байтов для немного измененного оригинального заголовка IP.

Второй фрагмент имеет погашение 185 (185 x 8 = 1480), что означает, что часть данных этого фрагмента начинает 1480 байтов в оригинальную дейтаграмму IP. Длина этого фрагмента является 1500; это включает дополнительный заголовок IP, созданный для этого фрагмента.

Третий фрагмент имеет погашение 370 (370 x 8 = 2960), что означает, что часть данных этого фрагмента начинает 2960 байтов в оригинальную дейтаграмму IP. Длина этого фрагмента является 1500; это включает дополнительный заголовок IP, созданный для этого фрагмента.

Четвертый фрагмент имеет погашение 555 (555 x 8 = 4440), что означает, что часть данных этого фрагмента начинает 4440 байтов в оригинальную дейтаграмму IP. Длина этого фрагмента составляет 700 байтов; это включает дополнительный заголовок IP, созданный для этого фрагмента.

Это только, когда последний фрагмент получен, что может быть определен размер оригинальной дейтаграммы IP.

Погашение фрагмента в последнем фрагменте (555) дает погашение данных 4440 байтов в оригинальную дейтаграмму IP. Если вы тогда добавляете байты данных от последнего фрагмента (680 = 700 - 20), который дает вам 5120 байтов, который является частью данных оригинальной дейтаграммы IP. Затем добавление 20 байтов для заголовка IP равняется размеру оригинальной дейтаграммы IP (4440 + 680 + 20 = 5140).

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-02.gif

Проблемы с фрагментацией IP

Существует несколько проблем, которые делают нежелательного фрагментации IP. Существует маленькое увеличение CPU и памяти наверху для фрагментирования дейтаграммы IP. Это сохраняется для отправителя, а также для маршрутизатора в пути между отправителем и управляющим. Создание фрагментов просто включает заголовки фрагмента создания и копирование оригинальной дейтаграммы во фрагменты. Это может быть сделано справедливо эффективно, потому что вся информация должна была создать фрагменты, немедленно доступно.

Фрагментация вызывает более верхний для приемника при повторной сборке фрагментов, потому что приемник должен ассигновать память для прибывающих фрагментов и соединиться их назад в одну дейтаграмму после того, как получены все фрагменты. Повторную сборку на хозяине не считают проблемой, потому что у хозяина есть время и ресурсы памяти для посвящения этой задаче.

Но, повторная сборка очень неэффективна на маршрутизаторе, основная работа которого состоит в том, чтобы отправить пакеты как можно быстрее. Маршрутизатор не разработан для держаний за пакеты в течение любого отрезка времени. Также повторная сборка выполнения маршрутизатора выбирает самый большой буфер, доступный (18K), с которым можно работать, потому что это не имеет никакого способа знать размер оригинального пакета IP, пока не получен последний фрагмент.

Другая проблема фрагментации включает пропущенные фрагменты обработки. Если один фрагмент дейтаграммы IP пропущен, то вся оригинальная дейтаграмма IP должна быть, негодуют, и это будет также фрагментировано. Вы видите пример этого с Сетевой файловой системой (NFS). NFS, по умолчанию, имеет прочитанный, и напишите размер блока 8192, таким образом, NFS дейтаграмма IP/UDP составит приблизительно 8500 байтов (включая NFS, UDP и заголовки IP). Станция отправки, связанная с Ethernet (MTU 1500), должна будет фрагментировать 8500-байтовую дейтаграмму в шесть частей; пять 1500-байтовых фрагментов и один 1100-байтовый фрагмент. Если какой-либо из этих шести фрагментов пропущен из-за переполненной связи, полная оригинальная дейтаграмма должна будет быть повторно передана, что означает, что должны будут быть созданы еще шесть фрагментов. Если эта связь уронила каждый шестой пакет, то разногласия являются низкими, что любые данные NFS могут быть переданы по этой связи, так как по крайней мере один фрагмент IP был бы исключен из каждого NFS 8500-байтовая оригинальная дейтаграмма IP.

Брандмауэры, которые фильтруют или управляют пакетами, основанными на Слое 4 (L4) через Слой 7 информации (L7) в пакете, могут испытать затруднения при обработке фрагментов IP правильно. Если фрагменты IP не в порядке, брандмауэр может заблокировать неначальные фрагменты, потому что они не несут информацию, которая соответствовала бы фильтру пакета. Это означало бы, что оригинальная дейтаграмма IP не могла быть повторно собрана хозяином получения. Если брандмауэр формируется, чтобы позволить неначальным фрагментам с недостаточной информацией должным образом соответствовать фильтру, то неначальное нападение фрагмента через брандмауэр могло произойти. Кроме того, некоторые сетевые устройства (такие как Двигатели Выключателя Содержания) прямые пакеты, основанные на L4 через информацию L7, и если пакет охватывает многократные фрагменты, то устройство может испытать затруднения при предписании ее политики.

Предотвращение фрагментации IP: что делает MSS TCP и как это работает

Максимальный размер сегмента (MSS) TCP определяет максимальный объем данных, который хозяин готов принять в единственной дейтаграмме TCP/IP. Эта дейтаграмма TCP/IP может быть фрагментирована в слое IP. Стоимость MSS посылают как выбор заголовка TCP только в TCP SYN сегменты. Каждая сторона связи TCP сообщает о своей стоимости MSS другой стороне. Противоречащий широко распространенному мнению, о стоимости MSS не договариваются между хозяевами. Хозяин отправки обязан ограничивать размер данных в единственном сегменте TCP к стоимости, меньше чем или равной MSS, о котором сообщает хозяин получения.

Первоначально, MSS означал, как большой буфер (больше, чем или равный 65496K) был ассигнован на станции назначения, чтобы быть в состоянии хранить данные TCP, содержавшие в пределах единственной дейтаграммы IP. MSS Был максимальным сегментом (кусок) данных, которые приемник TCP был готов принять. Этот сегмент TCP мог быть столь же большим как 64K (максимальный дейтаграммный размер IP), и это могло быть фрагментировано в слое IP, чтобы быть переданным по сети хозяину получения. Хозяин получения повторно собрал бы дейтаграмму IP, прежде чем она вручила полный сегмент TCP слою TCP.

Ниже несколько сценариев, показывающих, как ценности MSS устанавливаются и используются для ограничения размеров сегмента TCP, и поэтому, дейтаграммных размеров IP.

Сценарий 1 иллюстрирует способ, которым был сначала осуществлен MSS. У хозяина А есть буфер 16K и Хозяина Б буфер 8K. Они посылают и получают свои ценности MSS и регулируют их посылать MSS для отправки данных друг другу. Заметьте, что Хозяин А и Хозяин Б должны будут фрагментировать дейтаграммы IP, которые больше, чем интерфейс MTU, но еще меньше, чем послать MSS, потому что стек TCP мог передать 16K или 8K байты данных вниз стек к IP. В случае Хозяина Б пакеты могли быть фрагментированы дважды, однажды чтобы получить на Маркерное кольцо LAN и снова получить на Ethernet LAN.

Сценарий 1

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-03.gif

  1. Хозяин А посылает его ценность MSS 16K Хозяину Б.

  2. Хозяин Б получает 16K стоимость MSS от Хозяина А.

  3. Хозяин Б устанавливает посылать стоимость MSS в 16K.

  4. Хозяин Б посылает его ценность MSS 8K Хозяину А.

  5. Хозяин А получает 8K стоимость MSS от Хозяина Б.

  6. Примите наборы посылать стоимость MSS в 8K.

Для помощи в предотвращении фрагментации IP в конечных точках связи TCP выбор стоимости MSS был изменен на минимальный размер буфера и MTU коммуникабельного интерфейса (-40). Числа MSS на 40 байтов меньше, чем числа MTU, потому что MSS является просто размером данных TCP, который не включает 20-байтовый заголовок IP и 20-байтовый заголовок TCP. MSS основан на размерах заголовка по умолчанию; стек отправителя должен вычесть соответствующие ценности для заголовка IP и заголовка TCP в зависимости от того, какой TCP или варианты IP используются.

Путем MSS теперь работает, то, что каждый хозяин сначала сравнит его коммуникабельное взаимодействие MTU с его собственным буфером и выберет самую низкую стоимость в качестве MSS для отправки. Хозяева тогда сравнят размер MSS, полученный с их собственным интерфейсом MTU, и снова выберут ниже двух ценностей.

Сценарий 2 иллюстрирует этот дополнительный шаг, сделанный отправителем для предотвращения фрагментации на местных и отдаленных проводах. Заметьте, как MTU коммуникабельного интерфейса принят во внимание каждым хозяином (прежде чем хозяева пошлют друг другу свои ценности MSS), и как это помогает избежать фрагментации.

Сценарий 2

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-04.gif

  1. Хозяин А сравнивает его буфер MSS (16K) и его MTU (1500 - 40 = 1460) и использует нижнее значение в качестве MSS (1460), чтобы послать Хозяину Б.

  2. Хозяин Б принимает Хозяина А, посылают MSS (1460), и сравнивает его с ценностью его интерфейса MTU за границу - 40 (4422).

  3. Хозяин Б устанавливает нижнее значение (1460) как MSS для отправки дейтаграмм IP Хозяину А.

  4. Хозяин Б сравнивает его буфер MSS (8K) и его MTU (4462-40 = 4422) и использует 4422 в качестве MSS, чтобы послать Хозяину А.

  5. Хозяин А принимает Хозяина Б, посылают MSS (4422), и сравнивает его с ценностью его интерфейса MTU за границу-40 (1460).

  6. Примите наборы нижнее значение (1460) как MSS для отправки дейтаграмм IP Хозяину Б.

1460 является стоимостью, выбранной обоими хозяевами в качестве послать MSS друг для друга. Часто послать стоимость MSS будет тем же самым на каждом конце связи TCP.

В Сценарии 2 фрагментация не происходит в конечных точках связи TCP, потому что оба коммуникабельных интерфейса MTUs приняты во внимание хозяевами. Пакеты могут все еще стать фрагментированными в сети между Маршрутизатором A и Маршрутизатором B, если они сталкиваются со связью с более низким MTU, чем тот из интерфейса любых хозяев за границу.

Что такое PMTUD?

MSS TCP, как описано выше заботится о фрагментации в двух конечных точках связи TCP, но она не обращается со случаем, где существует меньшая связь MTU в середине между этими двумя конечными точками. PMTUD был развит для предотвращения фрагментации в пути между конечными точками. Это используется для динамичного определения самого низкого MTU вдоль пути от источника пакета до его места назначения.

Примечание: PMTUD только поддержан TCP. UDP и другие протоколы не поддерживают его. Если PMTUD будет позволен на хозяине, и это почти всегда, то все пакеты TCP/IP от хозяина будут иметь набор сверл DF.

Когда хозяин посылает полный пакет данных MSS с набором сверл DF, работами PMTUD путем сокращения послать стоимости MSS для связи, если бы это получает информацию, что пакет потребовал бы фрагментации. Хозяин обычно "помнит" стоимость MTU за место назначения путем создания "хозяина" (/32) вход в его таблице маршрутизации с этой стоимостью MTU.

Если маршрутизатор попытается отправить дейтаграмму IP, с набором сверл DF, на связь, которая имеет более низкий MTU, чем размер пакета, то маршрутизатор уронит пакет и возвратит Интернет-протокол сообщения контроля (ICMP) "Место назначения Недостижимое" сообщение к источнику этой дейтаграммы IP, с кодексом, указывающим "на необходимую фрагментацию и набор DF" (тип 3, код 4). Когда исходная станция получит сообщение ICMP, она понизит послать MSS, и когда TCP повторно передаст сегмент, она будет использовать меньший размер сегмента.

Вот является пример ICMP "необходимой фрагментацией и сообщение" набора DF, что вы могли бы видеть на маршрутизаторе после включения IP отладки icmp команду:

ICMP: dst (10.10.10.10) frag. needed and DF set 
unreachable sent to 10.1.1.1

Диаграмма ниже показывает формат заголовка ICMP "необходимой фрагментации и набор DF" "Место назначения Недостижимое" сообщение.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-05.gif

В 1191 RFC leavingcisco.comмаршрутизатор, возвращая сообщение ICMP, указывающее "на необходимую фрагментацию и набор DF", должен включать MTU той сети следующего перелета в 16 битах младшего разряда дополнительной области заголовка ICMP, которая маркирована "неиспользованной" в спецификации RFC 792 ICMP leavingcisco.com.

Ранние внедрения 1191 RFC не поставляли следующего перелета информация о MTU. Даже когда эта информация была предоставлена, некоторые хозяева игнорируют ее. Для этого случая RFC 1191 также содержит стол, который перечисляет предложенные ценности, которыми MTU должен быть понижен во время PMTUD. Это используется хозяевами для прибытия более быстро в рыночную стоимость для послать MSS.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-06.gif

PMTUD делается все время на всех пакетах, потому что путь между отправителем и управляющим может измениться динамично. Каждый раз отправитель получает, "не Может Фрагментировать" сообщения ICMP, это обновит информацию о направлении (где это хранит PMTUD).

Две возможных вещи могут произойти во время PMTUD:

  • Пакет может добраться полностью до приемника без того, чтобы быть фрагментированным.

    Примечание: Для маршрутизатора для защиты CPU от нападений DoS это душит число недостижимых сообщений ICMP, что это послало бы, к два в секунду. Поэтому, в этом контексте, если у вас есть сетевой сценарий, в котором вы ожидаете, что маршрутизатор должен был бы ответить больше чем двумя ICMP (кодекс = 3, напечатайте = 4), в секунду (могут быть различные хозяева), вы хотели бы отключить удушение сообщений ICMP ни с каким IP icmp ограничение скорости, недостижимое [df] интерфейсная команда.

  • Отправитель может добраться, ICMP "не Может Фрагментировать" сообщения ни от кого (или каждый) перелет вдоль пути к приемнику.

PMTUD сделан независимо для обоих направлений потока TCP. Могут быть случаи, где PMTUD в одном направлении потока вызывает одну из станций конца для понижения послать MSS, и другая станция конца держит оригинал, посылают MSS, потому что это никогда не посылало дейтаграмму IP, достаточно большую для вызова PMTUD.

Хорошим примером этого является связь HTTP, изображенная ниже в Сценарии 3. Клиент TCP посылает маленькие пакеты, и сервер посылает большие пакеты. В этом случае только серверы большие пакеты (больше, чем 576 байтов) вызовут PMTUD. Пакеты клиента являются маленькими (меньше чем 576 байтов) и не вызовут PMTUD, потому что они не требуют, чтобы фрагментация объяснила связь на 576 метрических тонн.

Сценарий 3

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-07.gif

Сценарий 4 показывает асимметричный пример направления, где один из путей имеет меньший минимальный MTU, чем другой. Когда различные пути взяты для отправки и получения данных между двумя конечными точками, асимметричное направление происходит. В этом сценарии PMTUD вызовет понижение послать MSS только в одном направлении потока TCP. Движение от клиента TCP к серверу течет через Маршрутизатор A и Маршрутизатор B, тогда как движение возвращения, прибывающее от сервера до клиента, течет через Маршрутизатор D и Маршрутизатор C. Когда сервер TCP пошлет пакеты клиенту, PMTUD вызовет сервер для понижения послать MSS, потому что Маршрутизатор D должен фрагментировать 4092-байтовые пакеты, прежде чем это сможет послать их в Маршрутизатор C.

Клиент, с другой стороны, никогда не будет получать ICMP "Место назначения Недостижимое" сообщение с кодексом, указывающим "на необходимую фрагментацию и набор DF", потому что Маршрутизатор A не должен фрагментировать пакеты при отправке в сервер через Маршрутизатор B.

Сценарий 4

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-08.gif

Примечание: IP tcp path-mtu-discovery команда используется для предоставления возможности TCP MTU открытие пути для связей TCP, начатых маршрутизаторами (BGP и TELNET, например).

Проблемы с PMTUD

Существует три вещи, которые могут сломать PMTUD, два из которых необычны и один из которых распространен.

  • Маршрутизатор может уронить пакет и не послать сообщение ICMP. (Необычный)

  • Маршрутизатор может произвести и послать сообщение ICMP, но сообщение ICMP заблокировано маршрутизатором или брандмауэром между этим маршрутизатором и отправителем. (Распространенный)

  • Маршрутизатор может произвести и послать сообщение ICMP, но отправитель игнорирует сообщение. (Необычный)

Первые и последние из этих трех пуль выше необычны и обычно являются результатом ошибки, но средняя пуля описывает обычную проблему. Люди, которые осуществляют фильтры пакета ICMP, склонны блокировать все типы сообщения ICMP, а не только блокирование определенных типов сообщения ICMP. Фильтр пакета может заблокировать все типы сообщения ICMP кроме тех, которые "недостижимы" или "превышены временем". Успех или провал PMTUD зависит от недостижимых сообщений ICMP, проходящих отправителю пакета TCP/IP. ICMP превышенные временем сообщения важны для других проблем IP. Пример такого фильтра пакета, осуществленного на маршрутизаторе, показывают ниже.

access-list 101 permit icmp any any unreachable
access-list 101 permit icmp any any time-exceeded
access-list 101 deny icmp any any
access-list 101 permit ip any any

Существуют другие методы, которые могут использоваться, чтобы помочь облегчить проблему ICMP быть полностью заблокированным.

  • Очиститесь DF обдумал маршрутизатор, и позвольте фрагментацию так или иначе (Это может не быть хорошей идеей, все же. Посмотрите Проблемы с Фрагментацией IP для получения дополнительной информации).

  • Управляйте стоимостью выбора MSS TCP, которую MSS с помощью интерфейсного IP команды tcp регулирует-mss <500-1460>.

В Сценарии 5 ниже, Маршрутизатор A и Маршрутизатор B находятся в той же самой административной области. Маршрутизатор C недоступен и блокирует ICMP, таким образом, сломан PMTUD. Работа для этой ситуации должна очистить бит DF в обоих направлениях на Маршрутизаторе B для разрешения фрагментации. Это может быть сделано с помощью стратегического направления. Синтаксис для прояснения бита DF доступен в Cisco Выпуск 12.1 (6) программного обеспечения IOS� и позже.

interface serial0 
... 
ip policy route-map clear-df-bit 
route-map clear-df-bit permit 10 
	match ip address 111 
	set ip df 0 
 
access-list 111 permit tcp any any

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-09.gif

Другой выбор состоит в том, чтобы изменить стоимость выбора MSS TCP на пакетах SYN, которые пересекают маршрутизатор (доступный в Cisco IOS 12.2 (4) T и позже). Это уменьшает стоимость выбора MSS в TCP SYN пакет так, чтобы это было меньше, чем стоимость (1460) в IP tcp регулирует-mss команду. Результат состоит в том, что отправитель TCP пошлет сегменты, не больше, чем эта стоимость. Размер пакета IP будет на 40 байтов больше (1500), чем стоимость MSS (1460 байтов) для составления заголовка TCP (20 байтов) и заголовка IP (20 байтов).

Можно приспособить MSS TCP SYN, пакеты с IP tcp регулируют-mss команду. Следующий синтаксис уменьшит стоимость MSS на сегментах TCP к 1460. Это движение эффектов команды, и прибывающее и за границу в интерфейсе serial0.

int s0 
ip tcp adjust-mss 1460

Проблемы фрагментации IP стали более широко распространенными, так как тоннели IP стали более широко развернутыми. Причина, что тоннели вызывают больше фрагментации, состоит в том, потому что туннельная герметизация добавляет "наверху" к размеру пакет. Например, добавление Универсальной герметизации маршрутизатора (GRE) добавляет 24 байта к пакету, и после этого увеличения пакет, возможно, должен быть фрагментирован, потому что это больше тогда MTU за границу. В более поздней части этого документа вы будете видеть примеры видов проблем, которые могут возникнуть с фрагментацией IP и тоннелями.

Общая Сетевая Топология та Потребность PMTUD

PMTUD необходим в сетевых ситуациях, где промежуточные связи имеют меньший MTUs, чем MTU связей конца. Некоторые общие причины существования этих меньших связей MTU:

  • Маркерное кольцо (или FDDI) - соединило хозяев конца с соединением Ethernet между ними. Маркерное кольцо (или FDDI) MTUs в концах больше тогда Ethernet MTU в середине.

  • PPPoE (часто используемый с ADSL) нуждается в 8 байтах для своего заголовка. Это уменьшает эффективный MTU Ethernet к 1492 (1500 - 8).

Протоколы туннелирования как GRE, IPsec и L2TP также нуждаются в пространстве для своих соответствующих заголовков и трейлеров. Это также уменьшает эффективный MTU коммуникабельного интерфейса.

В следующих разделах мы изучим воздействие PMTUD, где протокол туннелирования используется где-нибудь между двумя хозяевами конца. Из этих трех случаев выше этого случая является самым сложным, охватывая все проблемы, которые вы могли бы видеть в других случаях.

Что такое тоннель?

Тоннель является логическим интерфейсом на маршрутизаторе Cisco, который обеспечивает способ заключить в капсулу пассажирские пакеты в транспортном протоколе. Это - архитектура, разработанная для предоставления услуг для осуществления двухточечной схемы герметизации. Туннелирование имеет следующие три основных компонента:

  • Пассажирский протокол (AppleTalk, Баньян VINES, CLNS, DECnet, IP или IPX)

  • Протокол перевозчика - Один из следующих протоколов герметизации:

    • GRE - Протокол перевозчика мультипротокола Cisco. Посмотрите RFC 2784 leavingcisco.com и 1701 RFC leavingcisco.com для получения дополнительной информации.

    • IP в тоннелях IP - Видит 2003 RFC leavingcisco.com для получения дополнительной информации.

  • Транспортный протокол - протокол раньше нес скрытый протокол

Пакеты ниже иллюстрируют понятия туннелирования IP, где GRE является протоколом герметизации, и IP является транспортным протоколом. Пассажирским протоколом является также IP. В этом случае IP является и транспортом и пассажирским протоколом.

Нормальный пакет

IP TCP TELNET

Туннельный пакет

IP GRE IP TCP TELNET

  • IP является транспортным протоколом.

  • GRE является протоколом герметизации.

  • IP является пассажирским протоколом.

Следующий пример показывает герметизацию IP и DECnet как пассажирские протоколы с GRE как перевозчик. Это иллюстрирует факт, что протокол перевозчика может заключить в капсулу многократные пассажирские протоколы.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-10.gif

Сетевой администратор мог бы рассмотреть туннелирование в ситуации, где существует две разобщенных сети неIP, отделенные основой IP. Если разобщенные сети управляют DECnet, администратор может не хотеть соединять их вместе путем формирования DECnet в основе. Администратор может не хотеть разрешать направлению DECnet потреблять полосу пропускания основы, потому что это могло вмешаться в исполнение сети IP.

Жизнеспособной альтернативой является к тоннелю DECnet по основе IP. Туннелирование заключает в капсулу пакеты DECnet в IP и посылает их через основу к туннельной конечной точке, куда герметизация удалена, и пакеты DECnet могут быть разбиты это их место назначения через DECnet.

Заключение в капсулу движения в другом протоколе обеспечивает следующие преимущества:

  • Конечные точки используют частные адреса (RFC 1918 leavingcisco.com), и основа не поддерживает направление эти адреса.

  • Позвольте виртуальные частные сети (VPNs) через WANs или Интернет.

  • Объединитесь разобщенные сети мультипротокола по основе единственного протокола.

  • Зашифруйте движение по основе или Интернету.

Для остальной части документа мы будем использовать IP в качестве пассажирского протокола и IP как транспортный протокол.

Соображения относительно туннельных интерфейсов

Следующее является соображениями когда туннелирование.

  • Быстро переключение тоннелей GRE было введено в Cisco IOS Выпуск 11.1, и переключение CEF было введено в версии 12.0. CEF, переключающийся для многоточечных тоннелей GRE, был введен в версии 12.2 (8) T. Герметизация и de-герметизация в туннельных конечных точках были медленными операциями в более ранних версиях IOS, когда только обрабатывают переключение, был поддержан.

  • Существует безопасность и проблемы топологии когда пакеты туннелирования. Тоннели могут обойти списки контроля доступа (ACLs) и брандмауэры. Если вы тоннель через брандмауэр, вы в основном обходите брандмауэр для любого пассажирского протокола, вы - туннелирование. Поэтому рекомендуется включать функциональность брандмауэра в туннельные конечные точки для предписания любой политики по пассажирским протоколам.

  • Туннелирование могло бы создать проблемы с транспортными протоколами, которые ограничили таймеры (например, DECnet) из-за увеличенного времени ожидания

  • Туннелирование через окружающую среду с различными связями скорости, как быстрые кольца FDDI и через медленные телефонные линии на 9600 бит/с, может ввести проблемы переупорядочения пакета. Некоторые пассажирские протоколы функционируют плохо в сетях мультимедиа.

  • Двухточечные тоннели могут израсходовать полосу пропускания на физической связи. Если вы управляете протоколами маршрутизации по многократным двухточечным тоннелям, имеете в виду, что каждый туннельный интерфейс имеет полосу пропускания и что физический интерфейс, по которому туннельные пробеги имеет полосу пропускания. Например, если бы было 100 тоннелей, переезжающих связь на 10 МБ, вы хотели бы установить туннельную полосу пропускания в 100 КБ. Полоса пропускания по умолчанию для тоннеля составляет 9 КБ.

  • Протоколы маршрутизации могут предпочесть тоннель по "реальной" связи, потому что тоннель, могло бы обманчиво казаться, был бы связью с одним перелетом с самым дешевым путем, хотя это фактически включает больше перелетов и является действительно более дорогостоящим, чем другой путь. Это может быть смягчено с надлежащей конфигурацией протокола маршрутизации. Вы могли бы хотеть рассмотреть управление различным протоколом маршрутизации по туннельному интерфейсу, чем протокол маршрутизации, бегущий в физическом интерфейсе.

  • Проблем с рекурсивным направлением можно избежать путем формирования соответствующих статических маршрутов к туннельному месту назначения. Когда лучший путь к "туннельному месту назначения" через сам тоннель, рекурсивный маршрут. Эта ситуация заставит туннельный интерфейс подпрыгивать вверх и вниз. Когда будет рекурсивная проблема направления, вы будете видеть следующую ошибку.

    %TUN-RECURDOWN Interface Tunnel 0
    temporarily disabled due to recursive routing

Маршрутизатор как участник PMTUD в конечной точке тоннеля

Маршрутизатор имеет две различных роли PMTUD для игры, когда это - конечная точка тоннеля.

  • В первой роли маршрутизатор является экспедитором пакета хозяина. Для обработки PMTUD маршрутизатор должен проверить, что DF укусил и размер пакета оригинального пакета данных и принял соответствующие меры при необходимости.

  • Вторая роль играет роль после того, как маршрутизатор заключил в капсулу оригинальный пакет IP в туннельном пакете. На данном этапе маршрутизатор действует больше как хозяин относительно PMTUD и в отношении тоннеля пакет IP.

Позволяет началу путем взгляда на то, что происходит, когда маршрутизатор действует в первой роли, маршрутизатор, отправляя хозяину пакеты IP, относительно PMTUD. Эта роль играет роль, прежде чем маршрутизатор заключает в капсулу хозяина пакет IP в туннельном пакете.

Если маршрутизатор будет участвовать как экспедитор пакета хозяина, то он сделает следующее:

  • Проверьте, укусил ли DF, установлен.

  • Проверьте, какой пакет размера тоннель может приспособить.

  • Фрагмент (если пакет является слишком большим и DF, укусил, не установлен), заключите в капсулу фрагменты и пошлите; или

  • Уроните пакет (если пакет является слишком большим, и DF укусил, установлен), и пошлите сообщение ICMP отправителю.

  • Заключите в капсулу (если пакет не является слишком большим), и послать.

В общем существует выбор герметизации и затем фрагментации (отправка двух фрагментов герметизации) или фрагментации и затем герметизации (отправка двух скрытых фрагментов).

Ниже некоторые примеры, которые описывают механику герметизации пакета IP и фрагментации и двух сценариев, которые показывают взаимодействие PMTUD и пакетов, пересекающих сети в качестве примера.

Первый пример ниже показывает то, что происходит с пакетом, когда маршрутизатор (в туннельном источнике) действует в роли отправления маршрутизатора. Помните, что для обработки PMTUD, маршрутизатор должен проверить, что DF укусил и размер пакета оригинального пакета данных и принял соответствующие меры. Это примеры использует герметизацию GRE для тоннеля. Как видно ниже, GRE делает фрагментацию перед герметизацией. Более поздние примеры показывают сценарии, в которых фрагментация сделана после герметизации.

В Примере 1, DF укусил, не установлен (DF = 0) и тоннель GRE IP, MTU является 1476 (1500 - 24).

Пример 1

  1. Посылаемый маршрутизатор (в туннельном источнике) получает 1500-байтовую дейтаграмму с ясным битом DF (DF = 0) от хозяина отправки. Эта дейтаграмма составлена из 20-байтового заголовка IP плюс 1480-байтовый полезный груз TCP.

    IP 1480-байтовый TCP + данные

  2. Поскольку пакет будет слишком большим для IP MTU после того, как GRE, верхний (24 байта), будет добавлен, посылаемый маршрутизатор ломает дейтаграмму в два фрагмента 1476 (20-байтовый заголовок IP + 1456-байтовый полезный груз IP) и 44 байта (20 байтов заголовка IP + 24 байта полезного груза IP) поэтому после того, как герметизация GRE будет добавлена, пакет не будет больше, чем коммуникабельный физический интерфейс MTU.

    IP0 1456-байтовый TCP + данные

    IP1 24-байтовые данные

  3. Посылаемый маршрутизатор добавляет герметизацию GRE, которая включает 4-байтовый заголовок GRE плюс 20-байтовый заголовок IP к каждому фрагменту оригинальной дейтаграммы IP. Эти две дейтаграммы IP теперь имеют длину 1500 и 68 байтов, и эти дейтаграммы замечены как отдельные дейтаграммы IP не как фрагменты.

    IP GRE IP0 1456-байтовый TCP + данные

    IP GRE IP1 24-байтовые данные

  4. Туннельный маршрутизатор назначения удаляет герметизацию GRE из каждого фрагмента оригинальной дейтаграммы, оставляя два фрагмента IP длин 1476 и 24 байтами. Эти дейтаграммные фрагменты IP будут отправлены отдельно этим маршрутизатором хозяину получения.

    IP0 1456-байтовый TCP + данные

    IP1 24-байтовые данные

  5. Хозяин получения повторно соберет эти два фрагмента в оригинальную дейтаграмму.

    IP 1480-байтовый TCP + данные

Сценарий 5 изображает роль посылаемого маршрутизатора в контексте сетевой топологии.

В следующем примере маршрутизатор действует в той же самой роли отправления маршрутизатора, но на сей раз DF укусил, установлен (DF = 1).

Пример 2

  1. Посылаемый маршрутизатор в туннельном источнике получает 1500-байтовую дейтаграмму с DF = 1 от хозяина отправки.

    IP 1480-байтовый TCP + данные

  2. Так как DF укусил, установлен, и дейтаграммный размер (1500 байтов) больше, чем тоннель GRE IP MTU (1476), маршрутизатор пропустит дейтаграмму и пошлет "фрагментации ICMP необходимый но набор сверл DF" сообщение к источнику дейтаграммы. Сообщение ICMP приведет в готовность отправителя, что MTU является 1476.

    IP ICMP MTU 1476

  3. Хозяин отправки получает сообщение ICMP, и когда оно отправит оригинальные данные, оно будет использовать 1476-байтовую дейтаграмму IP.

    IP 1456-байтовый TCP + данные

  4. Этой дейтаграммной длиной IP (1476 байтов) является теперь равной стоимости к тоннелю GRE IP MTU, таким образом, маршрутизатор добавляет герметизацию GRE к дейтаграмме IP.

    IP GRE IP 1456-байтовый TCP + данные

  5. Маршрутизатор получения (в туннельном месте назначения) удаляет герметизацию GRE дейтаграммы IP и посылает его хозяину получения.

    IP 1456-байтовый TCP + данные

Теперь мы можем посмотреть на то, что происходит, когда маршрутизатор действует во второй роли хозяина отправки относительно PMTUD и в отношении тоннеля пакет IP. Вспомните, что эта роль играет роль после того, как маршрутизатор заключил в капсулу оригинальный пакет IP в туннельном пакете.

Примечание: По умолчанию маршрутизатор не делает PMTUD на туннельных пакетах GRE, которые это производит. Тоннель path-mtu-discovery команда может использоваться для включения PMTUD для туннельных пакетов GRE-IP.

Ниже пример того, что происходит, когда хозяин посылает дейтаграммы IP, которые являются достаточно маленькими для установки в пределах IP MTU в интерфейсе GRE Tunnel. DF укусил, в этом случае может быть или установлен или ясный (1 или 0). Туннельный интерфейс GRE не имеет тоннеля path-mtu-discovery командой формируемый, таким образом, маршрутизатор не будет делать PMTUD на пакете GRE-IP.

Пример 3

  1. Посылаемый маршрутизатор в туннельном источнике получает 1476-байтовую дейтаграмму от хозяина отправки.

    IP 1456-байтовый TCP + данные

  2. Этот маршрутизатор заключает в капсулу 1476-байтовую дейтаграмму IP в GRE для получения 1500-байтового GRE дейтаграмма IP. Бит DF в заголовке IP GRE будет ясен (DF = 0). Этот маршрутизатор тогда вперед этот пакет к туннельному месту назначения.

    IP GRE IP 1456-байтовый TCP + данные

  3. Предположите, что существует маршрутизатор между туннельным источником и местом назначения со связью MTU 1400. Этот маршрутизатор фрагментирует туннельный пакет, так как DF укусил, ясно (DF = 0). Помните, что этот пример фрагментирует наиболее удаленный IP, таким образом, GRE, внутренний IP и заголовки TCP только обнаружатся в первом фрагменте.

    IP0 GRE IP 1352-байтовый TCP + данные

    IP1 104-байтовые данные

  4. Туннельный маршрутизатор назначения должен повторно собрать туннельный пакет GRE.

    IP GRE IP 1456-байтовый TCP + данные

  5. После того, как туннельный пакет GRE повторно собран, маршрутизатор удаляет заголовок IP GRE и посылает оригинальную продвигающуюся дейтаграмму IP.

    IP 1456-байтовый TCP + данные

Следующий пример показывает то, что происходит, когда маршрутизатор действует в роли хозяина отправки относительно PMTUD и в отношении тоннеля пакет IP. На сей раз DF укусил, установлен (DF = 1) в оригинальном заголовке IP, и мы формировали тоннель path-mtu-discovery команда так, чтобы DF укусил, будет скопирован от внутреннего заголовка IP до внешнего (GRE + IP) заголовок.

Пример 4

  1. Посылаемый маршрутизатор в туннельном источнике получает 1476-байтовую дейтаграмму с DF = 1 от хозяина отправки.

    IP 1456-байтовый TCP + данные

  2. Этот маршрутизатор заключает в капсулу 1476-байтовую дейтаграмму IP в GRE для получения 1500-байтового GRE дейтаграмма IP. Этот заголовок IP GRE будет иметь набор сверл DF (DF = 1), так как оригинальная дейтаграмма IP имела набор сверл DF. Этот маршрутизатор тогда вперед этот пакет к туннельному месту назначения.

    IP GRE IP 1456-байтовый TCP

  3. Снова, предположите, что существует маршрутизатор между туннельным источником и местом назначения со связью MTU 1400. Этот маршрутизатор не фрагментирует туннельный пакет, так как DF укусил, установлен (DF = 1). Этот маршрутизатор должен уронить пакет и послать сообщение об ошибке ICMP в туннельный исходный маршрутизатор, так как это - исходный IP-адрес на пакете.

    IP ICMP MTU 1400

  4. Посылаемый маршрутизатор в туннельном источнике получает это сообщение об ошибке ICMP, и это понизит тоннель GRE IP MTU к 1376 (1400 - 24). В следующий раз, когда хозяин отправки повторно передает данные в 1476-байтовом пакете IP, этот пакет будет слишком большим, и этот маршрутизатор пошлет сообщение об ошибке ICMP отправителю со стоимостью MTU 1376. Когда хозяин отправки повторно передаст данные, они пошлют его в 1376-байтовом пакете IP, и этот пакет сделает их через тоннель GRE хозяину получения.

Сценарий 5

Этот сценарий иллюстрирует фрагментацию GRE. Помните, что вы фрагментируете перед герметизацией для GRE, затем сделайте PMTUD для пакета данных, и DF укусил, не скопирован, когда пакет IP заключен в капсулу GRE. В этом сценарии DF укусил, не установлен. Туннельный интерфейс IP MTU GRE - по умолчанию, 24 байта меньше, чем физический интерфейс IP MTU, таким образом, интерфейс GRE IP MTU является 1476.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-11.gif

  1. Отправитель посылает 1500-байтовый пакет (20-байтовый заголовок IP + 1480 байтов полезного груза TCP).

  2. Так как MTU тоннеля GRE является 1476, 1500-байтовый пакет сломан в два фрагмента IP 1476 и 44 байтов, каждого в ожидании дополнительных 24 byes заголовка GRE.

  3. 24 байта заголовка GRE добавлены к каждому фрагменту IP. Теперь фрагменты являются 1500 (1476 + 24) и 68 (44 + 24) байты каждый.

  4. GRE + пакеты IP, содержащие два фрагмента IP, отправлены туннельному пэру GRE маршрутизатор.

  5. Туннельный пэр GRE маршрутизатор удаляет заголовки GRE из этих двух пакетов.

  6. Этот маршрутизатор вперед эти два пакета к конечному хосту.

  7. Конечный хост повторно собирает фрагменты IP назад в оригинальную дейтаграмму IP.

Сценарий 6

Это - сценарий подобное Сценарию 5, но на сей раз DF укусил, установлен. В Сценарии 6 маршрутизатор формируется, чтобы сделать PMTUD на GRE + туннельные пакеты IP с тоннелем path-mtu-discovery команда, и DF укусил, скопирован от оригинального заголовка IP до заголовка IP GRE. Если маршрутизатор получает ошибку ICMP для GRE + пакет IP, это уменьшает IP MTU в туннельном интерфейсе GRE. Снова, помните, что Тоннель GRE IP, MTU установлен в 24 байта меньше, чем физический интерфейс MTU по умолчанию, таким образом, IP GRE MTU здесь является 1476. Также заметьте, что существует связь на 1400 метрических тонн в туннельном пути GRE.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-12.gif

  1. Маршрутизатор получает 1500-байтовый пакет (20-байтовый заголовок IP + полезный груз TCP 1480 года), и это уронило пакет. Маршрутизатор уронил пакет, потому что это больше тогда IP MTU (1476) в туннельном интерфейсе GRE.

  2. Маршрутизатор посылает ошибку ICMP отправителю, говорящему его, что следующий перелет MTU является 1476. Хозяин сделает запись этой информации, обычно как маршрут хозяина для места назначения в его таблице маршрутизации.

  3. Хозяин отправки использует 1476-байтовый размер пакета, когда он отправляет данные. Маршрутизатор GRE добавляет 24 байта герметизации GRE и посылает 1500-байтовый пакет.

  4. 1500-байтовый пакет не может пересечь 1400-байтовую связь, таким образом, это пропущено промежуточным маршрутизатором.

  5. Промежуточный маршрутизатор посылает ICMP (кодекс = 3, напечатайте = 4) к маршрутизатору GRE со следующим перелетом MTU 1400. Маршрутизатор GRE уменьшает это до 1376 (1400 - 24) и устанавливает внутренний IP стоимость MTU в интерфейсе GRE. Это изменение может только быть замечено при использовании туннельной команды отладки; это не может быть замечено в продукции по выставочному тоннелю интерфейса IP <#> команда.

  6. В следующий раз, когда хозяин отправляет 1476-байтовый пакет, маршрутизатор GRE уронит пакет, так как это больше тогда текущий IP MTU (1376) в туннельном интерфейсе GRE.

  7. Маршрутизатор GRE пошлет другой ICMP (кодекс = 3, напечатайте = 4) отправителю со следующим перелетом, MTU 1376 и хозяина обновит свою текущую информацию с новой стоимостью.

  8. Хозяин снова отправляет данные, но теперь в меньшем 1376-байтовом пакете, GRE добавит 24 байта герметизации и отправит ее на. На сей раз пакет сделает это туннельному пэру GRE, где пакет будет de-capsulated и посланный в конечный хост.

    Примечание: Если тоннель path-mtu-discovery команда не формировался на посылаемом маршрутизаторе в этом сценарии, и DF укусил, был установлен в пакетах, отправленных через тоннель GRE, Хозяин 1 все еще преуспеет в том, чтобы послать пакеты TCP/IP для Оказания гостеприимства 2, но они фрагментировать в середине в связи на 1400 метрических тонн. Также туннельный пэр GRE должен был бы повторно собрать их, прежде чем это могло decapsulate и отправлять им на.

"Чистый" туннельный способ IPsec

Безопасность IP (IPsec) Протокол является основанным на стандартах методом обеспечения частной жизни, целостности и подлинности к информации, переданной через сети IP. IPsec обеспечивает шифрование сетевого слоя IP. IPsec удлиняет пакет IP путем добавления по крайней мере одного заголовка IP (туннельный способ). Добавленный заголовок (ки) варьируется по длине, зависящей способ конфигурации IPsec, но они не превышают ~58 байтов (Заключение в капсулу полезного груза безопасности (ESP) и идентификация ESP (ESPauth)) за пакет.

IPsec имеет два способа, туннельный способ и способ транспортировки.

  • Туннельный способ является режимом по умолчанию. С туннельным способом весь оригинальный пакет IP защищен (зашифрованный, заверенный, или оба) и заключил в капсулу заголовками IPsec и трейлерами. Тогда новый заголовок IP предварительно на рассмотрении к пакету, определяя конечные точки IPsec (пэры) как источник и место назначения. Если IPsec защищает движение от хозяев позади пэров IPsec, туннельный способ может использоваться с любым unicast движением IP и должен использоваться. Например, туннельный способ используется с Виртуальными частными сетями (VPNs), куда хозяева в одной защищенной сети посылают пакеты хозяевам в различной защищенной сети через пару пэров IPsec. С VPNs "тоннель" IPsec защищает движение IP между хозяевами путем шифровки этого движения между пэром IPsec маршрутизаторы.

  • Со способом транспортировки (формируемый с подкомандой, транспортом способа, на определении преобразования), только полезный груз оригинального пакета IP защищен (зашифрованный, заверенный, или оба). Полезный груз заключен в капсулу заголовками IPsec и трейлерами. Оригинальные заголовки IP остаются неповрежденными, за исключением того, что область протокола IP изменена, чтобы быть ESP (50), и первоначальная стоимость протокола спасена в трейлере IPsec, который будет восстановлен, когда расшифрован пакет. Способ транспортировки используется только, когда движение IP, которое будет защищено, между самими пэрами IPsec, источник и IP-адреса назначения на пакете совпадают с пэром IPsec адреса. Обычно способ транспортировки IPsec только используется, когда другой протокол туннелирования (как GRE) используется, чтобы сначала заключить в капсулу пакет данных IP, тогда IPsec используется для защиты туннельных пакетов GRE.

IPsec всегда делает PMTUD для пакетов данных и для его собственных пакетов. Существуют команды конфигурации IPsec для изменения PMTUD, обрабатывающего для пакета IP IPsec, IPsec может очистить, установить или скопировать бит DF с пакета данных заголовок IP к заголовку IP IPsec. Это называют, "Бит DF Отвергают Функциональность" особенность.

Примечание: Когда вы делаете шифрование аппаратных средств с IPsec, вы действительно хотите избежать фрагментации после герметизации. Шифрование аппаратных средств может дать вам пропускную способность приблизительно 50 Mbs в зависимости от аппаратных средств, но если пакет IPsec фрагментирован, вы освобождаете 50 - 90 процентов пропускной способности. Эта потеря - то, потому что фрагментированные пакеты IPsec переключены в процесс для повторной сборки и затем вручены двигателю шифрования Аппаратных средств для декодирования. Эта потеря пропускной способности может снизить пропускную способность шифрования аппаратных средств к исполнительному уровню шифрования программного обеспечения (2-10 Mbs).

Сценарий 7

Этот сценарий изображает фрагментацию IPsec в действии. В этом сценарии MTU вдоль всего пути является 1500. В этом сценарии DF укусил, не установлен.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-13.gif

  1. Маршрутизатор получает 1500-байтовый пакет (20-байтовый заголовок IP + 1480-байтовый полезный груз TCP) предназначенный для Хозяина 2.

  2. 1500-байтовый пакет зашифрован IPsec, и 52 байта верхних добавлены (заголовок IPsec, трейлер и дополнительный заголовок IP). Теперь IPsec должен послать 1552-байтовый пакет. Так как MTU за границу является 1500, этот пакет должен будет быть фрагментирован.

  3. Два фрагмента созданы из пакета IPsec. Во время фрагментации дополнительный 20-байтовый заголовок IP добавлен для второго фрагмента, приводящего к 1500-байтовому фрагменту и 72-байтовому фрагменту IP.

  4. Туннельный пэр IPsec маршрутизатор получает фрагменты, раздевается от дополнительного заголовка IP и соединяется фрагменты IP назад в оригинальный пакет IPsec. Тогда IPsec расшифровывает этот пакет.

  5. Маршрутизатор тогда вперед оригинальный 1500-байтовый пакет данных для Оказания гостеприимства 2.

Сценарий 8

Этот сценарий подобен Сценарию 6 за исключением того, что в этом случае DF укусил, установлен в оригинальном пакете данных и существует связь в пути между туннельными пэрами IPsec, который имеет более низкий MTU, чем другие связи. Этот сценарий демонстрирует, как пэр IPsec маршрутизатор выполняет обоих роли PMTUD, как описано в Маршрутизатор как Участник PMTUD в Конечной точке части Тоннеля.

Вы будете видеть в этом сценарии, как IPsec PMTU изменяется на нижнее значение как результат потребности во фрагментации. Помните, что DF укусил, скопирован от внутреннего заголовка IP до внешнего заголовка IP, когда IPsec шифрует пакет. СМИ MTU и ценности PMTU сохранены в Сопоставлении безопасности (SA) IPsec. СМИ MTU основан на MTU интерфейса маршрутизатора за границу и PMTU, основаны на минимальном MTU, замеченном на пути между пэрами IPsec. Помните, что IPsec заключает в капсулу/шифрует пакет, прежде чем это попытается фрагментировать его.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-14.gif

  1. Маршрутизатор получает 1500-байтовый пакет и пропускает его, потому что IPsec наверху, когда добавлено, сделает пакет больше тогда PMTU (1500).

  2. Маршрутизатор посылает сообщение ICMP для Оказания гостеприимства 1 сообщения его, что следующий перелет MTU является 1442 (1500 - 58 = 1442). Это 58 байтов является максимальный IPsec наверху при использовании IPsec ESP и ESPauth. Реальный IPsec наверху может составить целых 7 байтов менее тогда эта стоимость. Примите 1 отчет эта информация, обычно как маршрут хозяина для места назначения (Хозяин 2), в его таблице маршрутизации.

  3. Хозяин 1 понижает его PMTU для Хозяина 2 - 1442, таким образом, Хозяин 1 пошлет меньшие (1442-байтовые) пакеты, когда это повторно передаст данные для Оказания гостеприимства 2. Маршрутизатор получает 1442-байтовый пакет, и IPsec добавляет 52 байта шифрования наверху, таким образом, получающийся пакет IPsec составляет 1496 байтов. Поскольку этот пакет имеет набор сверл DF в своем заголовке, это пропущено средним маршрутизатором с 1400-байтовой связью MTU.

  4. Средний маршрутизатор, который уронил пакет, посылает сообщение ICMP отправителю пакета IPsec (первый маршрутизатор) сообщение его, что следующий перелет MTU составляет 1400 байтов. Эта стоимость зарегистрирована в IPsec SA PMTU.

  5. Следующий раз Принимает 1, повторно передает 1442-байтовый пакет (это не получало признание для него), IPsec уронит пакет. Снова маршрутизатор уронит пакет, потому что IPsec наверху, когда добавлено к пакету, сделает его больше тогда PMTU (1400).

  6. Маршрутизатор посылает сообщение ICMP для Оказания гостеприимства 1 сообщения его, что следующий перелет MTU теперь 1342. (1400 - 58 = 1342). Хозяин 1 снова сделает запись этой информации.

  7. Когда Хозяин 1 снова повторно передаст данные, они будут использовать меньший пакет размера (1342). Этот пакет не потребует фрагментации и сделает ее через тоннель IPsec для Оказания гостеприимства 2.

GRE и IPsec вместе

Когда IPsec используется для шифровки тоннелей GRE, происходят более сложные взаимодействия для фрагментации и PMTUD. IPsec и GRE объединены этим способом, потому что IPsec не поддерживает пакеты передачи IP, что означает, что вы не можете управлять динамическим протоколом маршрутизации по IPsec VPN Сеть. Тоннели GRE действительно поддерживают передачу, таким образом, тоннель GRE может использоваться, чтобы сначала заключить в капсулу динамический пакет передачи протокола маршрутизации в IP GRE unicast пакет, который может тогда быть зашифрован IPsec. При выполнении этого IPsec часто развертывается в способе транспортировки сверху GRE, потому что пэры IPsec и туннельные конечные точки GRE (маршрутизаторы) являются тем же самым, и способ транспортировки спасет 20 байтов IPsec наверху.

Когда пакет IP был разделен на два фрагмента и заключен в капсулу GRE, один интересный случай. В этом случае IPsec будет видеть два независимых GRE + пакеты IP. Часто в конфигурации по умолчанию один из этих пакетов будет достаточно большим, что он должен будет быть фрагментирован после того, как он был зашифрован. Пэр IPsec должен будет повторно собрать этот пакет перед декодированием. Эта "двойная фрагментация" (однажды GRE и снова после IPsec) на маршрутизаторе отправки увеличивает время ожидания и понижает пропускную способность. Кроме того, повторная сборка переключена в процесс, таким образом, будет CPU, пораженный в маршрутизатор получения каждый раз, когда это происходит.

Этой ситуации можно избежать, устанавливая "IP mtu" в туннельном интерфейсе GRE достаточно низко принимать во внимание верхнее и от GRE и от IPsec (по умолчанию, туннельный IP "интерфейса GRE mtu" установлен в коммуникабельный реальный интерфейс MTU - GRE верхние байты).

В следующей таблице перечислены предложенные ценности MTU для каждой комбинации тоннеля/способа, предполагающей, что коммуникабельный физический интерфейс имеет MTU 1500.

Туннельная комбинация Определенный необходимый MTU Рекомендуемый MTU
GRE + IPsec (Способ транспортировки) 1440 байтов 1400 байтов
GRE + IPsec (Туннельный способ) 1420 байтов 1400 байтов

Примечание: стоимость MTU 1400 рекомендуется, потому что это покрывает наиболее распространенный GRE + комбинации способа IPsec. Кроме того, нет никакой различимой нижней стороны к обеспечению дополнительных 20 или 40 байтов наверху. Легче помнить и установить одну стоимость и эту стоимость покрытия почти все сценарии.

Сценарий 9

IPsec развернут сверху GRE. Коммуникабельный физический MTU является 1500, IPsec PMTU является 1500 и IP GRE, MTU является 1476 (1500 - 24 = 1476). Из-за этого пакеты TCP/IP будут фрагментированы дважды, однажды GRE и однажды после IPsec. Пакет будет фрагментирован, прежде чем герметизация GRE и один из этих пакетов GRE будут фрагментированы снова после шифрования IPsec.

При формировании "IP mtu 1440" (Способ транспортировки IPsec) или "IP mtu 1420" (Туннельный способ IPsec) на тоннеле GRE удалил бы возможность двойной фрагментации в этом сценарии.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-15.gif

  1. Маршрутизатор получает 1500-байтовую дейтаграмму.

  2. Перед герметизацией GRE фрагментирует 1500-байтовый пакет в две части, 1476 (1500 - 24 = 1476) и 44 (24 данных + 20 заголовков IP) байты.

  3. GRE заключает в капсулу фрагменты IP, который добавляет 24 байта к каждому пакету. Это приводит к двум GRE + пакеты IPsec 1500 (1476 + 24 = 1500) и 68 (44 + 24) байты каждый.

  4. IPsec шифрует эти два пакета, добавляя 52 byes (туннельный способ IPsec) герметизации наверху каждому, для предоставления 1552 байтов и 120-байтовый пакет.

  5. 1552-байтовый пакет IPsec фрагментирован маршрутизатором, потому что это больше тогда MTU за границу (1500). 1552-байтовый пакет разделен на части, 1500-байтовый пакет и 72-байтовый пакет (52-байтовый "полезный груз" плюс дополнительный 20-байтовый заголовок IP для второго фрагмента). Эти три пакета 1500 байтов, 72 байта, и 120-байтовые пакеты отправлены IPsec + пэр GRE.

  6. Маршрутизатор получения повторно собирает два фрагмента IPsec (1500 байтов и 72 байта) для получения оригинального 1552-байтового IPsec + пакет GRE. Ничто не должно быть сделано к 120-байтовому IPsec + пакет GRE.

  7. IPsec расшифровывает и 1552-байтовый и 120-байтовый IPsec + пакеты GRE для получения 1500-байтовых и 68-байтовых пакетов GRE.

  8. GRE decapsulates 1500-байтовые и 68-байтовые пакеты GRE для получения 1476-байтовых и 44-байтовых фрагментов пакета IP. Эти фрагменты пакета IP отправлены конечному хосту.

  9. Хозяин 2 повторно собирает эти фрагменты IP для получения оригинальной 1500-байтовой дейтаграммы IP.

Сценарий 10 подобен Сценарию 8 кроме в туннельном пути существует более низкая связь MTU. Это - "худший случай" сценарий для первого пакета, посланного от Хозяина 1 для Оказания гостеприимства 2. После последнего шага в этом сценарии Хозяин 1 набор правильный PMTU для Хозяина 2 и все хорошо для связей TCP между Хозяином 1 и Хозяином 2. Потоки TCP между Хозяином 1 и другими хозяевами (достижимый через IPsec + тоннель GRE) должны будут только пройти последние три шага Сценария 10.

В этом сценарии тоннель path-mtu-discovery команда формируется на тоннеле GRE, и DF укусил, установлен на пакетах TCP/IP, происходящих от Хозяина 1.

Сценарий 10

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-16.gif

  1. Маршрутизатор получает 1500-байтовый пакет. Этот пакет уронен GRE, потому что GRE не может фрагментировать или отправить пакет, потому что DF укусил, установлен, и размер пакета превышает интерфейсный "IP за границу mtu" после добавления GRE, верхнего (24 байта).

  2. Маршрутизатор посылает сообщение ICMP для Оказания гостеприимства 1 разрешения ему знать, что следующий перелет MTU является 1476 (1500 - 24 = 1476).

  3. Примите 1 изменение его PMTU для Хозяина 2 - 1476, и посылает меньший размер, когда он повторно передает пакет. GRE заключает в капсулу его и вручает 1500-байтовый пакет IPsec. IPsec уронил пакет, потому что GRE скопировал (набор) DF долота с внутреннего заголовка IP, и с IPsec наверху (максимальные 38 байтов), пакет является слишком большим для отправления физического интерфейса.

  4. IPsec посылает сообщение ICMP в GRE указание, что следующий перелет, MTU составляет 1462 байта (так как максимальные 38 байтов будут добавлены для шифрования и IP наверху). GRE делает запись стоимости 1438 (1462 - 24) как "IP mtu" в туннельном интерфейсе.

    Примечание: Это изменение в стоимости сохранено внутренне и не может быть замечено в продукции выставочного тоннеля интерфейса IP <#> команда. Вы будете только видеть это изменение, если вы повернетесь, используют туннельную команду отладки.

  5. Следующий раз Принимает 1, повторно передает 1476-байтовый пакет, GRE пропускает его.

  6. Маршрутизатор посылает сообщение ICMP для Оказания гостеприимства 1 указания, в том 1438 следующий перелет MTU.

  7. Хозяин 1 понижает PMTU для Хозяина 2 и повторно передает 1438-байтовый пакет. На сей раз GRE принимает пакет, заключает в капсулу его и передает его к IPsec для шифрования. Пакет IPsec отправлен промежуточному маршрутизатору и уронен, потому что это имеет интерфейс MTU за границу 1400.

  8. Промежуточный маршрутизатор посылает сообщение ICMP в IPsec сообщение его, что следующий перелет MTU является 1400. Эта стоимость зарегистрирована IPsec в ценности PMTU связанной IPsec SA.

  9. Когда Хозяин 1 повторно передает 1438-байтовый пакет, GRE заключает в капсулу его и вручает его IPsec. IPsec уронил пакет, потому что это изменило свой собственный PMTU на 1400.

  10. IPsec посылает ошибку ICMP в GRE указание, что следующий перелет, MTU является 1362 и GRE, делает запись стоимости 1338 внутренне.

  11. Когда Хозяин 1 повторно передает оригинальный пакет (потому что он не получал признание), GRE пропускает его.

  12. Маршрутизатор посылает сообщение ICMP для Оказания гостеприимства 1 указания на следующий перелет, MTU является 1338 (1362 - 24 байта). Хозяин 1 понижает его PMTU для Хозяина 2 - 1338.

  13. Хозяин 1 повторно передает 1338-байтовый пакет, и на сей раз это может наконец добраться полностью через для Оказания гостеприимства 2.

Больше рекомендаций

Формирование тоннеля path-mtu-discovery команда в туннельном интерфейсе может помочь GRE и взаимодействию IPsec, когда они формируются на том же самом маршрутизаторе. Помните, что без тоннеля path-mtu-discovery формируемая команда, DF укусил, будет всегда очищаться в заголовке IP GRE. Это позволяет пакету IP GRE быть фрагментированным даже при том, что скрытые данные, заголовок IP имел набор сверл DF, который обычно не будет позволять пакету быть фрагментированным.

Если тоннель path-mtu-discovery команда будет формироваться в туннельном интерфейсе GRE, то следующее произойдет.

  1. GRE скопирует бит DF с данных заголовок IP к заголовку IP GRE.

  2. Если DF укусил, установлен в заголовке IP GRE, и пакет будет "слишком большим" после шифрования IPsec для IP MTU в физическом коммуникабельном интерфейсе, то IPsec уронит пакет и зарегистрирует тоннель GRE для сокращения его IP размер MTU.

  3. IPsec делает PMTUD для своих собственных пакетов и если IPsec PMTU изменения (если это уменьшено), тогда IPsec немедленно не регистрирует GRE, но когда другой "слишком большой" пакет прибывает полный, тогда процесс в шаге 2 происходит.

  4. MTU IP GRE теперь меньше, таким образом, он пропустит любые данные пакеты IP с набором сверл DF, которые являются теперь слишком большими и посылают сообщение ICMP хозяину отправки.

Тоннель path-mtu-discovery команда помогает интерфейсу GRE установить свой IP MTU динамично, а не статически с IP mtu команда. Фактически рекомендуется, чтобы использовались обе команды. IP mtu команда используется для обеспечения комнаты для GRE и IPsec наверху относительно местного физического коммуникабельного интерфейса IP MTU. Тоннель path-mtu-discovery команда позволяет тоннелю GRE IP MTU, который будет далее уменьшен, если существует более низкий IP связь MTU в пути между пэрами IPsec.

Ниже некоторые вещи, которые можно сделать, если у вас есть проблемы с PMTUD в сети, где существуют GRE + формируемые тоннели IPsec.

Следующий список начинается с самого желательного решения.

  • Решите проблему с PMTUD, не работающим, который обычно вызывается маршрутизатором или брандмауэром, блокирующим ICMP.

  • Используйте IP tcp, регулируют-mss команду в туннельных интерфейсах так, чтобы маршрутизатор уменьшил стоимость MSS TCP в TCP SYN пакет. Это поможет двум хозяевам конца (отправитель TCP и управляющий) использовать пакеты, достаточно маленькие так, чтобы не был необходим PMTUD.

  • Используйте стратегическое направление во входном интерфейсе маршрутизатора и формируйте маршрутную карту для прояснения бита DF в данных заголовок IP, прежде чем это доберется до туннельного интерфейса GRE. Это позволит данным пакет IP, который будет фрагментирован перед герметизацией GRE.

  • Увеличьте "IP mtu" в туннельном интерфейсе GRE, чтобы быть равными интерфейсу MTU за границу. Это позволит данным пакет IP, чтобы быть GRE, заключенным в капсулу, не фрагментируя его сначала. Пакет GRE тогда будет зашифрованным IPsec и затем фрагментированным, чтобы выйти физический интерфейс за границу. В этом случае вы не формировали бы тоннель path-mtu-discovery команда в туннельном интерфейсе GRE. Это может существенно уменьшить пропускную способность, потому что повторная сборка пакета IP на пэре IPsec сделана в переключающем процесс способе.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Соответствующая информация


Document ID: 25885