По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Седьмая часть тут.
Поля фиксированной длины - самый простой из описанных в словаре механизмов. Протокол определяет набор полей, какие данные содержит каждое поле и насколько велико каждое поле. Эта информация «встроена» в определение протокола, поэтому каждая реализация построена в соответствии с этими же спецификациями и, следовательно, может взаимодействовать друг с другом. Рисунок 1 иллюстрирует кодирование поля фиксированной длины, используемое в протоколе Open Shortest Path First (OSPF), взятом из RFC2328.
Ряд чисел в верхней части рисунка 1 указывает отдельные биты в формате пакета; каждая строка содержит 32 бита информации. Первые 8 битов указывают номер версии, вторые 8 битов всегда имеют номер 5, следующие 16 битов содержат общую длину пакета и так далее Каждое из этих полей дополнительно определяется в спецификации протокола с видом информации, переносимой в поле и как оно закодировано. Например:
Поле номера версии кодируется как целое число без знака. Это метаданные, указывающие словарь и грамматику, используемые для этого пакета. Если формат пакета необходимо изменить, номер версии может быть увеличен, что позволяет передатчикам и получателям использовать правильный словарь и грамматику при кодировании и декодировании информации в пакете
Число 5 указывает тип пакета в протоколе; это часть словаря, определенного в другом месте в документе стандартов, поэтому он просто вставляется как фиксированное значение на этом рисунке. Этот конкретный пакет является пакетом подтверждения состояния канала (Link State Acknowledgment Packet).
Длина пакета кодируется как целое число без знака, указывающее количество октетов (или наборов из 8 битов), содержащихся в полном пакете. Это позволяет размеру пакета варьироваться по длине в зависимости от объема передаваемой информации.
Формат поля фиксированной длины имеет несколько преимуществ. Прежде всего, местоположение любого фрагмента информации в пакете будет одинаковым для каждого пакета, что означает, что легко оптимизировать код, предназначенный для кодирования и декодирования информации вокруг формата пакета. Например, обычным способом обработки формата пакета фиксированной длины является создание структуры данных в памяти, точно соответствующей формату пакета; когда пакет считывается с провода, он просто копируется в эту структуру данных. Поля в пакете могут быть прочитаны напрямую.
Форматы фиксированной длины имеют тенденцию быть несколько компактными. Метаданные, необходимые для кодирования и декодирования данных, передаются «вне протокола» в форме спецификации протокола. Сами пакеты содержат только значение и никогда не содержат никакой информации о значениях. С другой стороны, форматы фиксированной длины могут тратить много места на буферизацию полей, чтобы они всегда были одинаковой длины. Например, десятичное число 1 может быть представлено одной двоичной цифрой (один бит), тогда как десятичное число 4 требует 3 двоичных цифры (три бита); если поле фиксированной длины должно быть в состоянии представить любое число от 0 до 4, оно должно быть длиной не менее 3 битов, даже если два из этих битов иногда «теряются» при представлении меньших десятичных чисел.
Форматы фиксированной длины также часто занимают место, выравнивая размеры полей по общим границам памяти процессора, чтобы повысить скорость обработки. Поле, которое должно принимать значения от 0 до 3, даже если для представления полного набора значений требуется только два бита, может быть закодировано как 8-битовое поле (полный октет), чтобы обеспечить всегда выравнивание следующего поля на границе октета для более быстрой обработки в памяти.
Гибкость - то, где кодирование фиксированной длины часто сталкивается с проблемами. Если какое-либо поле определено как 8-битное значение (один октет) в исходной спецификации, нет очевидного способа изменить длину поля для поддержки новых требований. Основной способ решения этой проблемы в схемах кодирования с фиксированной длиной - через номер версии. Если длина поля должна быть изменена, номер версии изменяется в форматах пакетов, поддерживающих новую длину поля. Это позволяет реализациям использовать старый формат, пока все устройства в сети не будут обновлены для поддержки нового формата; после того как все они обновлены, вся система может быть переключена на новый формат, будь то больше или меньше.
Метрические веса TOS K1 K2 K3 K4 K5, выданные командой в режиме конфигурации маршрутизатора EIGRP, может быть использована для установки K-значений, используемых EIGRP в своем расчете. Параметр TOS был предназначен для использования маркировки качества обслуживания (где TOS обозначает тип служебного байта в заголовке IPv4). Однако параметр TOS должен быть равен 0. На самом деле, если вы введете число в диапазоне 1 - 8 и вернетесь назад, чтобы изучить свою текущую конфигурацию, вы обнаружите, что Cisco IOS изменила это значение на 0. Пять оставшихся параметров в команде metric weights - это пять K-значений, каждое из которых может быть задано числом в диапазоне от 0 до 255.
Предыдущие статьи из цикла про EIGRP:
Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка
Часть 2. Про соседство и метрики EIGRP
Следующие статьи из цикла:
Часть 3. Конвергенция EIGRP – настройка таймеров
Часть 4. Пассивные интерфейсы в EIGRP
Часть 5. Настройка статического соседства в EIGRP
Часть 6. EIGRP: идентификатор роутера и требования к соседству
Например, представьте, что в нашем проекте мы обеспокоены тем, что нагрузка на наши линии может быть высокой в разы, и мы хотим, чтобы EIGRP учитывал уровень насыщения линии при расчете наилучшего пути. Изучая полную формулу расчета метрики EIGRP, мы замечаем, что наличие ненулевого значения для K2 приведет к тому, что EIGRP будет учитывать нагрузку. Поэтому мы решили установить K2 равным 1, в дополнение к K1 и K3, которые уже установлены в 1 по умолчанию. Значения К4 и К5 сохранится на уровне 0. В приведенном ниже примере показано, как можно настроить такой набор K-значений.
OFF1#conf term
Enter configuration commands, one per line. End with CNTL/Z .
OFF1(config)#router eigrp 1
OFF1(config-router)#metric weights 0 1 1 1 0 0
OFF1(config-router)#end
Первый 0 в команде metric weights 0 1 1 1 0 0, показанной в приведенном выше примере, задает значение TOS равное 0. Следующие пять чисел задают наши пять K-значений: K1 = 1, K2 = 1, K3 = 1, K4 = 0, K5 = 0. Этот набор K-значений теперь будет учитывать не только пропускную способность и задержку, но и нагрузку при выполнении расчета метрики. Однако есть проблема. Обратите внимание на сообщения консоли, появляющиеся после нашей конфигурации. Оба наших соседства были разрушены, потому что маршрутизатор OFF1 теперь имеет другие K-значения, чем маршрутизаторы OFF2 и OFF3. Напомним, что соседи EIGRP должны иметь соответствующие K-значения, а это означает, что при изменении K-значений на одном EIGRP-спикер маршрутизаторе, вам нужен идентичный набор K-значений на каждом из его соседей EIGRP. Как только вы настроите соответствующие K-значения на этих соседях, то каждый из этих соседей должен соответствовать K-значениям. Как вы можете видеть, в большой топологии может возникнуть значительная административная нагрузка, связанная с манипуляцией K-значением.
Преемник и возможные маршруты преемников
Одна из причин, по которой EIGRP быстро восстанавливает соединения в случае сбоя маршрута, заключается в том, что EIGRP часто имеет резервный маршрут, готовый взять на себя управление, если основной маршрут уходит в down. Чтобы убедиться, что резервный маршрут не зависит от основного маршрута, EIGRP тщательно проверяет резервный маршрут, убедившись, что он соответствует условию осуществимости EIGRP. В частности, условие осуществимости гласит:
Маршрут EIGRP является возможным маршрутом-преемником, если его сообщенное расстояние (RD) от нашего соседа меньше возможного расстояния (FD) маршрута-преемника.
Например, рассмотрим топологию, показанную на следующем рисунке, и соответствующую конфигурацию, приведенную ниже. Обратите внимание, что сеть 10.1.1.8/30 (между маршрутизаторами OFF2 и OFF3) доступна из OFF1 через OFF2 или через OFF3. Если маршрутизатор OFF1 использует маршрут через OFF2, он пересекает канал связи 1 Гбит/с, чтобы достичь целевой сети. Однако маршрут через OFF3 заставляет трафик пересекать более медленное соединение со скоростью 100 Мбит/с. Поскольку EIGRP учитывает пропускную способность и задержку по умолчанию, мы видим, что предпочтительный маршрут проходит через маршрутизатор OFF2. Однако, что делать, если связь между маршрутизаторами OFF1 и OFF2 обрывается? Есть ли возможный преемственный маршрут, который может почти сразу заработать? Опять же, мы видим, что маршрутизатор OFF1 будет использовать возможный маршрут преемника через маршрутизатор OFF3. Однако, прежде чем мы убедимся в этом, мы должны подтвердить, что путь через OFF3 соответствует условию осуществимости.
Возможное условие преемника выполнено на маршрутизаторе OFF1
Просто в силу того, что маршрут через маршрутизатор OFF3 (то есть через 10.1.1.6) появляется в выходных данных команды show ip eigrp topology, выполненной на маршрутизаторе OFF1, мы делаем вывод, что путь через OFF3 действительно является возможным маршрутом-преемником. Однако давайте рассмотрим выходные данные немного более внимательно, чтобы определить, почему это возможный маршрут-преемник.
Во-первых, рассмотрим запись из выходных данных в приведенном выше примере, идентифицирующую последующий маршрут (то есть предпочтительный маршрут):
via 10.1.1.2 (3072/2816), GigabitEthernet0/1
Часть выходных данных via 10.1.1.2 говорит, что этот маршрут указывает на адрес следующего прыжка 10.1.1.2, который является маршрутизатором OFF2. На интерфейсе GigabitEthernet0/1 часть выходных данных указывает, что мы выходим из маршрутизатора OFF1 через интерфейс Gig0/1 (то есть выходной интерфейс). Теперь давайте рассмотрим эти два числа в скобках: (3072/2816). Стоимость 2816 называется зафиксированная дистанция (reported distance (RD). В некоторых литературных источниках это значение также называется advertised distance (AD). Эти термины, синонимы, относятся к метрике EIGRP, сообщенной (или объявленной) нашим соседом по EIGRP. В данном случае значение 2816 говорит нам, что метрика маршрутизатора OFF2 (то есть расстояние) до cети 10.1.1.8/30 равна 2816. Значение 3072 на выходе - это допустимое расстояние маршрутизатора OFF1 (FD). FD вычисляется путем добавления RD нашего соседа к метрике, необходимой для достижения нашего соседа. Поэтому, если мы добавим метрику EIGRP между маршрутизаторами OFF1 и OFF2 к RD маршрутизатора OFF2, мы получим FD (то есть общее расстояние), необходимое для того, чтобы OFF1 добрался до 10.1.1.8/30 через маршрутизатор OFF2. Кстати, причина, по которой маршрутизатор OFF1 определяет наилучший путь к сети 10.1.1.8/30, - это via via router OFF2 (то есть 10.1.1.2) В отличие от маршрутизатора OFF3 (то есть 10.1.1.6), потому что FD пути через OFF1 (3072) меньше, чем FD пути через OFF2 (28,416).
Далее рассмотрим запись для возможного последующего маршрута из приведенного выше примера:
via 10.1.1.6 (28416/2816), GigabitEthernet0/2
Часть выходных данных via 10.1.1.6 говорит, что этот маршрут указывает на адрес следующего прыжка 10.1.1.6, который является маршрутизатором OFF3. На интерфейсе GigabitEthernet0/2 часть результатов показывает, что мы выходим из маршрутизатора OFF1 через интерфейс Gig0/2. Эта запись имеет FD 28 416 и RD 2816. Однако прежде, чем EIGRP просто слепо сочтет этот резервный путь возможным преемником, он проверяет маршрут на соответствие условию осуществимости. В частности, процесс EIGRP на маршрутизаторе OFF1 запрашивает, является ли RD от маршрутизатора OFF3 меньше, чем FD последующего маршрута. В этом случае RD от маршрутизатора OFF3 составляет 2816, что действительно меньше, чем FD преемника 3072. Поэтому маршрут через маршрутизатор OFF3 считается возможным преемником маршрута.
Чтобы утвердить эту важную концепцию, рассмотрим топологию, показанную ниже. Процесс EIGRP на маршрутизаторе OFF1 изучил три пути для достижения сети 10.1.1.0/24. Однако далее EIGRP должен определить, какой из этих путей является маршрутом-преемником, какие (если таковые имеются) пути являются возможными маршрутами-преемниками, а какие (если таковые имеются) пути не являются ни преемником, ни возможным маршрутом-преемником. Результаты расчетов EIGRP приведены в таблице ниже.
Примеры расчетов Feasible Successor
Используя приведенную выше таблицу в качестве рассмотрения, сначала рассмотрим путь маршрутизатора OFF1 к сети 10.1.1.0/24 через маршрутизатор OFF2. С точки зрения маршрутизатора OFF2, расстояние до сети 10.1.1.0/24 - это расстояние от OFF2 до OFF5 (которое равно 5000) плюс расстояние от OFF5 до сети 10.1.1.0/24 (которое равно 1000). Это дает нам в общей сложности 6000 для расстояния от маршрутизатора OFF2 до сети 10.1.1.0/24. Это расстояние, которое маршрутизатор OFF2 сообщает маршрутизатору OFF1. Таким образом, маршрутизатор OFF1 видит RD 6000 от маршрутизатора OFF2. Маршрутизатор OFF1, затем добавляет расстояние между собой и маршрутизатором OFF2 (который равен 10 000) к RD от OFF2 (который равен 6000), чтобы определить его FD для достижения сети 10.1.1.0/24 составляет 16 000 (то есть 10 000 + 6000 = 16 000). Процесс EIGRP на маршрутизаторе OFF1 выполняет аналогичные вычисления для путей к сети 10.1.1.0/24 через маршрутизаторы OFF3 и OFF4. Ниже приведены расчеты, которые привели к значениям, приведенным в таблице.
Затем маршрутизатор OFF1 проверяет результаты этих вычислений и определяет, что кратчайшее расстояние до сети 10.1.1.0/24 проходит через маршрутизатор OFF2, поскольку путь через OFF2 имеет самый низкий FD (16 000). Этот путь, определяемый как кратчайший, считается следующим маршрутом. Затем маршрутизатор OFF1 пытается определить, соответствует ли любой из других маршрутов условию выполнимости EIGRP. В частности, маршрутизатор OFF1 проверяет, чтобы увидеть, что RD от маршрутизаторов OFF3 или OFF4 меньше, чем FD последующего маршрута. В случае OFF3 его RD в 11 000 действительно меньше, чем FD последующего маршрута (который составляет 16 000). Таким образом, путь к сети 10.1.1.0 /24 через OFF3 квалифицируется как возможный маршрут-преемник. Однако маршрут через OFF4 не подходит, потому что RD OFF4 из 18 000 больше, чем 16 000 (FD последующего маршрута). В результате путь к сети 10.1.1.0/24 через маршрутизатор OFF4 не считается возможным маршрутом-преемником.
Мы изучили K - значения, теперь почитайте про конвергенцию EIGRP и настройку таймеров
Сегментная маршрутизация (Segment Routing, SR) может или не может считаться туннельным решением, в зависимости от конкретной реализации и того, насколько строго вы хотите придерживаться определения туннелей, представленного ранее в статье "Виртуализация сетей". В этой статье будет рассмотрена основная концепция сегментной маршрутизации и две возможные схемы реализации: одна с использованием меток потока IPv6, а другая с использованием меток многопротокольной коммутации по меткам (Multiprotocol Label Switching -MPLS).
Каждому устройству в сети с поддержкой SR присваивается уникальная метка. Стек меток, описывающий путь в терминах этих уникальных меток, может быть присоединен к любому пакету, заставляя его принимать определенный указанный путь. Рисунок 5 демонстрирует это.
Каждый маршрутизатор на рисунке 5 объявляет IP-адрес в качестве идентификатора вместе с меткой, прикрепленной к этому IP-адресу. В SR метка, прикрепленная к идентификатору маршрутизатора, называется идентификатором сегмента узла (SID узла). Поскольку каждому маршрутизатору в сети присваивается уникальная метка, путь через сеть может быть описан с использованием только этих меток. Например:
Если вы хотите перенаправить трафик от A к K по пути [B, E, F, H], вы можете описать этот путь с помощью меток [101,104,105,107].
Если вы хотите перенаправить трафик от A к K по пути [B, D, G, H], вы можете описать этот путь с помощью меток [101,103,106,107].
Набор меток, используемых для описания пути, называется стеком меток. Между D и H есть две связи; как это можно описать? В SR доступно несколько опций, в том числе:
Стек меток может включать в себя только идентификаторы SID узла, описывающие путь через сеть в терминах маршрутизаторов, как показано ранее. В этом случае, если бы стек меток включал пару [103,107], D просто перенаправлял бы H в обычном режиме на основе информации локальной маршрутизации, поэтому он будет использовать любой локальный процесс, который он будет использовать для пересылки любого другого пакета, например, распределение нагрузки между двумя каналами для пересылки трафика с меткой SR.
Стек меток может включать явную метку для загрузки общего ресурса по любому доступному набору путей, доступных в этой точке сети.
H может назначить метку для каждого входящего интерфейса, а также SID узла, привязанный к его локальному идентификатору маршрутизатора. Эти метки будут объявляться так же, как SID узла, но, поскольку они описывают смежность, они называются SID смежности (adjacency). SID смежности уникален локально; он уникален для маршрутизатора, объявляющего сам SID смежности.
Третий вид SID, префиксный SID, описывает конкретный достижимый пункт назначения (префикс) в сети. SID узла может быть реализован как SID префикса, привязанный к loopback адресу на каждом маршрутизаторе в сети.
Не обязательно, чтобы весь путь описывался стеком меток. Например, стек меток [101,103] будет направлять трафик в B, затем в D, но затем позволит D использовать любой доступный путь для достижения IP-адреса назначения в K. Стек меток [105] обеспечит прохождение трафика через сеть к K будет проходить через F. Не имеет значения, как трафик достиг этой точки в сети и как он был перенаправлен после того, как достигнет F, если он проходит через F, будучи направленным к K.
Каждая метка в стеке представляет собой сегмент. Пакеты переносятся от метки к метке через каждый сегмент в сети, чтобы быть транспортированными от головной части пути к хвостовой части пути.
Маршрутизация сегментов с многопротокольной коммутацией меток
MPLS был изобретен как способ сочетать преимущества асинхронного режима передачи (ATM), который больше не используется широко, с IP-коммутацией. В первые дни сетевой инженерии наборы микросхем, используемые для коммутации пакетов, были более ограничены в своих возможностях, чем сейчас. Многие из используемых наборов микросхем были Field Programmable Gate Arrays (FPGA), а не Application-Specific Integrated Circuits (ASIC), поэтому длина поля, в котором коммутировался пакет, напрямую коррелировала со скоростью, с которой пакет мог коммутироваться. Часто было проще переработать пакет или обработать его дважды, чем включать в заголовок много сложной информации, чтобы пакет можно было обработать один раз.
Примечание: повторное использование пакетов по-прежнему часто используется во многих наборах микросхем для поддержки внутренних и внешних заголовков или даже для обработки различных частей более длинного и сложного заголовка пакета.
MPLS инкапсулирует исходный пакет в заголовок MPLS, который затем используется для коммутации пакета по сети. На рисунке 6 показан заголовок MPLS. Весь заголовок состоит из 32 бит, метка 20 бит. Устройство пересылки MPLS может выполнять три операции:
Текущая метка в заголовке MPLS может быть заменена другой меткой (SWAP).
В пакет можно вставить новую метку (PUSH).
Текущая метка может быть очищена, а метка под текущей меткой обработана (POP).
Операции PUSH и POP переносятся непосредственно в SR: операция SWAP реализована в SR как CONTINUE, что означает, что текущая метка заменяется той же меткой (т. е. заголовок с меткой 100 будет заменен меткой 100), и обработка этого текущего сегмента будет продолжена. Проще всего понять процесс обработки на примере. Рисунок 7 демонстрирует это.
На рисунке 7 каждому маршрутизатору присвоена глобально уникальная метка из глобального блока сегментной маршрутизации (Segment Routing Global Block -SRGB). Они объявляются через протокол маршрутизации или другую плоскость управления. Когда A получает пакет, предназначенный для N, он выбирает путь через сеть, используя некоторый локальный механизм. В этот момент:
Чтобы начать процесс, A выполнит PUSH серии заголовков MPLS на пакете, которые описывают путь через сеть, [101,103,104,202,105,106,109, 110]. Когда A коммутирует пакет в сторону B, он вставит первую метку в стек, так как нет необходимости отправлять свою собственную метку в заголовке. Стек меток на канале [A,B] будет равен [103,104,202,105,106,109,110].
Когда B получает пакет, он проверяет следующую метку в стеке. Обнаружив, что метка равна 103, он выполнит POP этой метки и перешлет пакет в D. В этом случае стек меток SR выбрал один из двух возможных путей с равной стоимостью через сеть, так что это пример выбора SR конкретного пути. Стек меток на канале [B, D] будет [104,202,105,106,109,110].
Когда D получает пакет, верхняя метка в стеке будет 104. D выполнит POP этой метки и отправит пакет в E. Стек меток на канале [D, E] будет [202,105,106,109,110].
Когда E получает этот пакет, верхняя метка в стеке - 202. Это селектор смежности, поэтому он выбирает конкретный интерфейс, а не конкретного соседа. E выберет правильный интерфейс, нижний из двух интерфейсов на рисунке, и POP этой метки. Верхняя метка теперь представляет собой SID узла для F, который можно удалить, поскольку пакет передается на F. E переработает пакет и также откроет эту POP. Стек меток на канале [E, F] будет [106,109,110].
Когда пакет достигает F, следующей меткой в стеке будет 106. Эта метка указывает, что пакет должен быть передан в G. F выполнит POP метки и передаст ее G. Стек меток на канале [F, G] будет [109,110].
Когда пакет достигает G, следующая метка в стеке - 109, что указывает на то, что пакет должен быть направлен к L. Поскольку G не соединен напрямую с L, он может использовать локальный, свободный от петель (обычно самый короткий) путь к L. В этом случае есть два пути с равной стоимостью к L, поэтому G выполнит POP метки 109 и переадресовывает по одному из этих двух путей к L. В сегменте [G, L] стек меток равен [110].
Предположим, что G решает отправить пакет через K. Когда K получает пакет, он будет иметь стек меток, содержащий [110], который не является ни локальной меткой, ни смежным узлом. В этом случае метка должна оставаться прежней, или сегмент должен иметь CONTINUE. Чтобы реализовать это, K поменяет текущую метку 110 на другую копию той же метки, так что K будет пересылать трафик с той же меткой. На канале [K,L] стек меток будет равен [110].
Когда L принимает пакет, единственной оставшейся меткой будет 110, что указывает на то, что пакет должен быть направлен в M. L будет выполнена POP метки 109, эффективно удалив всю инкапсуляцию MPLS, и перенаправит пакет в M.
Когда M получает пакет, он пересылает его, используя обычный IP-адрес, в конечный пункт назначения - N.
Концепция стека меток в MPLS реализована в виде серии заголовков MPLS, уложенных друг на друга. Pop метки означает удаление самой верхней метки, push метки означает добавление нового заголовка MPLS в пакет, а continue означает замену метки идентичной меткой. Когда вы работаете со стопкой меток, понятия внутреннего и внешнего часто сбивают с толку, особенно, поскольку многие люди используют идею метки и заголовка как взаимозаменяемые. Возможно, лучший способ уменьшить путаницу - использовать термин "заголовок" для обозначения всего стека меток и исходного заголовка, переносимого внутри MPLS, при этом обращаясь к меткам как к отдельным меткам в стеке. Тогда внутренний заголовок будет исходным заголовком пакета, а внешний заголовок будет стеком меток. Внутренняя метка будет следующей меткой в стеке в любой момент прохождения пакета по сети, а внешняя метка будет меткой, по которой пакет фактически переключается.
Хотя в приведенном здесь примере используются IP-пакеты внутри MPLS, протокол MPLS предназначен для передачи практически любого протокола, включая Ethernet. Таким образом, SR MPLS не ограничивается использованием для передачи одного типа трафика, но может также использоваться для передачи кадров Ethernet по сети на основе IP / MPLS. Это означает, что SR можно использовать для поддержки первого варианта использования, обсуждаемого в этой статье, - предоставления услуг Ethernet по IP-сети.
MPLS - это туннель?
Много написанных и произнесенных слов были пролиты на вопрос о том, является ли MPLS протоколом туннелирования. Здесь туннелирование определяется как действие, а не протокол; это намеренная попытка отделить идею протокола туннелирования от концепции туннелирования как действия, предпринимаемого при передаче трафика через сеть. В случае MPLS это означает, что он может быть, а может и не быть протоколом туннелирования, в зависимости от того, как он используется - как и любой другой протокол. Например, если у вас есть стек меток, помещенных поверх пакета с IP-заголовком, внешняя метка, на которую коммутируется пакет, не является (технически) туннелем. Этот внешний заголовок в сети MPLS фактически является локальным для сегмента, поэтому он либо выталкивается, либо отправляется на каждом маршрутизаторе. Это аналогично заголовку Ethernet для каждого канала. Однако внутренний заголовок переносится в пакете MPLS и, следовательно, технически туннелируется. Внутренняя метка не используется на текущем устройстве для коммутации пакета; он просто переносится как часть пакета.
Это определение не идеально. Например, в случае MPLS SWAP или SR CONTINUE, используется ли метка для коммутации пакета или нет? Кроме того, в отличие от заголовка Ethernet в пакете, заголовок MPLS фактически используется при принятии решения о пересылке. Заголовок Ethernet, напротив, просто используется для достижения следующего перехода, а затем отбрасывается. Возможно, более подходящим сравнением было бы следующее: Заголовок MPLS подобен заголовку Ethernet, который используется для достижения перехода за пределы устройства, на которое маршрутизатор в настоящее время передает.
Независимо от этих ограничений, этого определения обычно достаточно, чтобы мысленно управлять различием между туннелированием и не туннелированием в MPLS, а также в большинстве других протоколов.