# Data Plane или передача пользовательских данных

Сначала надо бы сказать, что в MPLS VPN VRF создаётся только на тех маршрутизаторах, куда подключены клиентские сети. В нашем примере это R1 и R3. Любым промежуточным узлам не нужно ничего знать о VPN.\
А между ними нужно как-то обеспечить изолированную передачу пакетов разных VPN.

Вот какой подход предлагает MPLS VPN: коммутация в пределах магистральной сети осуществляется, как мы описывали в [предыдущей статье](https://linkmeup.ru/blog/154.html), по одной метке MPLS, а принадлежность конкретному VPN определяется другой — дополнительной меткой.

Подробнее:

1\) Вот клиент отправляет пакет из сети 172.16.0.0/24 в сеть 172.16.1.0/24.\
2\) Пока он движется в пределах своего филиала (сеть клиента), он представляет из себя самый обычный пакет IP, в котором Source IP — 172.16.0.2, Destination IP — 172.16.1.2.\
3\) Сеть филиала знает, что добраться до 172.16.1.0/24 можно через Сеть провайдера.\
До сих пор это самый обычный пакет, потому что стык идёт по чистому IP с частными адресами.\
4\) Дальше R1 (маршрутизатор провайдера), получает этот пакет, знает, что он принадлежит определённому VRF (интерфейс привязан к VRF TARS), проверяет таблицу маршрутизации этого VRF — в какой из филиалов отправить пакет — и инкапсулирует его в пакет MPLS.\
Метка MPLS на этом пакете означает как раз его принадлежность определённому VPN. Это называется **«Сервисная метка»**.\
5\) Далее наш маршрутизатор должен отправить пакет на R3 — за ним находится искомый офис клиента. Естественно, по MPLS. Для этого при выходе с R1 на него навешивается **транспортная метка MPLS**. То есть в этот момент на пакете две метки.\
Продвижение пакета MPLS по облаку происходит ровно так, как было описано в [выпуске про базовый MPLS](https://linkmeup.ru/blog/154.html). В частности на R2 заменяется транспортная метка — SWAP Label.\
6\) R3 в итоге получает пакет, отбрасывает **транспортную** метку, а по **сервисной** понимает, что тот принадлежит к VPN TARS' Robotics.\
7\) Он снимает все заголовки MPLS и отправляет пакет в интерфейс таким, какой он пришёл на R1 изначально.

На диаграмме железо-углерод видно, как преображается пакет по ходу движения от ПК1 до ПК2:\
![](https://habrastorage.org/files/7fc/c5b/5dc/7fcc5b5dcd884a6295a649cfadd9c96e.gif)

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

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

Итак, в промежутке между R1 и R3 (то есть в облаке MPLS) ни у кого нет понимания, что такое VPN – пакеты VPN движутся по метками до пункта назначения, и только он уже должен волноваться, что с ними делать дальше. Это убирает необходимость поднимать VRF на каждом узле и, соответственно, поддерживать таблицу маршрутизации, FIB, список интерфейсов итд.\
Учитывая, что весь дальнейший путь пакета определяется на первом MPLS-маршрутизаторе (R1), отпадает нужда и в индивидуальном протоколе маршрутизации в каждом VPN, хотя остаётся вопрос, как найти выходной маршрутизатор, на который мы ответим дальше.

![](https://img-fotki.yandex.ru/get/6214/83739833.52/0_107085_688266c0_L.png)

Чтобы лучше понять, как передаётся трафик, нужно выяснить значение меток в пакете.