Сеть нашей воображаемой компании linkmeup растёт. У неё есть уже магистральные линии в различных городах, клиентская база и отличный штат инженеров, выросших на цикле СДСМ.
Но всё им мало. Услуги ШПД - это хорошо и нужно, но есть ещё огромный потенциальный рынок корпоративных клиентов, которым нужен VPN.
Думали ребята над этим, ломали голову и пришли к выводу, что никак тут не обойтись без MPLS.

Если мультикаст был первой темой, которая требовала некоторого перестроения понимания IP-сетей, то, изучая MPLS, вам точно придётся забыть почти всё, что вы знали раньше - это особенный мир со своими правилами.

Сегодня в выпуске:

А начнём мы с вопроса: «Что не так с IP?»

Традиционное видео

А действительно, что не так? Зачем городить MPLS?

Да всё так. Достоинства и недостатки IP вытекают из того, что он появился позже классических сетей и невероятно гибкий. Сейчас повсеместно идёт переход на пакетную коммутацию, в основу которой лёг IP на сетевом уровне, а на канальном всё большую популярность набирает Ethernet.
Это хорошо, ведь теперь на базе одной опорной сети и сети доступа можно предоставлять , IP-телефонию, IPTV и другие возможные услуги.
То же самое прослеживается и в сетях мобильных операторов. Сети второго поколения на заре были целиком на основе . Ядро сетей 3G в большинстве своём уже IP, но услуги телефонии по-прежнему могут предоставляться в режиме коммутации каналов. Сети же 4G это уже полноценные IP-сети, где передача голоса - это лишь одно из приложений, также, как и ШПД.

Однако существует ещё огромное число сегментов, где используются старые технологии. Например, где-то есть ATM, в другом месте нужно PDH передать из одной части сети в другую, а тут клиент захотел, чтобы его кусок Ethernet-сети оказался доступным с другого конца города так, словно он подключен непосредственно - иными словами VPN.
Как это решалось раньше: нужен ATM между двумя географическими точками - строй канал между ними на базе ATM, PDH - строй PDH.
А хочется-то делать всё это через одну сеть, а не строить отдельную для каждого типа трафика.
Для этого и были придуманы в своё время GRE, PPPoE, PPPoA, ATM over Ethernet, TDM over IP и многочисленные другие over"ы. Можно насоздавать ещё тысячу других, чтобы покрыть уже все комбинации, и настанет вселенское счастье в хаосе стандартов (к слову, некоторые мелкие производители по такому пути и пошли ).

В середине 90-х горячим головам из нескольких компаний (IBM, Toshiba, Cisco, Ipsilon) пришло в голову создать механизм, который позволил бы при маршрутизации заглядывать не внутрь пакета и прочёсывать таблицу маршрутизации в поисках лучшего пути, а ориентироваться по некой метке. Выстрелило у Cisco, и механизм был назван незамысловато: TAG Switching.
Причём цель, которую преследовали разработчики, заключалась в том, чтобы позволить высокоскоростным коммутаторам передавать трафик исключительно аппаратно. Дело в том, что аппаратная IP-маршрутизация долгое время была малодоступным удовольствием, и применять её на недорогих коммутаторах было нецелесообразно, а принимать решение на основе метки можно было бы просто и быстро.
Но в то же время появились сверхбольшие интегральные схемы (пусть я и не согласен с этим термином - английский VLSI гораздо лучше описывает суть), и задача экономии на анализе содержимого пакета стала не такой уж и актуальной. Кроме того появилось понятие FIB, которое предполагает, что для каждого пакета не нужно осуществлять поиск адресата в таблице маршрутизации и соответственно привлекать центральный процессор - вся горячая информация уже на линейной плате.
То есть по сути необходимость в таком механизме отпала.

Но внезапно стало понятно, что у коммутации по меткам есть незапланированный потенциал - совершенно неважно, что находится под меткой - IP, Ethernet, ATM, Frame Relay. А ещё она даёт возможность отвязаться от ограничений IP-маршрутизации.
Отсюда и берёт своё начало технология, утверждённая IETF - MPLS - MultiProtocol Label Switching. Шёл 1997-й год.
И эта, кажущаяся, возможно, незначительной, деталь дала начало новой эре в телекоммуникациях. Сегодня MPLS вы найдёте в любом более или менее крупном провайдере.

Основные применения MPLS сейчас:

• MPLS L2VPN
• MPLS L3VPN
• MPLS TE

О каждом из них мы поговорим в отдельных статьях - это чудовищно огромные темы. Но коротко мы затронем их в конце статьи.

MPLS

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

Несмотря на то, что MPLS не привязывается к типу сети, на которой он будет работать, в наше время он живёт в симбиозе только с IP. То есть сама сеть строится поверх IP, но переносить при этом она может данные многих других протоколов.
Но давайте уже перейдём к сути, и сначала я хочу сказать, что MPLS не заменяет IP-маршрутизацию , а работает поверх неё.

Чтобы быть более конкретным, я возьму такую сеть.

Сейчас она в полностью рабочем состоянии, но без всяких намёков на MPLS. То есть R1, например, видит R6 и может пинговать его Loopback.
ПК1 посылает ICMP-запрос на сервер 172.16.0.2. ICMP-запрос - это IP-пакет. На R1 согласно базовым принципам пакет уходит через интерфейс FE0/0 на R2 - так сказала Таблица Маршрутизации.
R2 после получения пакета проверяет адрес назначения, просматривает свою FIB, видит следующий маршрутизатор и отправляет пакет в интерфейс FE0/0.
И этот процесс повторяется раз за разом. Каждый маршрутизатор самостоятельно решает судьбу пакета.

Вот так совершенно привычно выглядит дамп трафика:

Что происходит, если мы активируем MPLS? Вот сразу же, в ту же секунду мир меняется. После этого на маршрутизаторах заполняются таблицы меток и строятся многочисленные LSP.

И теперь тот же путь будет проделан немного иначе.

Когда IP-пакет от ПК1 попадает в сеть MPLS первый маршрутизатор навешивает метку, дальше этот пакет идёт к точке назначения, а каждый следующий маршрутизатор меняет одну метку на другую. При выходе из сети MPLS метка снимается и дальше передаётся уже чистый IP-пакет, каким он был в самом начале.

Это основной принцип MPLS - маршрутизаторы коммутируют пакеты по меткам, не заглядывая внутрь пакета MPLS. Первый - добавляет, последний - удаляет.

Давайте рассмотрим шаг за шагом передачу пакета данных от ПК1 до узла назначения:

1. ПК1 - обычный компьютер - отправляет обычный пакет на удалённый сервер.

2. Пакет доходит до R1. Он добавляет метку 18. Она вставляется между заголовком IP и Ethernet.
Эту информацию он может взять из FIB:

По FIB видно, что пакет с адресатом 6.6.6.6 нужно снабдить меткой 18 и отправить в интерфейс FE0/0 .
Собственно это он и делает: добавляет заголовок и прописывает в него 18:

Дамп между R1 и R2 .

3. R2 получает этот пакет, в заголовке Ethernet видит, что это MPLS-пакет (Ethertype 8847), считывает метку и обращается к своей таблице меток:

Читаем по буквам: если пакет MPLS пришёл с меткой 18, её нужно поменять на 20 и отправить пакет в интерфейс FE0/0.

Дамп после R2.

4. R5 совершает аналогичные действия - видит, что пришёл пакет с меткой 20, её нужно поменять на 0 и отправить в FE1/0. Без всякого обращения к таблице маршрутизации.

5. R6, получив пакет MPLS, видит в своей таблице, что теперь метку надо снять. А, сняв её, видит уже, что адресат пакета - 172.16.0.2 - это Directly Connected сеть. Дальше пакет передаётся обычным образом по таблице маршрутизации уже безо всяких меток.

То есть целиком процесс выглядит так:

Не будем рассматривать конечные узлы, чтобы не усложнять схему.

Пока, вроде, всё просто, пусть и непонятно зачем.

Сейчас домены IGP и MPLS совпадают и MPLS только обещает нам в дальнейшем какие-то плюшки: L2VPN, L3VPN, MPLS TE.
Но, на самом деле, даже базовый MPLS дает нам преимущества, если мы вспомним, что мы провайдер.
Как провайдер, мы ведь не используем протоколы IGP для маршрутизации между AS. Для этого мы используем BGP. И именно в связке с BGP станут понятны преимущества MPLS.
Рассмотрим нашу сеть в связке с соседними AS:

Из выпуска о BGP мы знаем, что на каждом маршрутизаторе в нашей AS должен быть настроен BGP. Иначе мы не сможем передавать трафик соседних AS и наших клиентов, через нашу AS. Каждый маршрутизатор должен знать все маршруты.

Но это было до MPLS!
Когда в нашей сети настроен MPLS, нам больше не обязательно настраивать BGP на каждом маршрутизаторе в сети. Достаточно настроить его только на пограничных маршрутизаторах в AS, на тех, которые подключены к другим клиентам или провайдерам.

Но это не все хорошие новости. Кроме того, что BGP теперь можно не настраивать на каждом маршрутизаторе в AS, маршрутизаторам также не нужно создавать метку для каждого префикса BGP. Достаточно знать как добраться до IP-адреса, который указан как next-hop. То есть, если сессия BGP настроена между Loopback0 R1 и Loopback0 R6, то в таблице меток ничего не изменится, даже если каждый из них передает по BGP сотни тысяч маршрутов:

Например, маршрутизатору R1 по BGP от маршрутизатора R6 пришло несколько маршрутов:

Посмотрим как будут обрабатываться пакеты, которые идут в сеть 100.0.0.0/16:

В выводе выше видно, что пакетам будет добавляться метка 27.
И, если посмотреть в таблицу меток, то там нет меток для маршрутов, которые известны по BGP, но есть метка 27 и она соответствует 6.6.6.6/32. А это именно тот адрес, который мы видели в маршрутах, которые пришли по BGP от R6:

Пример настройки вы можете найти .

Мы немного забежали вперед, но теперь, когда стало понятнее какие преимущества дает даже базовый MPLS, мы можем окунуться в понятийный аппарат в мире MPLS.

Терминология

Label - метка - значение от 0 до 1 048 575. На основе неё LSR принимает решение, что с пакетом делать: какую новую метку повешать, куда его передать.
Является частью заголовка MPLS.

Label Stack - стек меток. Каждый пакет может нести одну, две, три, да хоть 10 меток - одну над другой. Решение о том, что делать с пакетом принимается на основе верхней метки. Каждый слой играет какую-то свою роль.
Например, при передаче пакета используется транспортная метка, то есть метка, организующая транзит от первого до последнего маршрутизатора MPLS.
Другие могут нести информацию о том, что данный пакет принадлежит определённому VPN.
В этом выпуске метка всегда будет только одна - больше пока не нужно.

Push Label - операция добавления метки к пакету данных - совершается в самом начале - на первом маршрутизаторе в сети MPLS (в нашем примере - R1).

Swap Label - операция замены метки - происходит на промежуточных маршрутизаторах в сети MPLS - узел получает пакет с одной меткой, меняет её и отправляет с другой (R2, R5).

Pop Label - операция удаления метки - выполняется последним маршрутизатором - узел получает пакет MPLS и убирает верхнюю метку перед передачей его дальше (R6).

На самом деле метка может добавляться и удаляться где угодно внутри сети MPLS.
Всё зависит от конкретных сервисов. Правильнее будет сказать, что метка добавляется первым маршрутизатором пути (LSP), а удаляется последним.
Но в этой статье для простоты мы будем говорить о границах сети MPLS.
Кроме того, удаление верхней метки ещё не означает, что остался чистый IP-пакет, если речь идёт о стеке меток. То есть если над пакетом с тремя метками совершили операцию Pop Label, то меток осталось две и дальше он по-прежнему обрабатывается, как MPLS. А в нашем примере была одна, а после не останется ни одной - и это уже дело IP.

LSR - Label Switch Router - это любой маршрутизатор в сети MPLS. Называется он так, потому что выполняет какие-то операции с метками. В нашем примере это все узлы: R1, R2, R3, R4, R5, R6.
LSR делится на 3 типа:
Intermediate LSR - промежуточный маршрутизатор MPLS - он выполняет операцию Swap Label (R2, R5).
Ingress LSR - «входной», первый маршрутизатор MPLS - он выполняет операцию Push Label (R1).
Egress LSR - «выходной», последний маршрутизатор MPLS - он выполняет операцию Pop Label (R6).
LER - Label Edge Router - это маршрутизатор на границе сети MPLS.
В частности Ingress LSR и Egress LSR являются граничными, а значит они тоже LER.

LSP - Label Switched Path - путь переключения меток. Это однонаправленный канал от Ingress LSR до Egress LSR, то есть путь, по которому фактически пройдёт пакет через MPLS-сеть. Иными словами - это последовательность LSR.
Важно понимать, что LSP на самом деле однонаправленный. Это означает, что, во-первых, трафик по нему передаётся только в одном направлении, во-вторых, если существует «туда», не обязательно существует «обратно», в-третьих, «обратно» не обязательно идёт по тому же пути, что «туда». Ну, это как туннельные интерфейсы в GRE.

Как выглядит LSP?

Да, вот так непрезентабельно.
Это компилированный вывод с четырёх LSR - R1, R2, R5, R6. То есть на LSR вы не увидите законченной последовательности узлов от входа до выхода, по типу атрибута AS-PATH в BGP. Здесь каждый узел знает только входную и выходную метки. Но LSP при этом существует.

Это похоже немного на IP-маршрутизацию. Несмотря на то, что существует путь от точки А до точки Б, таблица маршрутизации знает только следующий узел, куда надо отправлять трафик. Но разница в том, что LSR не принимает решение о каждом пакете на основе адреса назначения - путь определён заранее.

И одно из самых важный понятий, с которым необходимо разобраться - FEC - Forwarding Equivalence Class . Мне оно почему-то давалось очень тяжело, хотя по сути - всё просто. FEC - это классы трафика. В простейшем случае идентификатором класса является адресный префикс назначения (грубо говоря, IP-адрес или подсеть назначения).
Например, есть потоки трафика от разных клиентов и разных приложений, которые идут все на один адрес - все эти потоки принадлежат одному классу - одному FEC - используют один LSP.
Если мы возьмём другие потоки от других клиентов и приложений на другой адрес назначения - это будет соответственно другой класс и другой LSP.

В теории помимо адреса назначения FEC может учитывать, например, метки QoS, адрес источника, идентификатор VPN или тип приложений. Важно понимать тут, что пакеты одного FEC не обязаны следовать на один и тот же адрес назначения. И в то же время, если даже и два пакета следуют в одно место, не обязательно они будут принадлежать одному FEC.

Я поясню для чего всё это нужно. Дело в том, что для каждого FEC выбирается свой LSP - свой путь через сеть MPLS. И тогда, например, для WEB-сёрфинга вы устанавливаете приоритет - это будет один FEC - а для VoIP - - другой FEC. И далее можно указать, что для FEC BE LSP должен идти широким, но долгим и негарантированным путём, а для FEC EF - можно узким, но быстрым.

К сожалению или к счастью, но сейчас в качестве FEC может выступать только IP-префикс. Такие вещи, как маркировка QoS не рассматриваются.

Если вы обратите внимание на таблицу меток, FEC там присутствует, поскольку параметры замены меток определяются как раз таки на основе FEC, но делается это только в первый момент времени - когда эти метки распределяются. Когда же по LSP бежит реальный трафик, никто, кроме Ingress LSR, уже не смотрит на него - только метки и интерфейсы. Всю работу по определению FEC и в какой LSP отправить трафик берёт на себя Ingress LSR - получив чистый пакет, он его анализирует, проверяет какому классу тот принадлежит и навешивает соответствующую метку. Пакеты разных FEC получат разные метки и будут отправлены в соответствующие интерфейсы.
Пакеты одного FEC получают одинаковые метки.

То есть промежуточные LSR - это молотилки, которые для всего транзитного трафика только и делают, что переключают метки. А всю интеллектуальную работу выполняют Ingress LSR.

LIB - Label Information Base - таблица меток. Аналог таблицы маршрутизации (RIB) в IP. В ней указано для каждой входной метки, что делать с пакетом - поменять метку или снять её и в какой интерфейс отправить.
LFIB - Label Forwarding Information Base - по аналогии с FIB - это база меток, к которой обращается сетевой процессор. При получении нового пакета нет нужды обращаться к CPU и делать lookup в таблицу меток - всё уже под рукой.

Одна из первоначальных идей MPLS - максимально разнести Control Plane и Data Plane - ушла в небытие.
Разработчикам хотелось, чтобы при передаче пакета через маршрутизатор не было никакого анализа - просто прочитал метку, поменял на другую, передал в нужный интерфейс.
Чтобы добиться этого, как раз и было два разнесённых процесса - относительно долгое построение пути (Control Plane) и быстрая передача по этому пути трафика (Data Plane)

Но с появлением дешёвых чипов (ASIC, FPGA) и механизма FIB обычная IP-передача тоже стала быстрой и простой.
Для маршрутизатора без разницы, куда смотреть при передаче пакета - в FIB или в LFIB.
А вот что, несомненно, важно и полезно - так это, что безразличие MPLS к тому, что передаётся под его заголовком - IP, Ethernet, ATM. Не нужно городить GRE или какие-то другие до боли в суставах неудобные VPN. Но об этом ещё поговорим.

Заголовок MPLS

Весь заголовок MPLS - это 32 бита. Формат полей и их длина фиксированы. Часто весь заголовок называют меткой, хотя это не совсем и верно.

Label - собственно сама метка. Длина - 20 бит.
TC - Traffic Class. Несёт в себе приоритет пакета, как поле DSCP в IP.
Длина 3 бита. То есть может кодировать 8 различных значений.
Например, при передаче IP-пакета через сеть MPLS значению в поле DSCP определённым образом ставится в соответствие значение TC. Таким образом пакет может почти одинаково обрабатываться в очередях на всём протяжении своего пути, как на участке чистого IP, так и в MPLS.
Но, естественно, это преобразование с потерями - шести битам DSCP тесно в 3 битах TC: 64 против 8. Поэтому существует специальная таблица соответствий, где целый диапазон - это всего лишь одно значение.

Первоначально поле носило название EXP (экспериментальное), а его содержимое не было регламентировано. Предполагалось, что оно может быть использовано для исследований, внедрения нового функционала. Но это в прошлом.
Если кто-то с вами спорит, что это поле экспериментальное и не утверждено формально за функцией QoS - он не шарит порядочно отстал от жизни .

=====================

В сети настроена простая политика QoS, в которой IP-пакеты, которые идут с хоста 10.0.17.7 на адрес 6.6.6.6, маркируются и передаются по сети MPLS. Для маркировки пакетов используется поле EXP, значение поля 3.

Схема

На маршрутизаторе R6 настроена политика QoS, которая классифицирует пакеты по полю EXP.
Но, при проверке оказалось, что политика на R6 не отрабатывает. То есть, нет пакетов, приходящих со значением EXP 3 и все пакеты попадают в class default.

Задание: Исправить конфигурацию так, чтобы политика на R6 срабатывала.

Маршрутизатор R7 используется в качестве клиента. Соответственно MPLS между R7 и R1 не включен.

Подробности задачи и конфигурации .
=====================

S - Bottom of Stack - индикатор дна стека меток длиной в 1 бит. Заголовков MPLS на пакете может быть несколько, например, внешняя для коммутации в сети MPLS, а внутренняя указывает на определённый VPN. Чтобы LSR понимал с чем он имеет дело. В бит S записывается «1», если это последняя метка (достигнуто дно стека) и «0», если стек содержит больше одной метки (ещё не дно). То есть LSR не знает, сколько всего меток в стеке, но знает, одна она или больше - да этого и достаточно на самом-то деле. Ведь любые решения принимаются на основе только самой верхней метки, независимо от того, что там под ней. Зато, снимая метку, он уже знает, что дальше сделать с пакетом: продолжить работу с процессом MPLS или отдать его какому-то другому (IP, Ethernet, ATM, FR итд).

Вот к этой фразе: “Зато, снимая метку, он уже знает, что дальше сделать с пакетом” - надо дать пояснение. В заголовке MPLS, как вы заметили, нет информации о содержимом (как Ethertype в Ethernet’е или Protocol в IP).
Это с одной стороны хорошо - внутри может быть что угодно - выше гибкость, а с другой стороны, как без анализа содержимого теперь определить, какому процессу передавать всё это хозяйство?
А тут небольшая хитрость - маршрутизатор, как вы увидите дальше, всегда сам выделяет метку и передаёт её своим соседям, поэтому он знает, для чего её выделял - для IP или для Ethernet или ещё для чего-то. Поэтому он просто добавляет эту информацию в свою таблицу меток. И в следующий раз, когда делает операцию Pop Label, он уже из таблицы (а не из пакета) знает, что дальше делать.

В общем, стек тут в классическом понимании - последним положили, первым взяли (LIFO - Last Input - First Output).

В итоге, несмотря на то, что длина заголовка MPLS фиксированная, самих заголовков может быть много - и все они располагаются друг за другом.

TTL - Time To Live - полный аналог . Даже той же самой длиной обладает - 8 бит. Единственная задача - не допустить бесконечного блуждания пакета по сети в случае петли. При передаче IP-пакета через сеть MPLS значение IP TTL может быть скопировано в MPLS TTL, а потом обратно. Либо отсчёт начнётся опять с 255, а при выходе в чистую сеть IP значение IP TTL будет таким же, как до входа.

Как видите, заголовок MPLS втискивается между канальным уровнем и теми данными, которые он несёт - в случае IP - сетевым. Поэтому метафорически MPLS называется технологией 2,5 уровня, а заголовок - Shim-header - заголовок-клин.
К слову, метка не обязательно должна быть в заголовке MPLS. Согласно решению IETF, она может встраиваться в заголовки ATM, AAL5, Frame Relay.

Вот как оно выглядит в жизни:

Пространство меток

Как уже было сказано выше, может существовать 2^20 меток.

Из них несколько зарезервировано:

0 : IPv4 Explicit NULL Label . «Явная пустая метка». Она используется на самом последнем пролёте MPLS - перед Egress LSR - для того, чтобы уведомить его, что эту метку 0 можно снять, не просматривая таблицу меток (точнее LFIB).
Для тех FEC, что зарождаются локально (directly connected) Egress LSR выделяет метку 0 и передаёт своим соседям - предпоследним LSR (Penultimate LSR).
При передаче пакета данных предпоследний LSR меняет текущую метку на 0.
Когда Egress LSR получает пакет, он точно знает, что верхнюю метку нужно просто удалить.

Так было не всегда. Изначально предлагалось, что метка 0 может быть только на дне стека меток и при получении пакета с такой меткой, LSR должен вообще очистить упоминания об MPLS и начать обрабатывать данные.
В какой-то момент теоретики под давлением практиков согласились, что это нерационально и реального применения им придумать не удалось, поэтому отказались от обоих условий.
Так что теперь метка 0 не обязательно последняя (нижняя) и при операции Pop Label удаляется только она, а нижние остаются и пакет дальше обрабатывается в соответствии с новой верхней меткой.

1 : Метка Router Alert Label - аналог опции Router Alert в IP - может быть где угодно, кроме дна стека. Когда пакет приходит с такой меткой, он должен быть передан локальному модулю, а дальше он коммутируется в соответствии с меткой, которая была ниже - реальной транспортной, при этом наверх стека снова должна быть добавлена метка 1.

2 : IPv6 Explicit NULL Label - то же, что и 0, только с поправкой на версию протокола IP.

3 : Implicit Null . Фиктивная метка, которая используется для оптимизации процесса передачи пакета MPLS на Egress LSR. Эта метка может анонсироваться, но никогда не используется в заголовке MPLS реально. Рассмотрим её попозже.

4-15 : Зарезервированы.

В зависимости от вендора, могут быть зафиксированы и другие значения меток, например, на оборудовании Huawei метки 16-1023 используются для статических LSP, а всё, что выше - в динамических. В Cisco доступные метки начинаются уже с 16-й.

На следующей схеме все маршрутизаторы, кроме R5, это маршрутизаторы Huawei. R5 - Cisco.

Схема

Для приведенной ниже конфигурации маршрутизатора R5, необходимо настроить его таким образом, чтобы распределение значений меток соответствовало Huawei. Речь о том, что в Huawei динамические метки начинаются с 1024, а в Cisco с 16.

Конфигурация R5

ip cef
!
interface Loopback0

ip router isis
!
interface FastEthernet0/0
description to R4

ip router isis
mpls ip
!
interface FastEthernet0/1
description to R2

ip router isis
mpls ip
!
interface FastEthernet1/0
description to R6

ip router isis
mpls ip
!
router isis
net 10.0000.0000.0005.00
!

Быстро, просто, понятно, хотя и не всегда нужно, чтобы все знали обо всём.

Второй режим - DoD - Downstream-on-Demand . LSR знает FEC, у него есть соседи, но пока они не спросят, какая для данного FEC метка, LSR сохраняет молчание.

Этот способ удобен, когда к LSP предъявляются какие-то требования, например, по ширине полосы. Зачем слать метку просто так, если она тут же будет отброшена? Лучше вышестоящий LSR запросит у нижестоящего: мне нужна от тебя метка для данного FEC - а тот: «ок, на».

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

Ordered Control против Independent Control

Во-вторых , LSR может дожидаться, когда со стороны Egress LER придёт метка данного FEC, прежде чем рассказывать вышестоящим соседям. А может разослать метки для FEC, как только узнал о нём.

Первый режим называется Ordered Control

Гарантирует, что к моменту передачи данных весь путь вплоть до выходного LER будет построен.

Второй режим - Independent Control .

То есть метки передаются неупорядоченно. Удобен тем, что трафик можно начинать передавать ещё до того, как весь путь построен. Этим же и опасен.

Liberal Label Retention Mode против Conservative Label Retention Mode

В-третьих , важно, как LSR обращается с переданными ему метками.
Например, в такой ситуации, должен ли R1 хранить хранить информацию о метке 20, полученной от соседа R3, который не является лучшим способом добраться до R6?

А это определяется режимом удержания меток.
Liberal Label Retention Mode - метки сохраняются. В случае, когда R3 станет следующим шагом (например, проблемы с основным путём), трафик будет перенаправлен скорее, потому что метка уже есть. То есть скорость реакции выше, но велико и количество использованных меток.
Conservative Label Retention Mode - лишняя метка отбрасывается сразу, как она получена. Это позволяет сократить количество используемых меток, но и MPLS среагирует медленнее в случае аварии.

PHP

Нет, это не тот PHP, о котором вы подумали. Речь о Penultimate Hop Popping . Все инженеры немного оптимизаторы, вот и тут ребята подумали: а зачем нам два раза обрабатывать заголовки MPLS - сначала на предпоследнем маршрутизаторе, потом ещё на выходном.
И решили они, что метку нужно снимать на предпоследнем LSR и назвали сие действо - PHP.
Для PHP существует специальная метка - 3.
Возвращаясь к нашему примеру, для FEC 6.6.6.6 и 172.16.0.2 R6 выделяет метку 3 и сообщает её R5.
При передаче пакета на R6 R5 должен назначить ему фиктивную метку - 3, но фактически она не применяется и в интерфейс отправляется голый IP-пакет (стоит заметить, что PHP работает только в сетях IP) - то есть процедура Pop Label была выполнена ещё на R5.

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

С тем, как трафик передаётся, вроде, более или менее понятно. Но кто выполняет весь титанический труд по созданию меток, заполнению таблиц?

Протоколы распространения меток

Их не так много - три: LDP, RSVP-TE, MBGP.
Есть две глобальные цели - распространение траспортных меток и распространение меток сервисных.
Поясним: транспортные метки используются для передачи трафика по сети MPLS. Это как раз те, о которых мы говорим весь выпуск. Для них используются LDP и RSVP-TE.

Сервисные метки служат для разделения различных сервисов. Тут на арену выходят MBGP и отросток LDP - .
В частности MBGP позволяет, например, пометить, что вот такой-то маршрут принадлежит такому-то VPN. Потом он этот маршрут передаёт, как vpn-ipv4 family своему соседу с меткой, чтобы тот смог потом отделить мух от котлет.
Так вот, чтобы он мог отделить, ему и нужно сообщить о соответствии метка-FEC.
Но это действие другой пьесы, которую мы сыграем ещё через полгода-год.

Обязательным условием работы всех протоколов динамического распределения меток является базовая настройка IP-связности. То есть на сети должны быть запущены IGP.

Ну, вот теперь, когда я вас окончательно запутал, можно начинать распутывать.
Итак, как проще всего распределить метки? Ответ - включить LDP.

LDP

Протокол с очень прозрачным названием - Labed Distribution Protocol - имеет соответствующий принцип работы.
Рассмотрим его на сети linkmeup, которую мы мурыжим весь выпуск:

1. После включения LDP LSR делает мультикастовую рассылку UDP-дейтаграмм во все интерфейсы на адрес 224.0.0.2 и порт 646, где активирован LDP - так происходит поиск соседей.
TTL таких пакетов равен 1, поскольку LDP-соседство устанавливается между непосредственно подключенными узлами.

Вообще говоря, это не всегда так - LDP сессия может устанавливаться для определённых целей и с удалённым узлом, тогда это называется tLDP - . О нём мы поговорим в других выпусках.

Такие сообщения называются Hello .

2. Когда соседи обнаружены, устанавливается TCP соединение с ними, тоже по порту 646 - Initialization . Дальнейшие сообщения (кроме Hello) передаются уже с TTL равным 255.

3. Теперь LSR периодически обмениваются сообщениями Keepalive адресно по TCP и по-прежнему не оставляют попыток найти соседей с помощью Hello.

4. В какой-то момент один из LSR обнаруживает в себе вторую личность - Egress LSR - то есть он является выходным для какого-то FEC. Это факт, о котором нужно сообщить миру.
В зависимости от режима он ждёт запроса на метку для данного FEC, либо рассылает его сразу же.

Эта информация передаётся в сообщении Label Mapping Message . Исходя из названия, оно несёт в себе соответствие FEC и метки.

R5 получает информацию о соответствии FEC 6.6.6.6/32 и метки 3 (implicit null) и записывает её в свою таблицу меток. Теперь, когда ему нужно будет отправить данные на 6.6.6.6 он будет знать, что нужно удалить верхний заголовок MPLS и отправить оставшийся пакет в интерфейс FE1/0.

Теперь R5 знает, что если пришёл пакет MPLS с меткой 20, его нужно передать в интерфейс FE1/0, сняв метку, то есть выполнив процедуру PHP.

R2 получает от R5 информацию о соответствии FEC-метка (6.6.6.6 - 20), вносит её в таблицу и, создав свою входную метку (18), передаёт её ещё выше. И так далее, пока все LSR не получат свою выходную метку.

Таким образом у нас построен LSP от R1 до R6. R1 при отправке пакета на 6.6.6.6/32 добавляет к нему метку 18 (Push Label) и посылает его в порт FE0/0. R2, получив пакет с меткой 18, меняет метку на 20 (Swap Label) и отправляет его в порт FE0/0. R5 видит, что для пакета с меткой 20, надо выполнить PHP (выходная метка - 3 - implicit null), снимает метку (Pop Label) и отправляет данные в порт FE1/0.

При этом параллельно оказались построены LSP от R2 до R6, от R5 до R6, от R4 до R6 итд. То есть ото всех LSR - просто я не показал это на иллюстрации.

Если у вас хватит сил, то на гифке ниже можно весь процесс посмотреть в динамике.

Естественно, вы понимаете, что не только R6 вдруг начал рассылать свои соответствия FEC-метка, но и все другие - R1 про 1.1.1.1/32, R2 - 2.2.2.2/32 итд. Все эти сообщения молниеносно разносятся по сети MPLS, строя десятки LSP. В результате каждый LSR будет знать про все существующие FEC и будет построен соответствующий LSP.

Опять же на гифке выше процесс показан не до конца, R1 потом передаёт информацию на R3, R3 на R4, R4 на R5.
И если мы посмотрим на R5, то увидим, что для FEC 6.6.6.6/32 у нас не одна выходная метка, как ожидалось, а 3:

Более того, сам R6 запишет метку для FEC 6.6.6.6, которую получит от R5:

Inuse - правильная - imp-null в сторону R6. Но две других из кольца - от R2 и R4. Это не ошибка и не петля - просто R2 и R4 сгенерировали эти метки для известного им из таблицы маршрутизации FEC 6.6.6.6/32.

Возникает два вопроса:
1) Как он планирует ими воспользоваться? Они же бестолковые. Ответ: а никак. Не может быть в нашей сети такой ситуации, когда 2.2.2.2 или 4.4.4.4 будут следующими узлами на пути к 6.6.6.6 - IGP так маршрут не построит. А значит и использованы метки не будут. Просто LDP-то глупый - его сообщения разбредаются по всей сети, пробиваясь в каждую щёлочку. А умный LSR уже решит каким пользоваться.
2) Что насчёт петель? Не будут сообщения LDP курсировать по сети пока TTL не истечёт?
А тут всё просто - получение нового сообщения Label Mapping Message не инициирует создание нового - полученное соответствие просто записывается в таблицу LDP. То есть в нашем случае R5 уже придумал один раз метку для FEC 6.6.6.6/32 и разослал её своим вышестоящим соседям и она уже не поменяется, пока процесс LDP не перезагрузится.

Возможно, вы уже заметили, что при настройке LDP есть возможность включить функционал Loop Detection, но спешу вас успокоить - это для сетей, где нет TTL, например, ATM. Этот функционал переключит LDP в режим DoD.

Это базовая информация о том, как работает LDP.
На самом деле здесь всё очень сильно зависит от производителя. В принципе LDP поддерживает всевозможные режимы работы с метками: и DoD/DU, и Independent Control/Ordered Control, и Conservative/Liberal Label Retention. Это никак не регламентируется RFC, поэтому каждый вендор волен выбирать свой путь.
Например, в основном все используют DU для LDP, но при этом в Juniper метки раздаются упорядоченно, а в Cisco независимо.
В качестве FEC в Huawei и Juniper выбираются только Loopback-интерфейсы LSR, а Cisco FEC создаётся для всех записей в таблице маршрутизации.

Но это всё едва ли как-то отразится на реальной сети.

Самое важное, что нужно понимать относительно LDP - он не использует в своей работе протоколы динамической маршрутизации - по принципу работы он похож на : наводняет всю сеть метками, но при этом он опирается на информацию из таблицы маршрутизации LSR. И если на R1 придёт две метки для одного FEC от разных соседей, то он выберет для LSP только ту, которая получена через лучший интерфейс до этого FEC по информации из ТМ.
Это означает три вещи:

• Вы вольны выбирать IGP, который вам больше нравится, хоть RIP .
• LDP всегда строит только один (лучший) маршрут и не может построить, например, резервный.
• При изменении топологии сети LSP перестроится в соответствии с обновившейся таблицей маршрутизации, то есть сначала должен сойтись IGP, и только потом поднимется LSP.

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

Для включения MPLS глобально, необходимо дать две команды:
R1(config)#ip cef
R1(config)#mpls ip
Первая - это уже стандарт де факто и де юре почти на любом сетевом оборудовании - она запускает механизм CEF на маршрутизаторе, вторая стартует MPLS и LDP глобально (тоже может быть дана по умолчанию).

Router ID (а в более общей (нецисковской) терминологии LSR ID) в MPLS выбирается незамысловато:

1. Самый большой адрес Loopback-интерфейсов
2. Если их нет - самый большой IP-адрес, настроенный на маршрутизаторе.

Естественно, не стоит доверять автоматике - настроим LSR ID вручную:
R1(config)# mpls ldp router-id Loopback0 force
Если не добавлять ключевое слово «force» , Router ID изменится только при переустановлении LDP-сессии. «Force» заставляет маршрутизатор сменить Router ID насильно и при необходимости (если тот поменялся) переустанавливает соединение LDP.

Далее на нужных интерфейсах даём команду mpls ip :
R1(config)#interface FastEthernet 0/0
R1(config-if)#mpls ip
R1(config)#interface FastEthernet 0/1
R1(config-if)#mpls ip
Cisco здесь опять использует свой принцип ленивого инженера - минимум усилий со стороны персонала. Команда mpls ip включает на интерфейсе LDP одновременно с MPLS, желаем мы этого или нет. Точно так же команда ip pim sparse-mode включает IGMP на интерфейсе, как я описывал это в статье про .
После активации LDP маршрутизатор начинает прощупывать почву по UDP:

Проверяки посылаются на мультикастовый адрес 224.0.0.2.

Теперь повторяем все те же манипуляции на R2
R2(config)#ip cef
R2(config)#mpls ip
R2(config)# mpls ldp router-id Loopback0 force
R2(config)#interface FastEthernet 0/0
R2(config-if)#mpls ip
R2(config)#interface FastEthernet 0/1
R2(config-if)#mpls ip
и наслаждаемся результатом.
R2 тоже ищет соседей.

Узнали друг про друга, и R2 поднимает LDP-сессию:

Если интересно, как они устанавливают TCP-соединение

Теперь они соседи, что легко проверяется командой show mpls ldp neighbor .

Вот тут уже видно детали - R1 передаёт сразу 12 FEC - по одной для каждой записи в своей таблице маршрутизации. В такой же ситуации Huawei или Juniper передали бы только шесть FEC - адреса Loopback-интерфейсов, потому что они по умолчанию считают за FEC только /32-префиксы.
В этом плане Cisco очень неэкономно относится к ресурсу меток.
Впрочем, это поведение можно изменить на любом оборудовании. В нашем случае может помочь команда mpls ldp advertise-labels .

Но как так, спросите вы? Разве достаточно иметь метки только в Loopback?

Если вспомнить о том, что мы рассматривали вначале статьи, что BGP префиксы не получают свои метки, и что метки нужны только для next-hop, то становится понятно, что меток для Loopback вполне хватит.

Для того чтобы добраться до других сетей внутри нашей AS, нам достаточно IGP.

=====================

Если в Cisco по умолчанию анонсируются метки для всех сетей (кроме полученных по BGP), то в Juniper, по умолчанию анонсируется только loopback.

Схема

Все маршрутизаторы, кроме R5, это маршрутизаторы Juniper.

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

Конфигурация R5

ip cef
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip router isis
!
interface FastEthernet0/0
description to R4
ip address 10.0.45.5 255.255.255.0
ip router isis
mpls ip
!
interface FastEthernet0/1
description to R2
ip address 10.0.25.5 255.255.255.0
ip router isis
mpls ip
!
interface FastEthernet1/0
description to R6
ip address 10.0.56.5 255.255.255.0
ip router isis
mpls ip
!
router isis
net 10.0000.0000.0005.00
!
mpls ldp router-id Loopback0 force

И после этого посмотрим повторно на таблицу коммутации MPLS на R1 :

Для всех FEC уже появились метки.
Давайте пройдёмся по LSP от R1 до R6 и посмотрим как меняются метки по пути

Значит
1. Когда R1 21 Fa0/0 и поменять метку на 18 .
2. Когда R2 получает пакет MPLS с меткой 18 , он должен передать его в интерфейс Fa0/0 и поменять метку на 20 .
3. Когда R5 получает пакет MPLS с меткой 20 , он должен передать его в интерфейс Fa1/0 и снять метку - PHP .

В этом случае LSR даже не задумываются о том, чтобы глянуть что-то в таблице маршрутизации или в ip cef - они просто жонглируют метками.

Таблица коммутации, которую мы уже смотрели командой show mpls forwarding table - это LFIB (Lable Forwarding Information Base ) - почти что прописная истина для передачи данных - это Data Plane. Но что же там с Control Plane? Вряд ли LDP знает столько же? Наверняка у него ещё есть козыри в рукаве?
Так и есть:

Для каждого FEC мы тут видим информацию о различных метках:
local binding - что этот LSR передаёт соседям
remote binding - что этот LSR получил от соседей.

На иллюстрации выше вы можете видеть слово «tib». TIB - это Tag Information Base , которая правильно называется Label Information Base - LIB.
Это пережиток почившего в бозе - прародителя LDP.

Обратите внимание, что везде по 2 remote binding - это два пути получения меток. Например, до R2 можно добрать от R1 напрямую, а можно через R3-R4-R5-R2.
То есть, понимаете да? Мало того, что он из каждой записи в таблице маршрутизации делает FEC, так этот негодяй ещё и Liberal Retention Mode использует для удержания меток.
Давайте подытожим: по умолчанию LDP в Cisco работает в следующих режимах:

• Independent Control
• Liberal Retention Mode
• В качестве FEC выбираются все записи в таблице маршрутизации

Короче говоря, щедроты его не знают границ.

Есть ещё команда show mpls ip binding . Она показывает нечто похожее и позволяет кроме того быстро узнать, какой путь сейчас активен, то есть как построен LSP:

И последний, пожалуй, вопрос, который возникает в связи со всеми этими LSP - когда маршрутизатор сам является Ingress LSR, как он понимает, что нужно делать с пакетами, как выбрать LSP?
А для этого вот и придётся заглянуть в IP CEF. Вообще именно на Ingress LSR ложится всё бремя обработки пакета, определения FEC и назначения правильных меток.

Тут вам и Next Hop и выходной интерфейс и выходная метка

И тут уже вы должны заметить, что в LDP понятия LER, Ingress LSR, Egress LSR - это не роль каких-то конкретных узлов или характеристика местоположения узла в сети. Они неотделимы от FEC и LSP, индивидуальны для них. То есть для каждого конкретного FEC есть один или несколько Egress LSR и множество Ingress LSR (как правило, все маршрутизаторы), до которых ведут LSP.
Даже скажем так, понятия LER возникают когда мы говорим о конкретном LSP, тогда мы можем сказать, кто является Ingress, кто Egress.

MPLS и BGP

До сих пор мы говорили о том как MPLS взаимодействует с IGP-протоколами. Мы убедились, что ничего сложного в этом нет и что настройки также довольно простые.

Но самое интересное кроется во взаимодействии MPLS с BGP. В этом выпуске мы лишь слегка затронем эту тему. Но в следующих, мы поговорим подробнее о том, какую роль играет BGP, и как с помощью него и MPLS мы можем организовывать различные типы VPN.
Сейчас же нам надо разобраться как MPLS и BGP взаимодействуют на самом базовом уровне.

Главное отличие BGP от IGP заключается в том, что MPLS не создает метки для маршрутов BGP. Если вспомнить о том, какое количество маршрутов передает BGP, то становится понятно, что это очень хорошая идея. Как же тогда состыковать MPLS и BGP?
Все просто:

1. создаем метки только для адресов, которые будут указаны как next-hop для маршрутов, которые мы получаем по BGP (тут надо не забыть про next-hop-self для IBGP-соседей).
2. Когда нашему Ingress LSR понадобится передать пакеты по маршруту, который был получен по BGP, отправляем их к next-hop, который указан в маршруте и используем ту метку, которая была создана для него.

Теперь, вместе того чтобы настраивать BGP на каждом маршрутизаторе в нашей AS, мы можем настраивать его только на пограничных маршрутизаторах, к которым подключены клиенты или другие провайдеры.

Посмотрим на примере сети:

Если нам надо добраться с R1 до сетей Филькин Сертификат, мы смотрим, что они доступны через R6 и «пролетаем» через MPLS до адреса 6.6.6.6. А когда мы добираемся до R6, он уже знает куда идти дальше. Аналогично будет и наоборот, в Балаган-Телеком.

Конфигурацию для этой схемы и пару команд с выводом информации, можно найти по ссылке .

В сети настроены MPLS и OSPF. MPLS настроен во всей сети, кроме соединения между R7 и R1.
Между маршрутизаторами R1-R2-R3-R4-R5-R6 трафик должен передаваться силами MPLS.
В сети также настроен BGP, который работает между R1 и R6.

Для маршрутов BGP не генерируются метки.
Для того чтобы R1 мог добраться до маршрутов, которые получены по BGP от R6, пакеты передаются средствами MPLS до IP-адреса, который указан как next-hop в маршрутах BGP.

Сейчас с R7 недоступен маршрут, который анонсируется по BGP маршрутизатором R6.

Задание:
Восстановить работу сети, чтобы с R7 пинговался адрес 100.0.0.1.

Ограничения:
Нельзя менять настройки BGP.

Схема

Подробности задачи и конфигурации узлов .
=====================

RSVP-TE

LDP хорош. Работает он просто и понятно. Но есть такая технология, как MPLS TE - Traffic Engineering. И ей недостаточно лучшего маршрута, который может обеспечить LDP.
Управление трафиком подразумевает, что вы можете направить трафик между узлами как вам угодно, учитывая различные ограничения.
Например, в нашей сети клиент имеет две точки подключения своих узлов - на R1 и на R6. И между ними он просит предоставить ему VPN с гарантированной шириной канала в 100 Мб/с. Но при этом у нас в сети ещё и обычные ШПДшники видео гоняют с вконтактика и дюжина других клиентов, которые VPN арендуют, но полосу им резервировать не надо.
Если не вмешаться в эту ситуацию, где-нибудь на R2 может возникнуть перегруз, и 100 Мб/с для дорогого клиента не достанется.

MPLS TE позволяет пройти по всей сети от отправителя до получателя и зарезервировать ресурсы на каждом узле. Если вы знакомы с концепцией IntServ, то да, это именно она - организовать QoS на всём протяжении пути, вместо того, чтобы позволить каждому маршрутизатору самому принимать решение для проходящего пакета.
Собственно, протокол RSVP (Resource ReSerVation Protocol ) изначально (в 1993-м году) и был задуман для организации IntServ в IP-сетях. Он должен был донести информацию о QoS для какого-то конкретного потока данных до каждого узла и заставить его зарезервировать ресурсы.

В первом приближении работает он просто.

1) Узел-источник хочет отправить поток данных со скоростью 5 Мб/с. Но перед этим он посылает RSVP запрос на резервирование полосы до получателя - Path Message . Это сообщение содержит некие идентификаторы потока, по которым узел потом сможет идентифицировать принадлежность полученных IP-пакетов потоку, и требуемую ширину полосы.
2) Сообщение Path передаётся от узла к узлу до самого получателя. Куда его послать, определяется на основе таблицы маршрутизации.
3) Каждый маршрутизатор, получив Path, проверяет свои ресурсы. Если у него есть достаточно свободной полосы, он настраивает свои внутренние алгоритмы так, чтобы пакеты потока были обработаны как следует и пропускной способности всегда хватало.
4) Если же у него нет необходимых 5 Мб/с (занято другими потоками), он отказывает в выделении ресурсов и возвращает соответствующее сообщение отправителю.
5) Пакет Path доходит до получателя потока, тот отправляет назад сообщение Resv , подтверждая выделение ресурсов на всём протяжении пути.
6) Изначальный отправитель, получив Resv, понимает, что всё для него готово, и он может отправлять данные.

На самом деле под этими четырьмя простыми шагами лежат гораздо более сложные процессы, но нам это не интересно.

А вот что нам интересно - так это расширение RSVP для Traffic Engineering , или проще - RSVP TE , которое было разработано специально для MPLS TE.
Его задача такая же, как у LDP - распределить метки между LSR и скомпилировать в итоге LSP от получателя до отправителя. Но теперь, как вы уже поняли, появляются нюансы - LSP должен удовлетворять определённым условиям.

RSVP TE позволяет строить основной и запасной LSP, резервировать ресурсы на всех узлах, обнаруживать аварии на сети, строить заранее обходные пути, делать быстрое перенаправление трафика, избегать каналов, которые физически проходят по одному пути.
Но всё это мы будем обсуждать в статье о MPLS TE через пару выпусков. А сегодня же мы сосредоточимся на принципах, согласно которым RSVP TE строит LSP.

От смены протокола не меняется то, что LSP - однонаправленный, соответственно и ресурсы будут резервироваться только в одном направлении. Хочешь в другом - создавай обратный LSP.

Для начала мы отбросим функционал резервирования ресурсов - пусть наша задача только создать LSP, то есть распределить метки между LSR.

Чтобы это стало возможно, стандартный RSVP расширяется добавлением нескольких объектов. Рассмотрим простейший вариант.
0) R1 нужен LSP до FEC 6.6.6.6/32. Это выглядит как интерфейс Tunnel на R1, у которого адрес назначений 6.6.6.6 и тип Traffic Engineering.
1) Он посылает сообщение RSVP Path в направлении 6.6.6.6. В этом сообщении появляется новый объект - Label Request . Сообщение Path провоцирует узел выделить метку для данного FEC - то есть это запрос метки.
2) Следующий узел формирует новое сообщение Path и также отправляет его в сторону 6.6.6.6. Итд.
3) Path достигает Egress LSR. Тот видит, что пакет-то ему адресован, выделяет метку и отправляет источнику сообщение Resv. В последнем тоже добавлен новый объект - Label . В нём Egress LSR передаёт свою метку для этого FEC предпоследнему, предпоследний предпредпоследнему свою итд.
4) Resv достигает источника, распределяя по пути метки. Таким образом создан LSP, а источник уведомлён, что всё готово.

Метки запрашиваются вниз по течению (сообщение Path от отправителя к получателю), а передаются вверх по течению (сообщение Resv от получателя к отправителю).
При этом обратите ваше внимание на то, что это уже самый что ни на есть Downstream on Demand + Ordered Control. Path выступает запросом метки, а Resv идёт от получателя шаг за шагом и, пока метку не выслал нижестоящий LSR, вышестоящий не может её отправить своим соседям.

Стоп! Мы говорили, что RSVP TE в отличие от LDP позволяет строить как мы хотим, не привязываясь к таблице маршрутизации и IGP, а тут пока просто «в направлении 6.6.6.6».
И вот тут мы подошли вплотную к фундаментальному отличию RSVP TE от LDP. RSVP TE очень тесно связан с протоколами динамической маршрутизации, он не просто опирается на результат их работы - он адаптирует их под себя, эксплуатирует в прямом смысле слова.
Во-первых , годятся только протоколы, основанные на алгоритмах по состоянию связи (link-state), то есть OSPF и ISIS.
Во-вторых , OSPF и ISIS расширяются введением новых элементов в протоколы. Так в OSPF появляется новый тип LSA - Opaque LSA , а в ISIS - новые TLV IS Neighbor и IP Reachability .
В-третьих , для расчёта пути между Ingress LSR и Egress LSR используется специальная модификация алгоритма SPF - CSPF (Constrained Shortest Path First ).

Теперь подробнее.

Сообщение Path в принципе передаётся юникастом адресно. То есть адрес отправителя у него - адрес R1, а получателя - 6.6.6.6. И оно могло бы дойти и просто по таблице маршрутизации.

Но фактически Path передаётся по сети не как FIB на душу положит на каждом узле, ведь мы тогда не сможем ни резервирование обеспечить, ни поиск запасных маршрутов. Нет, он следует определённому пути.
Этот путь определяется на Ingress LSR с точностью до каждого узла.
Чтобы построить этот путь, RSVP TE нужно знать топологию сети. Понимаете да, к чему мы приближаемся? Сам RSVP не утруждает себя её изучением, да и зачем, когда её можно получить у OSPF или ISIS. И тут же становится очевидно, почему сюда не подходят RIP, IGRP и EIGRP - ведь они не изучают топологию, максимум на что они способны - это Feasible Successor.
Но классический алгоритм SPF на входе имеет топологию сети, а на выходе может выдать только наибыстрейший маршрут с учётом метрик и , хотя просчитать может и все возможные пути.
И тут на сцену выходит CSPF. Именно этот алгоритм может посчитать лучший путь, второй по приоритетности путь и, например, ещё какой-нибудь запасной, чтобы хоть как-то добраться, пусть и .
То есть RSVP TE может обращаться к CSPF с просьбой вычислить для него какой-либо путь между двумя узлами.
Ну хорошо, а зачем для этого менять сами протоколы IGP? Вооот. А это уже Constraints - ограничения. RSVP TE может предъявлять требования к пути - ширина полосы пропускания, минимально доступная ширина, тип линии или даже узлы, через которые LSP должен пролегать. Так вот, чтобы CSPF мог учитывать ограничения, он должен знать и о них и о доступных ресурсах на узлах всей сети. Входными данными для него являются ограничения, заданные в туннеле и топология сети - логично будет, если топология будет содержать кроме префиксов и метрик ещё и информацию о доступных ресурсах.
Для этой цели маршрутизаторы обмениваются между собой через сообщения OSPF и ISIS не только базовой информацией, но и характеристиками линий, интерфейсов итд. Как раз в новых типах сообщений и передаётся эта информация.
Например, в OSPF для этого ввели 3 дополнительных типа LSA:

• Type 9 - link-local scope
• Type 10 - area-local scope
• Type 11 - AS scope

Opaque значит непрозрачный (для OSPF). Это специальные типы LSA, которые никак не учитываются в самом OSPF при расчёте таблицы маршрутизации. Их могут использовать любые другие протоколы для своих нужд. Так TE их использует для построения своей топологии (она называется TED - Traffic Egineering Database ). Но теоретически за TE они не закреплены - если вы напишете своё приложение для маршрутизаторов, которое будет требовать обмена какой-то информацией о топологии, вы тоже можете использовать Opaque LSA.
Точно так же работает и ISIS. Новые сообщения: IS-IS TLV 22 (Extended IS Reachability), 134 (Traffic Engineering router ID), 135 (Extended IP reachability).

Итак, взглянем более детализированно на весь этот процесс.

0) На R1 мы включили MPLS TE и настроили ISIS (OSPF) на передачу данных для поддержки TE. Маршрутизаторы обменялись информацией о доступных ресурсах. На этом шаге сформирована TED. RSVP молчит.

1) Мы создали туннельный интерфейс, где указали его тип (Traffic Engineering), адрес назначения (6.6.6.6) и необходимые требования по ресурсам. LSR запускает CSPF: нужно вычислить кратчайший путь от R1 до 6.6.6.6 с учётом накладываемых условий. На этом шаге мы получаем оптимальный путь - список узлов от источника до получателя (R2, R5, R6).

2) Результат предыдущего шага скармливается RSVP и трансформируется в объект ERO . R1 компилирует RSPV Path, куда, естественно, добавляет ERO. Адресат пакета - 6.6.6.6. Кроме того, имеется и объект Label Request, сообщающий о том, что при получении пакета нужно выделить метку для данного FEC (6.6.6.6/32).

ERO - Explicit Route Object - специальный объект сообщения RSVP Path. Он содержит список узлов, через которые суждено пройти этому сообщению.

3) Сообщение RSVP Path передаётся специальным образом - не по таблице маршрутизации, а по списку ERO. В нашем случае лучший маршрут IGP и ERO совпадают, поэтому пакет посылается на R2.

4) R2, получив RSVP Path, проверяет наличие требуемых ресурсов и, если они есть, выделяет метку MPLS для FEC 6.6.6.6/32. Старый пакет Path уничтожается и создаётся новый, причём объект ERO меняется - из него удаляется сам R2. Делается это для того, чтобы следующий узел не пытался вернуть пакет на R2. То есть новый ERO выглядит уже так: (R5, R6). В соответствии с ним R2 отправляет обновлённый Path на R5.

5) R5 совершает аналогичные операции: проверяет ресурсы, выделяет метку, удаляет себя из ERO, пересоздаёт пакет Path и передаёт в интерфейс, через который ему известен следующий объект ERO - R6.

6) R6, получив пакет, понимает, что он виновник всей суматохи. Он уничтожает Path, выделяет метку для FEC 6.6.6.6 и вставляет её как объект Label в ответное сообщение Resv.
Заметьте, до этого шага метки только выделялись, но не распространялись, теперь же они начинают анонсироваться тем LSR, которые их запрашивали.
7) Сообщение RESV продвигается к R1 (Ingress LSR), оставляя за собой растущий хвост LSP. Resv должно пройти через те же узлы, что Path, но в обратном порядке.

8) В конце концов LSP от R1 до 6.6.6.6 сформирован. Данные по нему могут передаваться только от R1 к R6. Чтобы позволить передачу данных в обратном направлении, нужно создать туннельный интерфейс на R6 с адресом назначения 1.1.1.1 - все действия будут точно такими же.

Возникает вопрос - почему адресат пакета Path 6.6.6.6, если передаётся он узел за узлом и их адреса известны? Вопрос этот не праздный - он ведёт нас к одной важной особенности. Объект ERO может на самом деле содержать не все узлы от Ingress LSR до Egress LSR - некоторые могут быть опущены. Поэтому каждый LSR должен знать, куда в итоге направляется сообщение. И происходить это может не потому что Ingress LSR лень просчитать весь путь.
Проблема в зонах IGP. Вы знаете, что и в OSPF и в ISIS существует это понятие для того, чтобы упростить маршрутизацию. В больших сетях (сотни и тысячи узлов) встаёт проблема широковещательных рассылок служебных пакетов и просчёт огромного количества комбинация алгоритмом SPF. Поэтому один глобальный домен делится на зоны маршрутизации.
И вся загвоздка в том, что если внутри зоны IGP и является протоколом по состоянию связи (link-state), то между ними - он самый настоящий дистанционно-векторный - топология сети строится только внутри зоны, любые внутренние маршрутизаторы не знают, как устроены другие зоны - они только поставлены в известность, что для того, чтобы попасть в ту или иную сеть, им нужно отправлять пакеты на конкретный .
Иными словами, если у вас сеть поделена на зоны, то с MPLS TE возникают затруднения - CSPF не может просчитать весь путь, потому что в его топологии адресат из другой зоны - это облако, а не конкретный узел.

И тут на помощь приходит Explicit Path (не путать с объектом ERO). Это самый, что ни на есть, прямой способ управления путём построения LSP - администратор может самостоятельно и явно задать те узлы, через которые нужно проложить LSP. Ingress LSR должен точно следовать таким указаниям. Это вносит в жизнь алгоритма CSPF ещё немного разнообразия.
Как Explicit Path помогает пробить зону? Давайте на примере.

Мы возьмём и укажем, что обязательно должны быть промежуточные точки:
Explicit-path: R1, R3, R5.

Когда этот Explicit Path мы скармливаем CSPF, он строит тот кусок, который может, то есть в пределах Area 0: от R1 до R3.
То, что он насчитал, заносится в ERO, плюс в него добавляются и ещё один узел из Explicit-path - R5. Получается: R1, R2, R3. Path отправляется по сети согласно ERO, доходит до R3. Тот видит, что он в общем-то не адресат, а только перевалочный пункт, берёт заданные условия по требуемым ресурсам и адрес узла-получателя из Explicit-path и запускает CSPF. Последний выдаёт полный список узлов до адресата (R3, R4, R5), который преобразуется в ERO, и дальше всё происходит по стандартному сценарию.
То есть в случае нахождения Ingress LSR и Egress LSR в разных зонах вычисление пути выполняется отдельно для каждой зоны, а контрольной точкой является ABR.

Следует понимать, что Explicit Path используется не только для этого случая, но это вообще удобный инструмент, ведь вы можете явно указать, как нужно проложить LSP или наоборот, через какие узлы не надо прокладывать LSP.
Этого и много другого мы коснёмся детально в выпуске, посвящённом MPLS TE.

Меня могут упрекнуть в лукавстве, сказав, что не настолько уж и обязателен Link-State IGP. Ну вот хочется на моноцисочной сети запустить EIGRP, сил нет. Или вообще некрофильные позывы заставляют откопать RIP. И что теперь? Отказаться от TE?
В общем есть спасение, но только на оборудовании Cisco - называется оно Verbatim .

Ведь для чего нам нужен Link-State протокол? Он собирает информацию о топологии TE, а CSPF строит путь от Ingress LSR до Egress LSR. Таак. Отлично. А что если мы возьмём и состряпаем Explicit Path, где перечислим все узлы один за другим? Ведь тогда не надо ничего считать.
На самом деле, как бы подробно вы ни составили явный путь, он всё равно будет передан CSPF.
Но такое поведение можно отключить. Как раз для случаев, описанных выше.
Поможет такая команда:
Router(config-if)# tunnel mpls traffic-eng path-option 1 explicit name test verbatim

То ест данный путь будет взят как заведомо верный безо всяких проверок и пересчётов CSPF.
Такой сценарий стоит под большим вопросом, а его плюсы весьма призрачны. Однако возможность есть, и не говорите потом, что я вам про неё не рассказал.

Практика RSVP TE

Команда mpls ip была нам нужна для работы LDP. Теперь в ней больше нет нужды - удаляем её и начинаем с чистого листа .
Теперь нам понадобится mpls traffic-eng tunnels . Она глобально включает поддержку TE-туннелей и собственно RSVP TE:
R1(config)#mpls traffic-eng tunnels
Также необходимо включить то же самое на интерфейсах:

R1(config)# interface FastEthernet 0/0
R1(config-if)# mpls traffic-eng tunnels
R1(config)# interface FastEthernet 0/1
R1(config-if)# mpls traffic-eng tunnels
Пока ничего не происходит. RSVP молчит.

Сейчас мы расширим IGP на передачу данных TE. В своём примере мы используем ISIS:
R1(config)#router isis
R1(config-router)# metric-style wide

R1(config-router)# mpls traffic-eng level-2

Включить режим расширенных меток - обязательно, иначе TE не заработает.
Задать LSR-ID, как мы это делали и в LDP,
Необходимо задать конкретный уровень ISIS, иначе, TE не заработает.

Если вдруг вы используете OSPF

R1(config-router)# mpls traffic-eng area 0
R1(config-router)# mpls traffic-eng router-id Loopback0

Эти шаги нужно повторить на других маршрутизаторах.

Сразу после этого ISIS начинает обмениваться информацией о TE:

Как видите передаётся информация о LSR-ID, расширенная информация о соседях (которые поддерживают TE), расширенная информация о интерфейсах.

На этом этапе сформирована TED.

Саму топологию вы можете посмотреть в ISIS: #show isis database verbose

RSVP пока молчит.

Теперь настроим TE-туннель.
R1(config)# interface Tunnel1
R1(config-if)# ip unnumbered Loopback0
R1(config-if)# tunnel destination 6.6.6.6
R1(config-if)# tunnel mode mpls traffic-eng
R1(config-if)# tunnel mpls traffic-eng path-option 10 dynamic
Туннельные интерфейсы - вещь очень универсальная на маршрутизаторах. Они могут использоваться для L2TP, GRE, IPIP и, как видите, для MPLS TE.
ip unnumbered Loopback0 означает, что отправной точкой туннеля должен быть адрес интерфейса Loopback0.
tunnel destination 6.6.6.6 - универсальная для туннельных интерфейсов команда, определяет точку терминации, окончания туннеля.
tunnel mode mpls traffic-eng - задаёт тип. Именно здесь и определяется алгоритм работы туннеля, как его строить.
tunnel mpls traffic-eng path-option 10 dynamic - эта команда позволяет CSPF построить путь динамически, без задания промежуточных узлов.

Если до этого вы всё сделали правильно, то туннельный интерфейс должен подняться:
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

Что при этом произошло?
R1 отправил Path.

Дамп снят на линии R1-R2.

Нас в нём интересуют адрес назначения, объекты ERO и Label Request.
Адрес назначения - 6.6.6.6, как и настроили в туннеле.
Explicit Route:
10.0.12.2 -> 10.0.25.2 -> 10.0.25.5 -> 10.0.56.5 -> 10.0.56.6.
То есть в нём прописан линковый адрес выходного интерфейса и линковый же адрес следующего узла. Каждый LSR таким образом точно знает, в какой интерфейс нужно отправить Path.
В данном ERO нет 10.0.12.1, потому что R1 уже удалил его перед отправкой.
Факт наличия Label Request говорит о том, что LSR должен выделить метку для данного FEC.
При этом он никак не отвечает на этот Path пока - он посылает обновлённый дальше.
Resv ниже посылается после того, как пришёл Resv от нижестоящего LSR.

То же самое происходит на R5:

Дамп снят на линии R2-R5.

Дамп снят на линии R2-R5.

Так Path доходит до R6. Тот отправляет назад RSPV Resv:

Дамп снят на линии R5-R6.

На дампе хорошо видно, что Resv передаётся от узла к узлу.
В объекте Label передаётся метка, выделенная данному FEC.

Обратите внимание, что R6 присвоил метку 0 - Expliсit Null. Вообще это нормальная ситуация - делается это для того, чтобы метка MPLS между R5 и R6 была (для обработки пакета согласно значению в поле EXP, например), но R6 сразу же понял, что метку 0 надо сбрасывать и обрабатывать то, что под ней, а не производил поиск в таблице меток.
Проблема в том, что в пакете меток может быть больше одной (например, для VPN), но согласно RFC 3032 (да и мы раньше об этом говорили) R5 должен удалить весь стек меток, сколько бы их ни было, и передать пакет с одной меткой 0. При этом, конечно, всё сломается.
На самом деле, требование того, чтобы метка 0 была единственной в стеке, выглядит неоправданным - применений этому нет. Поэтому в RFC 4182 это ограничение убрали. Теперь метка 0 может быть не единственной в стеке.
Интересная особенность - PHP. Несмотря на то, что для этого есть специальная метка - 3 - LSR совершит PHP даже при получении метки 0. Подробнее у того же Пепельняка .

R5 передаёт Resv на R2, а R2 на R1.


Дамп снят на линии R1-R2.

Тут, как видите, уже метка нормальная - 16.

Как бы внимательно вы ни приглядывались к Resv, вы не увидите там пути, по которому нужно пройти, а список узлов должен быть тем же самым, чтобы успешно раздать метки и построить LSP. Как это решается?

ВиО

В1: Чем отличаются RSVP TE LSP и LDP LSP?

Строго говоря, с точки зрения как вышестоящиех протоколов, так и самого MPLS таких понятий нет вообще. LSP - он и есть LSP - это просто путь коммутации меток.
Можно выделить термин CR-LSP (ConstRaint-based LSP) - он строится RSVP TE. В этом плане разница в том, что CR-LSP удовлетворяет условиям заданным в туннельном интерфейсе.

В2: Как соотносятся Explicit Path и ERO?

Если для туннеля задан Explicit Path, то RSVP формирует ERO, учитывая требования Explicit Path. При этом даже если вы в Explicit-Path пропишите каждый узел до Egress LSR, RSVP всё равно загонит данные в CSPF.

В3: Если один из промежуточных узлов не будет поддерживать LDP (RSVP TE) или протокол будет выключен на интерфейсе/платформе, будет ли построен LSP так, например, чтобы на этом узле он переходил в IP, а потом на следующем снова в MPLS?

В случае RSVP TE Ingress LSR не будет иметь данного узла в TED и не сможет выстроить путь до Egress LSR, соответственно не пошлёт Path, соответственно, не будет и меток и LSP.
Трафик через туннель передаваться не сможет.

Если же речь о LDP, то ситуация интереснее. Например, если на R2 выключить LDP на интерфейсе FE0/0 (в сторону R5), то
1) на R1 будет метка для FEC 6.6.6.6/32. Причём их будет 2: одна через R2, другая - через R3, поскольку согласно таблице маршрутизации лучший - через R2, то и LSP будет лежать в сторону R2.
2) на R2 метка будет, но только одна - в сторону 1.1.1.1. Это не лучший путь, поэтому он не будет использован. То есть здесь LSP от R1 к FEC 6.6.6.6/32 прекращает своё существование.
3) на R5 метка для FEC 6.6.6.6/32 будет

То есть, вроде бы, мы получаем разорванный LSP: {R1-R2, R5-R6}. Но на самом деле, это не так. LSP на то и Label Switched, чтобы на протяжении всего пути на нём менялись метки, а у нас получается от R1 до R2 MPLS, от R2 до R5 IP, а от R5 до R6 опять MPLS. LSP для FEC 6.6.6.6/32 здесь нет . Обычный трафик тут пройдёт, в принципе, но если говорить о каких-то применениях MPLS, таких, например, как VPN, то это работать не будет.

В4: Хорошо, зачем нужен MPLS будет понятно из следующих статей - пока это вообще какая-то искусственная ерунда, чтобы усложнить жизнь инженера, но зачем мне MPLS TE-то? Ведь трафик можно направить нужным мне путём с помощью метрик IGP.

Начнём с того, что это тема будущих выпусков. Но…
Вообще говоря, если вы хотите определять путь, по которому пойдёт трафик, то это действительно можно сделать путём хитрой настройки стоимости линков, интерфейсов итд. Но обслуживание такой системы доставит вам те ещё хлопоты с одной стороны, а с другой у вас всё равно не получится направить два разных потока разными путями. То есть если стоит задача разгрузить сеть путём распределения трафика, то с помощью метрик вы просто перенесёте проблему с одного плеча на другое.
А вот если у вас будет несколько разных LSP и вы сможете направить в них трафик, то это пожалуйста. Хотя в плане простоты поддержки TE тоже вызывает вопросы.

Ну и вообще подумайте, если вам нужны для двух клиентов гарантированные каналы 40 Мб/с и 50 Мб/с соответственно, как вы будете отслеживать утилизацию линий? Ну хорошо, один раз вы вычислили и настроили каким-то чудесным образом маршрутизацию и QoS так, чтобы обеспечить нужный уровень услуги, но вдруг у вас срезают в трёх местах 3 километра оптики разом и вы неделю не можете починить. И у вас даже есть три резервных канала по 50Мб/с, но трафик обоих клиентов попёр в одно место, наплевав на все ваши формальные .

В5: Так чем всё-таки отличаются метки Explicit Null и Implicit Null? Нужно ли мне о них действительно знать?

Нужно. Первоначально предполагается, что по сети MPLS пакет всегда коммутируется по меткам от первого до последнего LSR. А на последнем пролёте метка будет «0», чтоб Egress LSR сразу знал, что её нужно снять. Эта метка позволяет не потерять приоритет, заданный в поле TC заголовка MPLS, который копируется по мере передачи пакета по сети. В итоге даже последний маршрутизатор обработает данные в правильных очередях.

В концепции с использованием метки «3» решили отказаться от лишних действий на Egress LSR. Если вас не волнует QoS (или вы скопировали приоритет, например, в поле DSCP), то острой нужды в транспортной метке на последнем пролёте нет - главное отправить в правильный интерфейс, а там Egress LSR разберётся. Если там был чистый IP-пакет - отдать его процессу IP, если был какой-нибудь E1, передать поток в нужный интерфейс, если стек меток, то сделать lookup в LFIB и посмотреть, какие дальнейшие действия нужно предпринять.

В6: Для одного FEC LSR всегда будет выделять одну и ту же метку всем своим соседям?

Существует понятие пространства меток:

• пространство меток интерфейса
• пространство меток слота


• пространство меток платформы

Если метки специфичны для каждого интерфейса, тогда для одного FEC в разные порты могут быть отправлены разные метки.
И наоборот - если метки специфичны для платформы (читай всего LSR), то маршрутизатор во все порты для одного FEC обязан отправить одинаковые метки.
В примерах ниже вы увидите, что у нас для одного FEC отправляются одинаковые метки разным соседям, но это ещё не говорит о том, как организовано пространство меток. Это вещь сугубо индивидуальная и завязана на аппаратном обеспечении.

Важно понимать, что технология MPLS никак не регламентирует протокол распространения меток, но конечные результаты на конкретной сети вполне могут различаться при использовании разных протоколов. Вышестоящие протоколы и приложения используют LSP безотносительно того, кем и как они построены.
Кстати нередко в современных сетях встречается сценарий LDP over TE. В этом случае RSVP-TE используется для организации транспорта и реализации Traffic Engineering, а LDP для обмена метками VPN, например.
Ingress LSR, записывая в заголовок MPLS первую метку, определяет весь путь пакета. Промежуточные маршрутизаторы просто меняют одну метку на другую. Содержимое может быть совершенно любым. Как раз вот эта мультипротокольность позволяет MPLS служить основой для разнообразных сервисов VPN.

Введение

В данном документе содержатся ответы на наиболее часто задаваемые вопросы, касающиеся многопротокольной коммутации по меткам (MPLS) для специалистов начального уровня подготовки.

Вопрос. Что такое многопротокольная коммутация по меткам (MPLS)?

Ответ. Многопротокольная коммутация по меткам (MPLS) - это технология переадресации пакетов, которая использует метки для принятия решений о перенаправлении данных. С помощью MPLS проводится однократный анализ заголовка третьего уровня (при поступлении пакета в домен MPLS). Анализ метки приводит к дальнейшей переадресации пакета. MPLS предлагает следующие удобные приложения:

• Virtual Private Networking (VPN)
• Traffic Engineering (TE)
• Quality of Service (QoS)
• Any Transport over MPLS (AToM)

Кроме того, эта технология уменьшает время перенаправления пакета на основных маршрутизаторах. Технологии MPLS применимы к любым протоколам сетевого уровня.

Вопрос. Что такое метка? Какова структура метки?

Ответ. Метка имеет небольшой размер, равный четырем байтам, фиксированную длину и устанавливается локально, что используется для идентификации класса эквивалентной переадресации (FEC). Метка, присвоенная определенному пакету, содержит данные о FEC, которому назначен этот пакет.

• Label - значение метки (неструктурированно), 20 бит
• Exp - экспериментальное использование, 3 бита; в текущий момент используется в качестве поля Class of Service (CoS).
• S - нижняя граница стека, 1 бит
• TTL - время жизни, 8 бит

Вопрос. В какой части пакета устанавливается метка?

Ответ. Метка устанавливается между заголовком уровня канала данных (второй уровень) и заголовком сетевого уровня (третий уровень). Верхняя граница стека меток отображается первой в пакете, а нижняя - последней. Пакет сетевого уровня непосредственно следует последней метке из стека меток.

Вопрос. Что такое класс эквивалентной переадресации (FEC)?

Ответ. Класс эквивалентной переадресации FEC является группой IP-пакетов, которые переадресуются одинаковым образом по одному и тому же маршруту и с одной и той же обработкой переадресации. FEC может соответствовать адресу IP-подсети назначения, кроме того, FEC может соответствовать любому классу трафика, который Edge-LSR рассматривает в качестве важного. Например, весь трафик с определенным значением IP-приоритета может служить основой для FEC.

Вопрос. Что такое восходящий маршрутизатор коммутирующий по меткам (LSR)? Что такое нисходящий маршрутизатор коммутирующий по меткам?

Ответ. Восходящий и нисходящий являются относительными понятиями для MPLS. Они всегда обращаются к префиксу (правильнее говорить о FEC). Это объясняется в следующем примере.

Для FEC 10.1.1.0/24, R1 является "нисходящим" маршрутизатором коммутирующим по меткам в R2.

Для FEC 10.1.1.0/24, R2 является "восходящим" маршрутизатором коммутирующим по меткам в R1?

Для FEC 10.1.1.0/24, R1 является "нисходящим" маршрутизатором коммутирующим по меткам в R2. А R2 является "нисходящим" маршрутизатором коммутирующим по меткам в R3.

Для FEC 10.1.1.0/24, R1 является "нисходящим" маршрутизатором коммутирующим по меткам в R2. Для FEC 10.2.2.0/24, R2 является "нисходящим" маршрутизатором коммутирующим по меткам в R1.

Для достижения этой сети данные передаются от восходящего к нисходящему маршрутизатору.

В таблице маршрутизации R4 содержатся данные о R1 и R2, как о следующих сетевых сегментах для достижения 10.1.1.0/24.

Вопрос. Является ли R3 "нисходящим" маршрутизатором коммутирующим по меткам в R4 для 10.1.1.0/24?

Ответ. Нет. Данные передаются от восходящего к нисходящему маршрутизатору.

Вопрос. Что означают термины "входящий", "исходящий", "локальный" и "удаленный" применительно к меткам?

Ответ. В данной топологии рассмотрим маршрутизаторы R2 и R3. R2 распределяет метку L для FEC F в R3. R3 использует метку L при перенаправлении данных к FEC-F (так как R2 является его нисходящим маршрутизатором коммутирующим по меткам для FEC-F). В данном примере:

• L является входящей меткой для F на R2.
• L является исходящей меткой для FEC-F на R3.
• L является локальным значением для FEC-F на R2.
• L является удаленной меткой для FEC-F на R3.

Вопрос. Может ли маршрутизатор коммутирующий по меткам использоваться для отправки и (или) получения на MPLS-интерфейс собственного IP-пакета (не MPLS)?

Ответ. Да, если на интерфейсе может использоваться IP-протокол. Собственные пакеты передаются и принимаются как обычно. IP - это всего лишь другой протокол. Пакеты MPLS имеют другую кодировку второго уровня. Принимающий маршрутизатор коммутирующий по меткам распознает пакет MPLS, основанный на кодировке второго уровня.

Вопрос. Может ли маршрутизатор коммутирующий по меткам использоваться для отправки и (или) получения помеченных пакетов на интерфейс отличный от MPLS?

Ответ. Нет. Пакеты никогда не передаются на интерфейс, который не допускает использование этого протокола. MPLS обладает определенным типом кодировки Ether, связанным с многопротокольной коммутацией по меткам (точно так же, как IP, IPX и Appletalk обладают уникальными типами Ether). При получении маршрутизатором Cisco пакета с типом Ether, которые не может использоваться на интерфейсе, происходит отклонение такого пакета. Например, если маршрутизатор получает пакет Appletalk на интерфейсе, который не может обрабатывать пакеты Appletalk, то происходит отклонение пакета. Аналогично этому, если пакет MPLS получен на интерфейсе, который не может его обработать, то этот пакет отклоняется.

Вопрос. Какие платформы и операционные системы Cisco IOS поддерживают работу с многопротокольной коммутацией по меткам (MPLS)?

Ответ. Многопротокольную коммутацию по меткам могут использовать Cisco Series 2691, 3640, 3660, 3725, 3745, 6400-NRP-1, 6400-NRP-2SV, 6400-NSP, Catalyst 5000 с модулем маршрутизации коммутатора (RSM), 7200, 7301, 7400, 7500, Catalyst 6500/Cisco 7600 Series с WS-SUP720-3B и WS-SUP720-3BXL, Gigabit Switch Router (GSR), Route Processor Module (RPM), Universal Broadband Router (UBR) 7200, AS5350 и IGX8400-URM.

Эти платформы поддерживают Cisco TDP-протокол в качестве протокола распределения меток.

Сведения о LDP-протоколе, RSVP-протоколе и BGP-протоколе могут быть найдены с помощью служебной программы (только для пользователей ). Software Advisor предоставляет сведения о полном списке наборов функций, поддерживаемых в различных версиях Cisco IOS и на различных платформах.

Вопрос. GRE-туннель использует служебные данные размером 24 байта. Какой размер служебных данных соответствует туннелю MPLS LSP?

Ответ. Туннель MPLS LSP имеет одну метку (четыре байта) или две метки (например, при использовании переадресации быстрого защищенного канала) в области служебных данных. В отличии от туннеля GRE, туннель MPLS не может изменять заголовки IP-пакетов. Вместо этого, стек меток применяется к пакету проходящему по пути туннеля.

Вопрос. Как маршрутизатор коммутирующий по меткам определяет какая метка из стека меток считается верхней, нижней или средней?

Ответ. Метка, расположенная сразу после заголовка второго уровня, является верхней меткой, а метка с битом S = 1 является нижней меткой. Средние метки не считываются и не идентифицируются маршрутизатором коммутирующим по меткам. При этом метка будет средней меткой, если она не находится вверху стека и бит S = 0.

Вопрос. Каков диапазон значений метки? Какие значения метки могут быть получены? Что означают полученные значения?

Ответ. Эти значения также могут быть найдены в документе RFC3032 - MPLS Label Stack Encoding (RFC3032 - кодировка меток стека MPLS) .

Теоретически диапазон значений от 0 до (2 20 -1). Значения меток 0-15 зарезервированы, а значения 4-15 зарезервированы для последующего использования. Значения 0-3 определяются следующим образом:

• Значение 0 соответствует "IPv4 Explicit NULL Label". Эта метка указывает на то, что пакет должен быть извлечен из стека меток, а переадресация пакета должна быть основана на основе IP-заголовка версии 4. Это помогает сохранить бит Exp неизменным до выхода из маршрутизатора. Он используется в QoS на основе MPLS.
• Значение 1 соответствует "Router Alert Label". Если полученный пакет содержит это значение метки вверху стека меток, то пакет доставляется модулю локального программного обеспечения для обработки. Фактическая переадресация пакета определяется его меткой в стеке. Однако если пакет переадресуется далее, то метка Router Alert Label должна быть возвращена обратно в стек меток перед выполнением переадресации. Использование этой метки аналогично использованию метки "Router Alert Option" в IP-пакетах (например, проверка связи с параметром записи маршрутизатора)
• Значение 2 соответствует "IPv6 Explicit NULL Label". Эта метка указывает на то, что пакет должен быть извлечен из стека меток, а переадресация пакета должна быть основана на основе IP-заголовка версии 6.
• Значение 3 соответствует "Implicit NULL Label". Это метка, которую маршрутизатор коммутирующий по меткам может назначать и распределять. Однако она никогда не отображается в инкапсуляции. Это указывает на то, что маршрутизатор коммутирующий по меткам выталкивает верхнюю метку из стека и направляет оставшуюся часть пакета (с меткой или без) через исходящий интерфейс (для каждой записи Lfib). Хотя это значение может никогда не отображаться в инкапсуляции, необходимо задать LDP-протокол так, чтобы зарезервировать значение.

Вопрос. Какой протокол и номер порта позволяют использовать протоколы LDP и TDP для распределения меток в узлах LDP/TDP?

Ответ. LDP-протокол использует TCP-порт 646, а TDP-протокол использует TCP-протокол 711. Эти порты открыты на интерфейсе маршрутизатора только когда mpls ip настраивается на этот интерфейс. Использование TCP в качестве транспортного протокола приводит к надежной доставке данных LDP/TDP с помощью надежных механизмов управления потоком и обработки перегрузок.

Вопрос. Какие ограничения на использование MPLS существуют для маршрутизаторов Catalyst 6500 и 7600 Optical Services (OSR)?

Ответ. Интерфейс, связанный с доменом MPLS, должен использовать один из оптических служебных модулей (OSM) (например, любой модуль, который использует комплекс Parallel Express Forwarding (PXF)) или интерфейс в модуле FlexWAN. Те же самые ограничения существуют и для многопротокольной коммутации по меткам третьего уровня VPN. Именно поэтому IP-кадр должен поступать на WAN-интерфейс, который может быть либо оптическим служебным модулем, либо интерфейсом в модуле FlexWAN. Эти ограничения не распространяются на Supervisor 720.

VPN (Virtual Private Network) - это виртуальная частная сеть или логическая сеть, которая создается поверх незащищённых сетей (сетей оператора связи или сервис-провайдера Интернет). VPN – это технология, которая обеспечивает защиту данных при передаче их по незащищенным сетям. Виртуальная частная сеть позволяет организовать туннель в незащищённых сетях (между двумя точками сети), например в ATM, FR или IP-сетях.

С помощью VPN можно осуществить соединения: сеть-сеть, узел-сеть или узел-узел. Такие свойства технологии VPN предоставляют возможность объединить территориально удаленные друг от друга локальные сети офисов компании в единую корпоративную информационную сеть. Необходимо отметить, что корпоративные вычислительные сети (КВС) можно организовывать и на базе выделенных (частных или арендованных) каналов связи. Такие средства организации используются для небольших КВС (предприятий с компактно расположенными офисами) с неизменяющимся во времени трафиком.

Известны основные виды VPN и их комбинации:

• Intranet VPN (внутрикорпоративные VPN);
• Extranet VPN (межкорпоративные VPN);
• Remote Access VPN (VPN с удаленным доступом);
• Client/Server VPN (VPN между двумя узлами корпоративной сети).

В настоящее время для построения корпоративных территориально распределенных сетей в разделяемой инфраструктуре сервис-провайдеров и операторов связи применяются следующие технологий:

• IP-туннели с использованием технологий GRE или IPSec VPN;
• SSL, к которой относятся OpenVPN и SSL VPN (SSL/TLS VPN) для организации безопасных каналов связи;
• MPLS в сети оператора (L3 VPN) или VPN в сети BGP/MPLS;
• Metro Ethernet VPN в сети оператора (L2 VPN). Наиболее перспективная технология, используемая в Metro Ethernet VPN, - это VPN на базе MPLS (MPLS L2 VPN) или VPLS.

Что касается применения выделенных линий и технологий Frame Relay, ATM для организации корпоративных территориально распределенных сетей, то они уже для этих целей практически не применяются. Сегодня, как правило, КВС строятся на основе оверлейных сетей (клиент-серверных и одноранговых сетей), которые работают в разделяемой инфраструктуре операторов, и являются «надстройками» над классическими сетевыми протоколами.

Для организации территориально распределенных корпоративных сетей провайдеры предоставляют заказчикам следующие основные модели VPN в среде Интернет:

• модель IP VPN (GRE, IPSec VPN, OpenVPN) через WAN сеть, в которой настройка VPN обеспечивается заказчиком;
• модель L 3 VPN или MPLS L3 VPN через WAN сеть, в которой настройка VPN обеспечивается сервис-провайдером или оператором связи;
• модель L2 VPN через MAN сеть, в которой настройка VPN обеспечивается провайдером или оператором связи:
  • point-to-point (AToM, 802.1Q, L2TPv3);
  • multipoint (VPLS и H-VPLS).

Технологии VPN можно классифицировать и по способам их реализации с помощью протоколов: аутентификации, туннелирования и шифрования IP-пакетов. Например, VPN (IPSec, OpenVPN, PPTP) основаны на шифровании данных заказчиков, VPN (L2TP и MPLS) базируются на разделении потоков данных между заказчиками VPN, а SSL VPN основана на криптографии и аутентификации трафика. Но, как правило, VPN используют смешанные варианты, когда совместно используются технологии: аутентификации, туннелирования и шифрования. В основном организация VPN-сетей осуществляется на основе протоколов канального и сетевого уровней модели OSI.

Необходимо отметить, что для мобильных удаленных пользователей была разработана технология SSL VPN (Secure Socket Layer - уровень защищенных сокетов), которая основана на ином принципе передачи частных данных (данных пользователей) через Интернет. Для организации SSL VPN используется протокол прикладного уровня HTTPS. Для HTTPS используется порт 443, по которому устанавливается соединение с использованием TLS (Transport Layer Security - безопасность транспортного уровня).

TLS и SSL (TLS и SSL- протоколы 6 уровня модели OSI) - это криптографические протоколы, которые обеспечивают надежную защиту данных прикладного уровня, так как используют асимметричную криптографию, симметричное шифрование и коды аутентичности сообщений. Но поскольку в стеке TCP/IP определены 4 уровня, т.е. отсутствуют сеансовый и представительский уровни, то эти протоколы работают над транспортным уровнем в стеке TCP/IP, обеспечивая безопасность передачи данных между узлами сети Интернет.

Модель IP VPN, в которой настройка VPN обеспечивается заказчиком

Модель IP VPN может быть реализована на базе стандарта IPSec или других протоколов VPN (PPTP, L2TP, OpenVPN). В этой модели взаимодействие между маршрутизаторами заказчика устанавливается через WAN сеть сервис-провайдера. В этом случае провайдер не участвует в настройке VPN, а только предоставляет свои незащищённые сети для передачи трафика заказчика. Сети провайдеров предназначены только для инкапсулированного или наложенного (прозрачного) соединения VPN между офисами заказчика.

Настройка VPN осуществляется телекоммуникационными средствами заказчика, т.е. заказчик сам управляет маршрутизацией трафика. VPN соединение – это соединение поверх незащищённой сети типа точка-точка: «VPN шлюз - VPN шлюз» для объединения удаленных локальных сетей офисов, «VPN пользователь - VPN шлюз» для подключения удаленных сотрудников к центральному офису.

Для организации VPN-сети в каждый офис компании устанавливается маршрутизатор, который обеспечивает взаимодействие сети офиса с VPN-сетью. На маршрутизаторы устанавливается программное обеспечение для построения защищённых VPN, например, бесплатный популярный пакет OpenVPN (в этом случае пакет OpenVPN надо сконфигурировать для работы в режиме маршрутизации). Технология OpenVPN основана на SSL стандарте для осуществления безопасных коммуникаций через Интернет.

OpenVPN обеспечивает безопасные соединения на основе 2-го и 3-го уровней OSI. Если OpenVPN сконфигурировать для работы в режиме моста - он обеспечивает безопасные соединения на основе 2 уровня OSI, если в режиме маршрутизации - на основе 3-го уровня. OpenVPN в отличие от SSL VPN не поддерживает доступ к VPN-сети через web-браузер. Для OpenVPN требуется дополнительное приложение (VPN-клиент).

Маршрутизатор головного офиса компании настраивается в качестве VPN-сервера, а маршрутизаторы удаленных офисов в качестве VPN-клиентов. Маршрутизаторы VPN-сервер и VPN-клиенты подключаются к Интернету через сети провайдера. Кроме того, к главному офису можно подключить ПК удаленного пользователя, настроив на ПК программу VPN-клиента. В итоге получаем модель IP VPN (скриншот представлен на рис. 1).

Рис. 1. Модель сети IP VPN (Intranet VPN + Remote Access VPN)

Модель MPLS L3 VPN или L3 VPN, в которой настройка VPN обеспечивается сервис-провайдером или оператором связи (поставщиком услуг)

Рассмотрим процесс организации VPN-сети для трех удаленных локальных сетей офисов заказчика услуг (например, корпорации SC-3), размещенных в различных городах, с помощью магистральной сети MPLS VPN поставщика услуг, построенной на базе технологии MPLS L3 VPN. Кроме того, к сети корпорации SC-3 подключен ПК удаленного рабочего места и ноутбук мобильного пользователя. В модели MPLS L3 VPN оборудование провайдера участвует в маршрутизации клиентского трафика через сеть WAN.

В этом случае доставка клиентского трафика от локальных сетей офисов заказчика услуг к магистральной сети MPLS VPN поставщика услуг осуществляется с помощью технологии IP. Для организации VPN-сети в каждый офис компании устанавливается периферийный или пограничный CE-маршрутизатор (Customer Edge router), который соединяется физическим каналом с одним из пограничных РЕ-маршрутизаторов (Provider Edge router) сети MPLS провайдера (оператора). При этом на физическом канале, соединяющем CE и PE маршрутизаторы, может работать один из протоколов канального уровня (PPP, Ethernet, FDDI, FR, ATM и т.д.).

Сеть поставщика услуг (сервис-провайдера или оператора связи) состоит из периферийных РЕ-маршрутизаторов и опорной сети (ядра сети) с коммутирующими по меткам магистральными маршрутизаторами P (Provider router). Таким образом, MPLS L3 VPN состоит из офисных локальных IP-сетей заказчика и магистральной сети MPLS провайдера (домена MPLS), которая объединяет распределенные локальные сети офисов заказчика в единую сеть.

Удаленные локальные сети офисов заказчика обмениваются IP-пакетами через сеть провайдера MPLS, в которой образуются туннели MPLS для передачи клиентского трафика по опорной сети поставщика. Скриншот модели сети MPLS L3 VPN (Intranet VPN + Remote Access VPN) представлен на рис. 2. С целью упрощения схемы сети приняты следующие начальные условия: все ЛВС офисов относятся к одной VPN, а опорная (магистральная) сеть является доменом MPLS (MPLS domain), находящаяся под единым управлением национального сервис-провайдера (оператора связи).

Необходимо отметить, что MPLS L3 VPN может быть организована с помощью нескольких доменов MPLS разных сервис-провайдеров. На рисунке 2 представлена полносвязная топология VPN.

Рис. 2. Модель сети MPLS L3 VPN (Intranet VPN + Remote Access VPN)

Функционирование PE-маршрутизаторов

Периферийные маршрутизаторы CE и PE (заказчика и провайдера) обмениваются друг с другом маршрутной информацией одним из внутренних протоколов маршрутизации IGP (RIP, OSPF или IS-IS). В результате обмена маршрутной информацией каждый РЕ-маршрутизатор создает свою отдельную (внешнюю) таблицу маршрутизации VRF (VPN Routing and Forwarding) для локальной сети офиса заказчика, подключенной к нему через CE-маршрутизатор. Таким образом, маршрутная информация, полученная от CE, фиксируется в VRF-таблице PE.

Таблица VRF называется виртуальной таблицей маршрутизации и продвижения. Только РЕ-маршрутизаторы знают о том, что в сети MPLS организована VPN для заказчика. Из модели сети MPLS L3 VPN следует, что между CE-маршрутизаторами заказчика не осуществляется обмен маршрутной информацией, поэтому заказчик не участвует в маршрутизации трафика через магистраль MPLS, настройку VPN (РЕ-маршрутизаторов и Р-маршрутизаторов) осуществляет провайдер (оператор).

К РЕ-маршрутизатору могут быть подключены несколько VPN-сетей разных заказчиков (рис.3). В этом случае на каждый интерфейс (int1, int2 и т.д.) PE-маршрутизатора, к которому подключена локальная сеть офиса заказчика, устанавливается отдельный протокол маршрутизации. Для каждого интерфейса РЕ-маршрутизатора один из протоколов IGP создает таблицу маршрутизации VRF, а каждая таблица маршрутизации VRF соответствует VPN-маршрутам для каждого заказчика.

Например, для заказчика SC-3 и его сети LAN0 (главного офиса), подключенной через CE0 к PE0, на PE0 будет сформирована таблица VRF1 SC-3, для LAN1 заказчика SC-3 на PE1 будет создана VRF2 SC-3, для LAN2 на PE2 - VRF3 SC-3 и т.д., а принадлежат они одной VPN SC3. Таблица VRF1 SC-3 является общей для маршрутной информации CE0 и CE4. Необходимо отметить, что таблицы VRF пополняются информацией об адресах локальных сетей всех других офисов данного заказчика с помощью протокола MP-BGP (multiprotocol BGP). Протокол MP-BGP используется для обмена маршрутами непосредственно между РЕ-маршрутизаторами и может переносить в маршрутной информации адреса VPN-IPv4.

Адреса VPN-IPv4 состоят из исходных адресов IPv4 и префикса RD (Route Distinguisher) или различителя маршрутов, который идентифицирует конкретную VPN. В итоге на маршрутизаторах РЕ будут созданы VRF-таблицы с идентичными маршрутами для одной сети VPN. Только те РЕ-маршрутизаторы, которые участвуют в организации одной и той же VPN-сети заказчика, обмениваются между собой маршрутной информацией по протоколу MP-BGP. Префикс RD конфигурируется для каждой VRF-таблицы.

Маршрутная информация, которой обмениваются РЕ-маршрутизаторы по протоколу MP-BGP через глобальный или внутренний интерфейс:

• Адрес сети назначения (VPN-IPv4);
• Адрес следующего маршрутизатора для протокола (next hop);
• Метка Lvpn – определяется номером интерфейса (int) РЕ-маршрутизатора, к которому подключена одна из ЛВС офиса заказчика;
• Атрибут сообщения RT (route-target) – это атрибут VPN, который идентифицирует все ЛВС офисов, принадлежащие одной корпоративной сети заказчика или одной VPN.

Рис. 3. РЕ-маршрутизатор

Кроме того, каждый РЕ-маршрутизатор обменивается маршрутной информацией с магистральными P-маршрутизаторами одним из внутренних протоколов маршрутизации (OSPF или IS-IS) и создает также отдельную (внутреннюю) глобальную таблицу маршрутизации (ГТМ) для магистральной сети MPLS. Внешняя (VRF) таблица и внутренняя (ГТМ) глобальная таблицы маршрутизации в РЕ-маршрутизаторах изолированы друг от друга. P-маршрутизаторы обмениваются маршрутной информацией между собой и PЕ-маршрутизаторами с помощью традиционных протоколов внутренней IP-маршрутизации (IGP), например OSPF или IS-IS, и создают свои таблицы маршрутизации.

На основе таблиц маршрутизации с помощью протоколов распределения меток LDP или протоколов RSVP на основе технологии Traffic Engineering строятся таблицы коммутации меток на всех маршрутизаторах P (на PE создаются FTN), образующих определенный маршрут LSP (Label Switched Paths). В результате формируются маршруты с коммутацией по меткам LSP, по которым IP-пакеты продвигаются на основе значений меток заголовка MPLS и локальных таблиц коммутации, а не IP-адресов и таблиц маршрутизации.

Заголовок MPLS добавляется к каждому IP-пакету, поступающему на входной PE-маршрутизатор, и удаляется выходным PE-маршрутизатором, когда пакеты покидают сеть MPLS. В заголовке MPLS используется не метка, а стек из двух меток, т.е. входной PE назначает пакету две метки. Одна из них внешняя L, другая внутренняя Lvpn. Внешняя метка или метка верхнего уровня стека используется непосредственно для коммутации пакета по LSP от входного до выходного PE.

Необходимо отметить, что PE направляет входной трафик в определенный виртуальный путь LSP на основании FEC (Forwarding Equivalence Class – класса эквивалентности продвижения). FEC – это группа пакетов к условиям, транспортировки которых предъявляются одни и те же требования. Пакеты, принадлежащие одному FEC, перемещаются по одному LSP. Классификация FEC может осуществляться различными способами, например: по IP-адресу сети (префиксу сети) назначения, типу трафика, требованиям инжиниринга и т.д.

Если использовать классификацию по IP-адресу сети назначения, то для каждого префикса сети назначения создается отдельный класс. В этом случае протокол LDP полностью автоматизирует процесс создание классов и назначение им значений меток (табл. 1). Каждому входящему пакету, который направляется маршрутизатором PE на определенный IP-адрес сети офиса, назначается определенная метка на основании таблицы FTN.

Таблица 1. FTN (FEC To Next hop) на маршрутизаторе PE1

Из таблицы 1 следует, что значение внешней метки назначает входной маршрутизатор PE1 на основании IP-адреса локальной сети офиса. Внутренняя метка или метка нижнего уровня стека в процессе коммутации пакета по LSP от входного до выходного PE не участвует, а она определяет VRF или интерфейс на выходном PE, к которому присоединена ЛВС офиса заказчика.

Обмен информацией о маршрутах VPN по протоколу MP-BGP

Маршрутная информация (информация о маршрутах VPN), которую передает маршрутизатор PE1 маршрутизатору PE2 по протоколу BGP (красные линии):

• Адрес VPN-IPv4: 46.115.25.1:106:192.168.1.0;
• Next Hop = 46.115.25.1;
• Lvpn=3;
• RT= SC-3.

Различитель маршрутов RD=46.115.25.1:106 добавляется к IPv4-адресу сети LAN1 регионального офиса 1. Где 46.115.25.1 – это IP-адрес глобального интерфейса маршрутизатора PE1, через который PE1 взаимодействует с P-маршрутизаторами. Для данного маршрута VPN SC-3 администратор сети провайдера в маршрутизаторе PE1 или PE1 назначает метку (номер), например 106.

Когда маршрутизатор PE2 получает от PE1 адрес сети назначения VPN-IPv4, он отбрасывает разграничитель маршрутов RD, помещает адрес 192.168.1.0 в таблицу VRF3 SC-3 и отмечает, что запись была сделана протоколом BGP. Кроме того, он объявляет этот маршрут, подключенному к нему маршрутизатору заказчика CE2 для данной VPN SC-3.

Таблица VRF3 SC-3 также пополняется протоколом MP-BGP – об адресах сетей других ЛВС офисов данной VPN SC-3. Маршрутизатор PE1 направляет по протоколу MP-BGP маршрутную информация также другим маршрутизаторам: PE0 и PE3. В итоге, все маршруты в таблицах VRF маршрутизаторов (PE0, PE1, PE2 и PE3) содержат адреса всех сетей ЛВС офисов данного заказчика в формате IPv4.

Рис. 4. Таблицы VRF маршрутизаторов (PE0, PE1, PE2 и PE3)

Маршрутная информация, которую передает маршрутизатор PE2 маршрутизатору PE1 по протоколу MP-BGP (красные линии):

• Адрес VPN-IPv4: 46.115.25.2:116:192.168.2.0;
• Next Hop = 46.115.25.2;
• Lvpn=5;
• RT=SC-3.

Передача данных между ПК в корпоративной сети организованной на базе технологии MPLS L3 VPN

Рассмотрим, как происходит обмен данными между ПК 2 (IP: 192.168.1.2) сети LAN1 и ПК 1 (IP: 192.168.3.1) сети LAN. Для доступа к файлам, размещенным в директориях или логических дисках ПК 1 (LAN) с общим доступом, необходимо на ПК 2 (LAN1) в строке "Найти программы и файлы" (для ОС Win 7) ввести \\192.168.3.1 и нажать клавишу Enter. В результате на экране ПК 2 будут отображены директории с общим доступом ("расшаренные" директории или папки), которые размещены на ПК 1. Как это происходит?

При нажатии клавишу Enter в ПК 2 (LAN1) на сетевом уровне сформировался пакет с IP-адресом назначения 192.168.3.1. В первую очередь пакет поступает на маршрутизатор CE1 (рис. 5), который направляет его в соответствии с таблицей маршрутизацией на интерфейс int3 маршрутизатора PE1, так как он является следующим маршрутизатором для доступа к сети 192.168.3.0/24, в которой находятся ПК 1 (LAN ГО) с IP-адресом 192.168.3.1. С интерфейсом int3 связана таблица маршрутизации VRF2 SC-3, поэтому дальнейшее продвижение пакета осуществляется на основе ее параметров.

Как следует из таблицы VRF2 SC-3, следующим маршрутизатором для продвижения пакета к сети 192.168.3/24 является PE0 и эта запись была выполнена протоколом BGP. Кроме того, в таблице указано значение метки Lvpn=2, которая определяет интерфейс выходного маршрутизатора PE0. Отсюда следует, что дальнейшее продвижение пакета к сети 192.168.3/24 определяется параметрами глобальной таблицы маршрутизации ГТМ PE1.

Рис. 5. Передача данных между ПК2 (192.168.1.2) и ПК1 (192.168.3.1) сетей LAN1 и LAN главного офиса КС SC-3

В глобальной таблице (ГТМ PE1) адресу следующего маршрутизатора (NH - Next Hop) PE0 соответствует начальное значение внешней метки L=105, которая определяет путь LSP до PE0. Продвижение пакета по LSP происходит на основании L-метки верхнего уровня стека (L=105). Когда пакет проходит через маршрутизатор P3, а затем через маршрутизатор P1, метка L анализируется и заменяется новыми значениями. После достижения пакетом конечной точки LSP, маршрутизатор PE0 удаляет внешнюю метку L из стека MPLS.

Затем маршрутизатор PE0 извлекает из стека метку нижнего уровня стека Lvpn=2, которая определяет интерфейс int2, к которому присоединен маршрутизатор CE0 локальной сети главного офиса заказчика (LAN ГО). Далее из таблицы (VRF1 SC-3), содержащей все маршруты VPN SC3, маршрутизатор PE0 извлекает запись о значении метки Lvpn=2 и о связанном с ней маршруте к сети 192.168.3/24, который указывает на CE0 в качестве следующего маршрутизатора. Из таблицы следует, что запись о маршруте была помещена в таблицу VRF1 SC-3 протоколом IGP, поэтому путь движения пакета от PE0 до CE0 осуществляется по IP-протоколу.

Дальнейшее движение пакета от CE0 к ПК 1 с IP-адресом 192.168.3.1 осуществляется по MAC-адресу, так как CE0 и ПК 1 (192.168.3.1) находятся в одной ЛВС. После получения пакета-запроса от ПК 2 операционная система компьютера ПК 1 отправит копии своих директорий с общим доступом для ПК 2. Операционная система ПК 2, получив копии директорий с общим доступом от ПК 1, отображает их на экране монитора. Таким образом, через общественные сети MPLS провайдера по виртуальным каналам LSP осуществляется обмен данными между двумя ПК, принадлежащим разным ЛВС офисов одного заказчика.

Что касается подключения удаленного мобильного пользователя к ресурсам территориально распределенной корпоративной сети, то его можно реализовать с помощью одной из технологий Remote Access VPN (Remote Access IPSec VPN и SSL VPN). Необходимо отметить, что технология SSL VPN поддерживает два типа доступа: полный сетевой доступ и clientless. Технология clientless SSL VPN обеспечивает удаленный доступ к сети через стандартный веб-браузер, но в этом случае доступны только сетевые приложения с web-интерфейсом. Технология SSL VPN с полным сетевым доступом, после установки на ПК дополнительного приложения (VPN-клиента) обеспечивает доступ ко всем ресурсам территориально распределенной корпоративной сети.

Как правило, подключение удалённого пользователя к MPLS L3 VPN производится посредством сервера удаленного доступа (RAS), который подключается к одному из PE-маршрутизаторов MPLS сети. В нашем случае мобильный пользователь через сеть доступа (Интернет) подключен с помощью Remote Access IPSec VPN к RAS, который соединен с маршрутизатором PE0. Таким образом, мобильный пользователь через IPSec VPN подключается к своей корпоративной сети (корпорации SC-3), организованной на основе MPLS L3 VPN.

Модель MPLS L2 VPN, в которой настройка VPN обеспечивается провайдером или оператором связи (поставщиком услуг)

Организовать единое информационное пространство в трех офисах (например, корпорации SC-3), расположенных в пределах одного города можно на базе широкополосной Metro Ethernet сети оператора связи (L2 VPN). Одной из услуг сетей Metro Ethernet является организация корпоративных сетей через магистральные сети MAN (сети оператора связи в масштабах города). Для организации Metro Ethernet VPN (L2 VPN) используются различные технологии, например AToM (в основном EoMPLS), 802.1Q, L2TPv3 и так далее, но наиболее перспективной является технология MPLS L2 VPN или VPLS. В этом случае доставка клиентского трафика от локальных сетей офисов заказчика услуг к опорной сети MPLS VPN поставщика услуг осуществляется с помощью технологии второго уровня (Ethernet, Frame Relay или ATM).

Операторы связи предоставляют два типа услуг Ethernet сетей для организации виртуальных частных сетей на втором уровне модели OSI, которые формируются на базе технологии MPLS - это VPWS (Virtual Private Wire Services) и VPLS (Virtual Private LAN Services). Эти VPN строятся на базе псевдоканалов (pseudowire), которые связывают пограничные PE-маршрутизаторы сети провайдера (MPLS domain). Туннели LSP или логические каналы создаются при помощи меток, внутри которых прокладываются псевдоканалы (эмулированные VC) и по этим псевдоканалам передаются пакеты MPLS. VPWS основана на Ethernet over MPLS (EoMPLS). Но в VPLS в отличие от сетей point-to-point (P2P) VPWS организация псевдоканалов осуществляется с помощью многоточечных соединений (P2M).

В VPLS существует два способа установления псевдоканалов между любыми двумя PE, которые входят в состав данной VPLS (с помощью протокола BGP и протокола рассылки меток LDP). Расширенный протокол BGP (MP-BGP) обеспечивает автоматическое определения PE, которые взаимодействуют при построении территориально распределенной ЛВС на основе сервиса VPLS, и сигнализацию меток (vc-labels) виртуальных каналов. Для сигнализации vc-labels можно использовать и расширенный протокол LDP. В этом случае выявление всех PE-маршрутизаторов, которые входят в состав данной VPLS, осуществляется в режиме ручной настройки.

Можно также использовать системы управления, которые автоматизируют поиск и настройку PE устройств для организации VPLS сервисов. Для передачи кадров использует стек меток, верхняя метка предназначена для туннелей LSP, которая используется для достижения выходного PE. Нижняя метка - это метка VC Label, которая используется для демультиплексирования виртуальных каналов (pseudowires), передаваемых внутри одного туннеля. В одном туннеле может быть проложено множество псевдоканалов для разных экземпляров VPLS.

Для каждого экземпляра VPLS на PE создаются отдельные виртуальные коммутаторы VSI. Коммутаторы VSI изучают MAC-адреса и строят таблицы продвижения MPLS-пакетов. На основании данных таблицы продвижения коммутаторы VSI, получив кадры, инкапсулированные в пакеты MPLS, направляют их в псевдоканалы ведущие к пограничным PE, к которым подключены пограничные коммутаторы CE сегментов ЛВС офисов заказчика.

На базе VPWS (point-to-point) можно объединить две подсети офисов корпорации в одиную сеть, с единой сквозной IP-адресацией. VPLS – это технология, которая обеспечивает многоточечные соединения поверх пакетной сетевой инфраструктуры IP/MPLS. VPLS позволяет объединить несколько территориально распределенных локальных сетей офисов корпорации в единую локальную сеть. В этом случае магистральная сеть MPLS сервис-провайдера представляет собой виртуальный Ethernet-коммутатор (L2-коммутатор), который пересылает Ethernet-фреймы между сегментами ЛВС отдельных офисов заказчика. Схема территориально распределенной (в пределах города) локальной сети корпорации представлена на рис. 6.

Рис. 6. Схема территориально распределенной (в пределах города) локальной сети корпорации

Суть концепции VPLS заключается в прозрачной передаче Ethernet-фреймов ПК локальных сетей офисов (сегментов сетей офисов заказчика) заказчика по магистральной сети MPLS провайдера. Пограничными устройствами на стороне заказчика VPLS 1 служат коммутаторы CE0, CE1, CE2, которые соединены с устройствами PE0, PE1, PE2. PE-маршрутизаторы взаимодействуют друг с другом, с целью выявления всех PE, подключенных к VPLS 1. Устройства PE и P строят таблицы маршрутизации, на основе которых создаются каналы LSP и псевдоканалы.

В качестве протоколов сигнализации могут использоваться как BGP, так и LDP. Виртуальные коммутаторы VSI 1 устройств PE0, PE1, PE2 строят таблицы продвижения MPLS-пакетов. Например, VSI 1 устройства PE0 формирует таблицу коммутации, представленную на рис. 6. При поступлении Ethernet-фрейма c одного из ПК сети LAN главного офиса на вход устройства PE0 он инкапсулирует Ethernet-фрейм в MPLS пакет и, используя таблицу коммутации, направляет его в туннель, по которому пакет поступает на выходное устройство PE1.

Для продвижения пакета через MPLS сеть (через псевдоканалы в туннелях LSP) используется стек меток, который состоит из метки туннеля LSP и метки псевдоканала VC Label, например, 15. На выходном устройстве PE1 пакеты MPLS преобразуются в Ethernet-фреймы и направляются на коммутатор С1, к которому подключен ПК назначения с MAC-адресом 90:5C:E7:C8:56:93. В документах RFC 4761 и RFC 4762 подробно изложены методы сигнализации на базе протоколов BGP и LDP для локальных сетей организованных с помощью услуг VPLS.

Список источников информации:

1. Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов. 4-е изд. / В.Г. Олифер, Н.А. Олифер –СПб. Питер, 2010. – 944 с.

2. Олвейн, Вивек. Структура и реализация современной технологии MPLS.: Пер. с англ. – М. : Издательский дом «Вильямс», 2004. – 480 с.

Курс MPLS 3.0 – 5-дневный курс под руководством инструктора, специально разработанный для того, чтобы предоставить слушателям глубокие знания по технологии MPLS, которая используется в сетях провайдеров для организации высокоэффективной маршрутизации трафика, а также для создания VPN-сетей нового поколения.

Курс рассматривает теоретические вопросы строения и функционирования технологии MPLS на маршрутизаторах CISCO, а также детально покрывает вопросы обнаружения и устранения неисправностей при настройке и работе с технологией MPLS. Также в курсе подробно рассматривается использование MPLS для создания MPLS VPN и участие в них протокола MP-BGP. В обновленной версии курса добавлен раздел, описывающий возможность управления трафиком в MPLS (технология MPLS-TE).

Большая часть курса состоит из практических заданий, позволяющих применить полученные знания и умения в тестовой лабораторной сети. Технический контент курса был обновлен и адаптирован под Cisco IOS Software Release 15. Все лабораторные работы производятся на виртуальном стенде.

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

• Специалистам по работе с сетями, которым необходимо правильно реализовывать решения на основе маршрутизации в соответствии с сетевым дизайном, предлагаемым Cisco. Реализация включает в себя планирование, конфигурирование и проверку;
• Сетевым инженерам и персоналу технической поддержки;
• Администраторам, которые занимаются настройкой и проверкой работы протоколов маршрутизации в сетях предприятий.

По окончании курса вы будете уметь

• Понимать основные принципы работы технологии MPLS
• Понимать способы назначения и распространения меток
• Конфигурировать и отлаживать frame-mode MPLS на оборудовании CISCO
• Понимать принципы построения распределенной архитектуры MPLS-сетей и правила маршрутизации и распространения пакетов в таких сетях
• Конфигурировать, отлаживать и мониторить MPLS VPN сети
• Понимать принципы использования MPLS для создания систем управляемых сервисов
• Понимать принципы работы различных моделей доступа в Интернет, а также преимущества и недостатки каждой модели
• Внедрять технологию MPLS TE

Требуемая подготовка

• Сертификация Cisco Certified Network Associate (CCNA) или аналогичный уровень знаний и опыта
• Рекомендуется освоение материалов курса CCNA Basics и ICND или аналогичный уровень знаний и опыта, который может быть получен при прохождении курсов Cisco
• Курс построения масштабируемых сетей Cisco (BSCI) и Конфигурирование BGP на роутерах Cisco (BGP)
• Настоятельно рекомендуется обладание практическим опытом построения и эксплуатации сетей на оборудовании Cisco
• Курс QoS рекомендуется, так как знание QoS подразумевается в некоторых частях курса

Программа курса

Модуль 1. Функции MPLS

• Технология MPL
• Описание меток и стеков меток MPLS
• Сервисы MPLS

Модуль 2. Назначение и распределение меток

• Протокол LDP
• Распределение меток в Frame-Mode MPLS
• Описание сходимости в Frame-Mode MPLS

Модуль 3. Внедрение Frame-Mode MPLS на платформе Cisco IOS

• Использование коммутации Cisco Express Forwarding
• Настройка Frame-Mode MPLS на платформе Cisco IOS
• Проверка Frame-Mode MPLS на платформе Cisco IOS
• Поиск и устранение неисправностей в Frame-Mode MPLS на платформе Cisco IOS

Модуль 4. Технология MPLS VPN

• Знакомство с VPN
• Знакомство с архитектурой MPLS VPN
• Знакомство с моделью маршрутизации MPLS VPN
• Пересылка пакетов MPLS VPN
• Использование механизмов MPLS VPN на платформах Cisco IOS
• Настройка таблиц VRF
• Настройка MP-BGP сессий между пограничными маршрутизаторами провайдера
• Настройка протоколов маршрутизации малой масштабируемости между маршрутизаторами провайдера и клиента
• Проверка работы MPLS VPN
• Настройка OSPF как протокола маршрутизации между маршрутизаторами провайдера и клиента
• Настройка BGP как протокола маршрутизации между маршрутизаторами провайдера и клиента
• Поиск и устранение неисправностей MPLS VPN

Модуль 5. Комплексные MPLS VPN

• Знакомство с Overlapping VPN
• Знакомство с Central Services VPN
• Использование расширенных функций импорта и экспорта VRF
• Знакомство с сервисом управляемых маршрутизаторов клиента

Модуль 6. Доступ в интернет и MPLS VPN

• Комбинирование доступа в интернет и MPLS VPN
• Внедрение раздельных сервисов доступа в интернет и VPN
• Внедрение доступа в интернет как отдельного VPN

Модуль 7. Обзор MPLS TE

• Знакомство с концепцией Traffic Engineering
• Обзор компонентов MPLS TE
• Настройка MPLS TE на платформе Cisco IOS
• Проверка настроек MPLS TE на платформе Cisco IOS

Сертификации и экзамены

Данный курс готовит к экзаменам, входящим в программы подготовки сертифицированных специалистов международного уровня:

• Cisco Certified Internetwork Professional

Многие из тех, кто постоянно работает с сетями Internet, наверняка слышали о такой замечательной технологии как MPLS.
MPLS открывает нам такие новые возможности как AToM (Any Transport over Mpls),Traffic Engineering и пр.
AToM позволяет передавать поверх сети IP/MPLS трафик таких протоколов второго уровня как ATM, Frame Relay, Ethernet, PPP, и HDLC.
В данной статье я бы хотел остановиться на технологии EoMPLS.

Немного теории

MPLS - (англ. Multiprotocol Label Switching) - мультипротокольная коммутация по меткам.
В модели OSI теоретически можно расположить между вторым и третьим уровнями.

В соответствии с технологией MPLS, пакетам присваиваются метки для их передачи по сети. Метки включаются в заголовок MPLS, вставляемый в пакет данных.

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

MPLS объединяет в себе все лучшее от IP-маршрутизации 3-го уровня и коммутации 2-го уровня.
В то время как маршрутизаторам требуется интеллект сетевого уровня, чтобы определить, куда передавать трафик, коммутаторам нужно только передать данные на следующий транзитный участок, а это естественно проще, быстрее и дешевле. MPLS полагается на традиционные протоколы маршрутизации IP, чтобы объявить и установить сетевую топологию. Затем MPLS накладывается поверх этой топологии. MPLS предопределяет путь распространения данных по сети и кодирует эту информацию в виде метки, которую понимают маршрутизаторы сети.
Поскольку планирование маршрута происходит в начальный момент времени и на краю сети (где состыковываются сети потребителя и провайдера услуг), MPLS-помеченные данные требуют меньше вычислительных возможностей от маршрутизаторов, чтобы пересечь ядро сети провайдера услуг.

AToM
Для создания VPN Layer 2 по схеме точка-точка (point-to-point) разработана технология Any Transport Over MPLS (AToM), обеспечивающая передачу Layer 2 фреймов через MPLS сеть. AToM – это интегральная технология, включающая Frame Relay over MPLS, ATM over MPLS, Ethernet over MPLS.

EoMPLS инкапсулирует Ethernet фреймы в MPLS пакеты и использует стек меток для продвижения через MPLS сеть.

Канал, построенный на технологии EoMPLS, для потребителя услуг провайдера выглядит как виртуальный патчкорд.

Итак, поехали… Как же создать VPN Layer 2 с использованием EoMPLS?

Представим, что у нас есть очень важный клиент, которому необходимо объединить два филиала (Москва и Владивосток) в один сегмент сети, с единой сквозной IP-адресацией. Здесь и приходит на помощь AToM.

Как это видит клиент

Как это видит провайдер

Перед непосредственной настройкой VPN необходимо обеспечить работу MPLS.

Настроить его намного проще, чем кажется на первый взгляд (мы говорим о минимальной базовой настройке).

1. Для начала включим IP CEF и MPLS в глобальной настройке нашего маршрутизатора.
   

   MSK-1#conf t
   MSK-1(config)#ip cef
   MSK-1(config)#mpls ip

   
   Если такую команду маршрутизатор отказывается понимать, то либо текущая версия IOS, либо само оборудование не поддерживает MPLS.
2. Создаем loopback интерфейс, через который и будет работать наш MPLS.
   

   MSK-1#conf t
   MSK-1(config)#int lo1
   MSK-1(config-if)#ip address 1.1.1.1 255.255.255.255
   

   
   Технически может работать и непосредственно на интерфейсах, обеспечивающих связь между двумя маршрутизаторами. Но такая схема создает только лишь дополнительные трудности. Например, смена IP-адресации на участке между маршрутизаторами.
3. Настраиваем роутинг для обеспечения связи маршрутизаторов через loopback интерфейсы.
   Можно использовать либо статические маршруты, либо динамические протоколы маршрутизации. Возьмем к примеру, OSPF.
   

   MSK-1#conf t
   MSK-1(config)#router ospf 100
   MSK-1(config-router)#log-adjacency-changes
   MSK-1(config-router)#network 1.1.1.1 0.0.0.0 area 0
   MSK-1(config-router)#network 1.0.0.0 0.0.0.3 area 0
   MSK-1(config-router)#

   
   В качестве network указывается loopback-интерфейс и сети интерфейсов для связи между маршрутизаторами.

   Проверяем командой ping, что все работает.
   

   MSK-1#ping 1.1.1.3
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 1.1.1.3, timeout is 2 seconds:
   ! ! ! ! !
   Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
   MSK-1#

4. Укажем нашему роутеру, что в качестве «router-id» будет использоваться loopback интерфейс.
   

   MSK-1#conf t
   MSK-1(config)#mpls ldp router-id Loopback1 force

5. Включаем MPLS на интерфейсах, которые связывают маршрутизаторы между собой.
   

   MSK-1#conf t
   MSK-1(config)#int gi0/2
   MSK-1(config-if)#mpls ip

6. Смотрим, что связь по MPLS установлена.
   

   MSK-1#sh mpls ldp neighbor Peer LDP Ident: 1.1.1.2:0; Local LDP Ident 1.1.1.1:0 TCP connection: 1.1.1.2.12817 - 1.1.1.1.646 State: Oper; Msgs sent/rcvd: 36243/37084; Downstream Up time: 01:39:49 LDP discovery sources: Targeted Hello 1.1.1.1 -> 1.1.1.2, active, passive GigabitEthernet0/2, Src IP addr: 1.0.0.2 Addresses bound to peer LDP Ident: 1.1.1.2 1.0.0.2 1.1.1.6 Peer LDP Ident: 1.1.1.3:0; Local LDP Ident 1.1.1.1:0 TCP connection: 1.1.1.3.48545 - 1.1.1.1.646 State: Oper; Msgs sent/rcvd: 347/127; Downstream Up time: 01:39:49 LDP discovery sources: Targeted Hello 1.1.1.1 -> 1.1.1.3, active, passive Addresses bound to peer LDP Ident: 1.0.0.5 1.1.1.3 MSK-1#

Основная настройка MPLS на этом закончена.
Здесь я представил настройку лишь одного маршрутизатора. В самом конце статьи можно посмотреть конфиги всех маршрутизаторов.

Переходим к настройке канала EoMPLS для нашего воображаемого клиента.

Вся настройка сводится к созданию sub-интерфейсов на обоих маршрутизаторах.

С одной стороны:

MSK-1#conf t
MSK-1(config)int gi0/1.100
MSK-1(config-subif)#encapsulation dot1Q 100
MSK-1(config-subif)#xconnect 1.1.1.3 123456789 encapsulation mpls

С другой стороны:

Vladi-1#conf t
Vladi-1(config)int gi0/1.40
Vladi-1(config-subif)#encapsulation dot1Q 40
Vladi-1(config-subif)#xconnect 1.1.1.1 123456789 encapsulation mpls

Некоторые моменты поподробнее:
encapsulation dot1Q 100 - указываем тег dot1Q. Если проще - номер VLAN, по которому будет ходить трафик клиента от маршрутизатора до его порта на коммутаторе. На другом маршрутизаторе это значение может отличаться. Что позволяет нам объединить два совершено разных VLANа.
xconnect 1.1.1.3 - создаем иксконнект до необходимого маршрутизатора. Туда, куда включена вторая точка нашего клиента.
123456789 - Значение Virtual Circuit. Должно быть одинаковым на обоих маршрутизаторах. Именно это значение идентифицирует наш канал. Значние VC может быть в диапазоне от 1 до 4294967295.

Теперь остается лишь проверить, что наш канал заработал, и радоваться жизни.

MSK-1#sh mpls l2transport vc 123456789 Local intf Local circuit Dest address VC ID Status Gi0/1.100 Eth VLAN 100 1.1.1.3 123456789 UP MSK-1#

И детальная информация:

MSK-1#sh mpls l2transport vc 123456789 detail Local interface: Gi0/1.100 up, line protocol up, Eth VLAN 100 up Destination address: 1.1.1.3, VC ID: 123456789, VC status: up Next hop: 1.0.0.2 Output interface: Gi0/2, imposed label stack {599 17} Create time: 02:33:18, last status change time: 02:33:14 Signaling protocol: LDP, peer 1.1.1.3:0 up MPLS VC labels: local 140, remote 17 Group ID: local 0, remote 0 MTU: local 1500, remote 1500 Remote interface description: Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 1391338893, send 1676515662 byte totals: receive 2765021070, send 3317727319 packet drops: receive 0, send 0 MSK-1#

Проблемы с MTU

Необходимо помнить, что при работе MPLS, к пакету Ethernet дополнительно добавляется 12 байт.
Чтобы избежать фрагментации пакетов, на интерфейсах можно указать «mpls mtu 1512». Но в данном случае, все устройства, находящие на пути следования, должны поддерживать пропускание пакетов с размером MTU, больше чем 1500.

P.S. Конфиги всех роутеров как и обещал.

Москва
#mpls ip #router ospf 100 log-adjacency-changes network 1.1.1.1 0.0.0.0 area 0 network 1.0.0.0 0.0.0.3 area 0 #interface GigabitEthernet0/2 ip address 1.0.0.1 255.255.255.252 mpls ip #interface Loopback1 ip address 1.1.1.1 255.255.255.255 #interface GigabitEthernet0/1.100 encapsulation dot1Q 100 xconnect 1.1.1.3 123456789 encapsulation mpls

Описать абсолютно все аспекты в одной статье невозможно. Постарался рассказать как можно кратко тот минимум, который необходим для работы.