MPLS - MultiProtocol Label Switching
MPLS оказывает влияние на маршрутизацию пакетов.
В традиционной маршрутизации на маршрут влияет Destination IP, в MPLS то, куда отправляется пакет, зависит не только Destination IP, но и значение специально метки - Label.
В традиционной маршрутизации каждый маршрутизатор сам принимает решение о маршрутизации пакета. В MPLS путь построен заранее.
По мере продвижения пакета от маршрутизатора к маршрутизатору, в MPLS у пакета "перекидываются" метки.

Применение MPLS

Сам по себе MPLS бесполезен, но на его основе работают следующие функции:
- MPLS L2VPN
- MPLS L3VPN
- MPLS TE

Базовый MPLS

При передаче пакета MPLS, маршрутизатор не смотрит во внутренние заголовки.
Под заголовком могут находиться любые протоколы (IP, Ehternet, ATM)

Несмотря на то, что 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

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

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

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

Наибольшую ценность MPLS представляет для провайдеров.
Для маршрутизации между AS провайдеры используют BGP. И именно в связке с BGP станут понятны преимущества MPLS.

Сеть MPLS строится поверх IP, за счет чего обладает гибкостью и масштабируемостью.
Трафик 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).
LSR — Label Switch Router — это любой маршрутизатор в сети MPLS. Называется он так, потому что выполняет какие-то операции с метками. В нашем примере это все узлы: R1, R2, R3, R4, R5, R6.
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 на самом деле однонаправленный. Это означает, что, во-первых, трафик по нему передаётся только в одном направлении, во-вторых, если существует «туда», не обязательно существует «обратно», в-третьих, «обратно» не обязательно идёт по тому же пути, что «туда».

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

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

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

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

Для чего всё это нужно. Дело в том, что для каждого FEC выбирается свой LSP — свой путь через сеть MPLS. И тогда, например, для WEB-сёрфинга вы устанавливаете приоритет QoS BE — это будет один FEC — а для VoIP — EF — другой 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 к тому, что передаётся под его заголовком — IP, Ethernet, ATM. Не нужно городить GRE или какие-то другие до боли в суставах неудобные VPN.

Заголовок MPLS выглядит следующим образом:

Весь заголовок MPLS — это 32 бита.
Label — собственно сама метка. Длина — 20 бит.
TC — Traffic Class. Несёт в себе приоритет пакета, как поле DSCP в IP.
S — Bottom of Stack — индикатор дна стека меток длиной в 1 бит.
Заголовков MPLS на пакете может быть несколько, например, внешняя для коммутации в сети MPLS, а внутренняя указывает на определённый VPN. Чтобы LSR понимал с чем он имеет дело. В бит S записывается «1», если это последняя метка (достигнуто дно стека) и «0», если стек содержит больше одной метки (ещё не дно). То есть LSR не знает, сколько всего меток в стеке, но знает, одна она или больше — да этого и достаточно на самом-то деле. Ведь любые решения принимаются на основе только самой верхней метки, независимо от того, что там под ней. Зато, снимая метку, он уже знает, что дальше сделать с пакетом: продолжить работу с процессом MPLS или отдать его какому-то другому (IP, Ethernet, ATM, FR итд).
В итоге, несмотря на то, что длина заголовка MPLS фиксированная, самих заголовков может быть много — и все они располагаются друг за другом.
TTL — Time To Live — полный аналог IP TTL. Даже той же самой длиной обладает — 8 бит. Единственная задача — не допустить бесконечного блуждания пакета по сети в случае петли.

Таким образом, заголовок MPLS втискивается между канальным уровнем и теми данными, которые он несёт — в случае IP — сетевым.

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

Как уже было сказано выше, может существовать 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 получает пакет, он точно знает, что верхнюю метку нужно просто удалить.

1: Метка Router Alert Label — аналог опции Router Alert в IP

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

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

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

В целом стало понятно, как передаётся трафик и как в этом участвуют метки MPLS.
Но метки не берутся от балды. Специальные протоколы распределяют метки между Egress LSR и Ingress LSR, создавая LSP.

Распространение меток

Как вы уже поняли, на некоторых устройствах можно всё сделать вручную.
Но существует три базовых протокола для распространения меток — LDP, RSVP-TE и MBGP

• LDP — самый простой и понятный способ — опирается на маршрутную информацию узлов.
• RSVP-TE — это развитие некогда разработанного, но непопулярного протокола RSVP — используется в MPLS-TE для построения LSP, удовлетворяющих определённым условиям. Для его работы нужны IGP, поддерживающие Traffic Engineering (OSPF, ISIS).
• MBGP — близкий родственник BGP, но это протокол из немного другой истории, он передаёт метки для других целей. Поэтому и стоит он в стороне от LDP и RSVP-TE.

Методы распространение меток

Метки распространяются в направлении от получателя трафика к отправителю, а точнее от Egress LER к Ingress LER.

В MPLS Downstream — это от отправителя к получателю, а Upstream от получателя к отправителю.

Я для себя определил это так: LSP «растёт» из FEC вверх к Ingress LER, как дерево, а пользовательский трафик «спускается» к получателю по LSP, как дождевая вода по веткам. То есть метки распространяются навстречу трафику.

Говорят ещё, что LSP строится навстречу трафику.

Сам же механизм распространения меток зависит от протокола, настроек и производителя

DU и DoD

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

Первый режим называется DU — Downstream Unsolicited. Как только LSR узнаёт про FEC, он рассылает всем своим MPLS-соседям метки для этого FEC.

Все LSR узнают обо всех FEC по всем возможным путям. Сначала соответствие FEC-метка расходится по всей сети от соседа к соседу
А потом каждый LSR выбирает только тот, который пришёл по лучшему пути, и его использует для LSP
Быстро, просто, понятно, хотя и не всегда нужно, чтобы все знали обо всём.

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

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

Ordered Control и Independent Control

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

Independent Control - LSR рассылает метки для FEC, как только узнал о нём. То есть метки передаются неупорядоченно. Удобен тем, что трафик можно начинать передавать ещё до того, как весь путь построен. Этим же и опасен.

Liberal Label Retention Mode и Conservative Label Retention Mode

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

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

Conservative Label Retention Mode — лишняя метка отбрасывается сразу, как она получена. Это позволяет сократить количество используемых меток, но и MPLS среагирует медленнее в случае аварии.

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 — tLDP.

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

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

LDP

LDP - Labed Distribution Protocol

Рассмотрим его на примере сети:

1. После включения LDP LSR делает мультикастовую рассылку UDP-дейтаграмм во все интерфейсы на адрес 224.0.0.2 и порт 646, где активирован LDP — так происходит поиск соседей.
   TTL таких пакетов равен 1, поскольку LDP-соседство устанавливается между непосредственно подключенными узлами.
   Такие сообщения называются 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.
   Далее он выбирает входную метку для данного FEC, записывает эту информацию в свою таблицу меток и отправляет её вышестоящим соседям.
   

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

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

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