?

Log in

No account? Create an account

Изменяю своим привычкам


Previous Entry Share Next Entry
Сети для самых маленьких. Часть одиннадцатая. MPLS L3VPN
eucariot
[Все выпуски]
10. Сети для самых маленьких. Часть десятая. Базовый MPLS
9. Сети для самых маленьких. Часть девятая. Мультикаст
8.1 Сети для Самых Маленьких. Микровыпуск №3. IBGP
8. Сети для самых маленьких. Часть восьмая. BGP и IP SLA
7. Сети для самых маленьких. Часть седьмая. VPN
6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация
5. Сети для самых маленьких: Часть пятая. NAT и ACL
4. Сети для самых маленьких: Часть четвёртая. STP
3. Сети для самых маленьких: Часть третья. Статическая маршрутизация
2. Сети для самых маленьких. Часть вторая. Коммутация
1. Сети для самых маленьких. Часть первая. Подключение к оборудованию cisco
0. Сети для самых маленьких. Часть нулевая. Планирование



В прошлый раз мы не оставили камня на камне при разборе MPLS. И это, пожалуй, хорошо.

Но до сих пор только призрачно прорисовывается применение его в реальной жизни. И это плохо.

Этой статьёй начнём исправлять ситуацию. Вообще же читателя ждёт череда из трёх статей: L3VPN, L2VPN, Traffic Engineering, где мы постараемся в полной мере рассказать, для чего нужен MPLS на практике.



Итак, linkmeup - уже больше не аутсорсинг по поддержке хоть и крупной, но единственной компании, мы - провайдер. Можно даже сказать федеральный провайдер, потому что наша оптика ведёт во все концы страны. И наши многочисленные клиенты хотят уже не только высокоскоростной доступ в Интернет, они хотят VPN.
Сегодня разберёмся, что придётся сделать на нашей сети (на которой уже меж тем настроен MPLS), чтобы удовлетворить эти необузданные аппетиты.

SDSM11-L3VPN

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


Как организовать взаимодействие двух отдалённых узлов в сети Интернет? Очень просто, если они имеют публичные адреса - IP для этого и был придуман. Они могут общаться напрямую. В любом случае, чтобы соединить две точки в Интернете, нужно два публичных адреса - по одному с каждой стороны. А если у нас адреса частные (10/8, 172.16/20, 192.168/16)?
Тогда они будут "натиться" с одной стороны, а потом "разначиваться" с другой стороны. А NAT - штука, скажу я вам, ой, какая неприятная.

Поэтому существует VPN. Virtual Private Network - это набор технологий и протоколов, который позволяет подключить что-то к вашей частной сети через чужую сеть, в частности, через Интернет.
Например, Томский филиал компании linkmeup можно подключить к головному офису в Москве с помощью VPN через Интернет, как мы и делали в выпуске про VPN.
То есть другие филиалы через VPN вы будете видеть так, как если бы они находились в соседней комнате и подключены вы к ним через шнурок, коммутатор или маршрутизатор. Соответственно и общаться узлы могут по своим приватным адресам, а не по публичным.

В этом случае ваши личные данные с частными адресами упаковываются в пакеты с публичными адресами и как в туннеле летят через Интернет.

Это называется клиентский VPN, потому что клиент сам озабочен его конфигурацией и поднятием. Единственный его посредник - Интернет.
Его мы разобрали в 7-м выпуске и о нём же в блоге linkmeup есть огромная статья нашего читателя - Вадима Семёнова.

Другой возможный вариант - провайдерский VPN. В этом случае провайдер предоставляет клиенту несколько точек подключения, а внутри своей сети строит каналы между ними.
От клиента тогда требуется только оплачивать провайдеру этот канал.
Провайдерский VPN, в отличие от клиентского позволяет обеспечить определённое качество услуг. Обычно при заключении договора подписывается SLA, где оговариваются уровень задержки, джиттера, процент потерь пакетов, максимальный период недоступности сервисов итд. И если в клиентском VPN вы можете только уповать на то, что в интернете сейчас всё спокойно, и ваши данные дойдут в полном порядке, то в провайдерском, вам есть с кого спросить.

Вот на провайдерском VPN мы в этот раз и сосредоточимся.

Речь пойдёт о VPN 3-го уровня - L3VPN, когда нам необходимо обеспечить маршрутизацию сетевого трафика. L2VPN - тема следующего выпуска.


VRF, VPN-Instance, Routing-instance


Когда речь заходит о VPN, возникает вопрос изоляции трафика. Никто другой не должен его получать, а ваши частные адреса не должны появляться там, где им не положено - то есть в Интернете, в сети нашего провайдера и в VPN других клиентов.
Когда вы настраиваете GRE-туннель через Интернет (или OpenVPN, на ваш вкус), то ваши данные автоматически обособлены - никто не видит ваши частные адреса в Интернете, и трафик не попадёт в чужие руки (если не поднимать вопрос нацеленной атаки).
То есть существует некий туннель между двумя публичными адресами, который никак не связан ни с вашим провайдером, ни с другими транзитными туннелями. Два разных VPN - два совершенно разных туннеля - и по вашему туннелю течёт только ваши трафик.
Совсем иначе стоит вопрос в провайдерском VPN - одна и та же магистральная сеть должна переносить данные сотен клиентов. Как тут быть?
Нет, можно, конечно, и тут GRE, OpenVPN, L2TP и иже с ними, но тогда всё, чем будут заниматься инженеры эксплуатации - это настраивать туннели и лопатить миллионы строк конфигурации.
Но проблема глубже - вопрос организации такого универсального для всех канала вторичен: главное сейчас - как изолировать двух клиентов, подключенных к одному маршрутизатору? Если, например, оба используют сеть 10.0.0.0/8, как не позволить трафику маршрутизироваться между ними?

Здесь мы приходим к понятию VRF - Virtual Routing and Forwarding instance. Терминология тут не устоявшаяся: в Cisco - это VRF, в Huawei - VPN-instance, в Juniper - Routing Instance. Все названия имеют право на жизнь, но суть одна - виртуальный маршрутизатор. Это что-то вроде виртуальный машины в каком-нибудь VirtualBox - там на одном физическом сервере поднимается много виртуальных серверов, а здесь на одном физическом маршрутизаторе есть много виртуальных маршрутизаторов.
Каждый такой виртуальный маршуртизатор - это по сути отдельный VPN. Их таблицы маршрутизации, FIB, список интерфейсов и прочие параметры не пересекаются - они строго индивидуальны и изолированы. Ровно так же они обособлены и от самого физического маршрутизатора. Но как и в случае виртуальных серверов, между ними возможна коммуникация.

VRF - он строго локален для маршрутизатора - за его пределами VRF не существует. Соответственно VRF на одном маршрутизаторе никак не связан с VRF на другом.
Раз уж мы рассматриваем все примеры на оборудовании Cisco, то будем придерживаться их терминологии.

VRF Lite


Так называется создание провайдерского VPN без MPLS.
Вот, например, так можно настроить VPN в пределах одного маршрутизатора:



Тут у нас есть два клиента - TAR's Robotics и C3PO Electronic.

Интерфейсы FE0/0 и FE0/1 принадлежат VPN C3PO Electronic, интерфейсы FE1/0 и FE1/1 - VPN TAR's Robotics. Внутри одного VPN узлы общаются без проблем, между собой - уже никак.



Вот так выглядят их таблицы маршрутизации на провайдерском маршрутизаторе:




Маршруты C3PO Electronic не попадут в сети TARS' Robotics и наоборот.

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


Используя VRF Lite можно легко пробросить VPN между разными концами сети. Для этого нужно настроить одинаковые VRF на всех промежуточных узлах и правильно привязать их к интерфейсам:


То есть R1 и R2 будут общаться друг с другом через одну пару интерфейсов в глобальной таблице маршрутизации, через другую пару в VRF TARS' Robotics и через третью в VRF C3PO Electronic. Разумеется, это могут быть сабинтерфейсы.
Аналогично между R2-R3.
Таким образом, получаются две виртуальные сети, которые друг с другом не пересекаются. Учитывая этот факт, в каждой такой сети нужно поднимать свой процесс IGP, чтобы обеспечить связность.
В данном случае будет один процесс для физического маршрутизатора, один для TARS' Robotics, один для C3PO Electric. Соответственно, каждый из них будет сигнализироваться отдельно от других по своим собственным интерфейсам.

Если говорить о передаче данных, то пакет, придя от узла из сети TARS's Robotics, сразу попадает в соответствующий VRF, потому что входной интерфейс R1 является его членом. Согласно FIB данного VRF он направляется на R2 через выходной интерфейс. На участке между R1 и R2 ходят самые обычные IP-пакеты, которые и не подозревают, что они принадлежат разным VPN. Вся разница только в том, что они идут по разным физическим интерфейсам, либо несут разный тег в заголовке 802.1q. R2 принимает этот пакет интерфейсом, который также член VRF TARS's Robotics.
R2 варит пакет в нужном FIB и отправляет дальше, согласно IGP. И так до самого выхода пакета ну другой стороне сети.

Как узел определяет, что полученный пакет относится к определённому VPN? Очень просто: данный интерфейс привязан ("прибинден") к конкретному VRF.
Как вы уже, вероятно, заметили, эти интерфейсы помечены на иллюстрации колечками соответствующего цвета.

Включим немного воображение:
Если пакет проходит через серое колечко, он переходит на серую сторону окрашивается в серый цвет. Далее он будет уже проверяться по серой таблице маршрутизации.
Аналогично, когда пакет проходит через золотое кольцо, он покрывается благородной позолотой и проверяется по золотой таблице маршрутизации.

Точно также выходные интерфейсы привязаны к VPN, и соответствующие таблицы маршрутизации знают, какие за ними сети находятся.
Учитывайте, что всё, что мы говорим о таблицах маршрутизации, касается и FIB - в каждом VPN свой собственный FIB.
Между маршрутизаторами пакеты не окрашены. Пакеты разных VPN не смешиваются, потому что идут либо по разных физическим интерфейсам, либо по одному, но имеют разные VLAN-теги (каждому VRF соответствует свой выходной саб-интерфейс).

Вот он простой и прозрачный VPN - для клиента сформирована самая что ни на есть частная сеть.


Но этот способ удобен, пока у вас 2-3 клиента и 2-3 маршрутизатора. Он совершенно не поддаётся масштабированию, потому что один новый VPN означает новый VRF на каждом узле, новые интерфейсы, новый пул линковых IP-адресов, новый процесс IGP/BGP.
А если точек подключения не 2-3, а 10, а если нужно ещё резервирование, а каково это поднимать IGP с клиентом и обслуживать его маршруты на каждом своём узле?

И тут мы подходим уже к MPLS VPN.

MPLS L3VPN


MPLS VPN позволяет избавиться от вот этих неприятных шагов:
1) Настройка VRF на каждом узле между точками подключения
2) Настройка отдельных интерфейсов для каждого VRF на каждом узле.
3) Настройка отдельных процессов IGP для каждого VRF на каждом узле.
4) Необходимость поддержки таблицы маршрутизации для каждого VRF на каждом узле.

Да как так-то?

Рассмотрим, что такое MPLS L3VPN на примере такой сети:



Итак, это три филиала нашего клиента TARS' Robotics: головной офис в Москве и офисы в Новосибирске и Красноярске - весьма удалённые, чтобы дотянуть до них своё оптоволокно. А у нас туда уже есть каналы.

Центральное облако - это мы - linkmeup - провайдер, который предоставляет услугу L3VPN.

Вообще говоря, TARS Robotics как заказчику, совершенно без разницы, как мы организуем L3VPN - да пусть мы хоть на поезде возим их пакеты, лишь бы в SLA укладывались. Но в рамках данной статьи, конечно, внутри нашей сети работает MPLS.

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, хотя остаётся вопрос, как найти выходной маршрутизатор, на который мы ответим дальше.




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

Роль меток MPLS


Если мы вернёмся к изначальной схеме с VRF-Lite, то проблема в том, что серый цвет IP-пакета (индикатор принадлежности к VPN TARS' Robotics) существует только в пределах узла, при передаче его на другой эта информация переносится в тегах VLAN. И если мы откажемся от сабинтерфейсов на промежуточных узлах, начнётся каша. А сделать это нужно во благо всего хорошего.
Чтобы этого не произошло в сценарии с MPLS, Ingress LSR на пакет навешивает специальную метку MPLS - Сервисную - она идентификатор VPN. Egress LSR (последний маршрутизатор - R3) по этой метке понимает, что IP-пакет принадлежит VPN TARS's Robotics и просматривает соответствующий FIB.
То есть очень похоже на VLAN, с той разницей, что только первый маршрутизатор должен об этом заботиться.

Но на основе сервисной метки пакет не может коммутироваться по MPLS-сети - если мы где-то её поменяем, то Egress LSR не сможет распознать, какому VPN она принадлежит.

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

Для чего нужно две метки, почему нельзя обойтись одной сервисной? Пусть бы, например, одна метка на Ingress LSR задавал один VPN, другая - другой. Соответственно дальше по пути они бы тоже коммутировались как обычно, и Egress LSR точно знал бы какому VRF нужно передать пакет.
Вообще говоря, сделать так можно было бы, и это бы работало, но тогда в магистральной сети для каждого VPN был бы отдельный LSP. И если, например, у вас идёт пучок в 20 VPN с R1 на R3, то пришлось бы создавать 20 LSP. А это сложнее поддерживать, это перерасход меток, это лишняя нагрузка на транзитные LSR. Да и, строго говоря, это то, от чего мы тут пытаемся уйти.
Кроме того, для разных префиксов одного VPN могут быть разные метки - это ещё значительно увеличивает количество LSP.
Куда ведь проще создать один LSP, который будет туннелировать сразу все 20 VPN?

Транспортная метка

Таким образом, нам необходима транспортная метка. Она верхняя в стеке.

Транспортная метка

Она определяет LSP и меняется на каждом узле.
Она добавляется (PUSH) Ingress LSR и удаляется (POP) Egress LSR (или Penultimate LSR в случае PHP). На всех промежуточных узлах она меняется с одной на другую (SWAP).
Распространением транспортных меток занимаются протоколы LDP и RSVP-TE. Об этом мы тоже очень хорошо поговорили в прошлой статье и не будем останавливаться сейчас.
В целом транспортная метка нам мало интересна, поскольку всё и так уже понятно, за исключением одной детали - FEC.
FEC здесь уже не сеть назначения пакета (приватный адрес клиента), это адрес последнего LSR в сети MPLS, куда подключен клиент.
Это очень важно, потому что LSP не в курсе про всякие там VPN, соответственно ничего не знает о их приватных маршрутах/префиксах. Зато он хорошо знает адреса интерфейсов Loopback всех LSR. Так вот к какому именно LSR подключен данный префикс клиента, подскажет BGP - это и будет FEC для транспортной метки.
В нашем примере R1, опираясь на адрес назначения клиентского пакета, должен понять, что нужно выбрать тот LSP, который ведёт к R3.
Чуть позже мы ещё вернёмся к этому вопросу.



Сервисная метка

Сервисная метка

Нижняя метка в стеке - сервисная. Она является уникальным идентификатором префикса в конкретном VPN.
Она добавляется Ingress LSR и больше не меняется нигде до самого Egress LSR, который в итоге её снимает.
FEC для Сервисной метки - это префикс в VPN, или, грубо говоря, подсеть назначения изначального пакета. В примере ниже FEC – 192.168.1.0/24 для VRF C3PO и 172.16.1.0/24 для VRF TARS.
То есть Ingress LSR должен знать, какая метка выделена для этого VPN. Как это происходит - предмет дальнейших наших с вами исследований.
Вот так выглядит целиком процесс передачи пакетов в различных VPN'ах:


Обратите внимание, что для двух разных VPN отличаются сервисные метки – по ним выходной маршрутизатор узнаёт, в какой VRF передавать пакет.
А транспортные в данном случае одинаковые для пакетов обоих VRF, потому что они используют один LSP – R1↔R2↔R3.



Иллюстратор проекта - Анастасия Мецлер.
За помощь в подготовке статьи, спасибо JDima.


Оставайтесь на связи



Продолжение читайте тут: http://linkmeup.ru/blog/204.html
В силу ограничений длины топика в ЖЖ.


  • 1
Как всегда - очень круто! Спасибо!
Когда ожидается продолжение?

Оххх, сложный вопрос. В следующем году точно - L2VPN.
Сейчас мы запускаем новый проект - много сил будет на него уходить.

Спасибо за твою работу! Всегда с нетерпением жду твои статьи. Раньше всем новичкам давал Вито Амато "Основы организации сетей Cisco" (может потому что сам учился на этих книгах и показалось очень доступно), теперь только твои статьи! ;)

Тема L3VPN достаточно сложная,и мне было очень трудно изложить ее доступно.
Но следующие выпуски будут ещё сложнее.
За QoS, например, страшно будет даже браться.

  • 1