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

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

Вот какой подход предлагает MPLS VPN: коммутация в пределах магистральной сети осуществляется, как мы описывали в предыдущей статье, по одной метке 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. В частности на R2 заменяется транспортная метка — SWAP Label. 6) R3 в итоге получает пакет, отбрасывает транспортную метку, а по сервисной понимает, что тот принадлежит к VPN TARS' Robotics. 7) Он снимает все заголовки MPLS и отправляет пакет в интерфейс таким, какой он пришёл на R1 изначально.

На диаграмме железо-углерод видно, как преображается пакет по ходу движения от ПК1 до ПК2:

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

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

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

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