SDSM
0
2587
0
В прошлом выпуске мы не оставили камня на камне при разборе MPLS. И это, пожалуй, хорошо.
Но до сих пор только призрачно прорисовывается применение его в реальной жизни. И это плохо.
Этой статьёй начнём исправлять ситуацию. Вообще же читателя ждёт череда из трёх статей: L3VPN, L2VPN, Traffic Engineering, где мы постараемся в полной мере рассказать, для чего нужен MPLS IRL.
Содержание выпуска:
!!!
Традиционное видео:
!!!
Как организовать взаимодействие двух отдалённых узлов в сети Интернет? Очень просто, если они имеют публичные адреса — 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 мы сейчас и сосредоточимся.
VRF, VPN-Instance, Routing-instance
Когда речь заходит о VPN, возникает вопрос изоляции трафика. Никто другой не должен его получать, а ваши частные адреса не должны появляться там, где им не положено.
Когда вы настраиваете GRE-туннель через Интернет (или OpenVPN, на ваш вкус), то ваши данные автоматически обособлены — никто не видит ни ваши частные адреса в Интернете и трафик не попадёт в чужие руки (если не поднимать вопрос нацеленной атаки).
То есть существует некий туннель между двумя публичными адресами, который никак не связан ни с вашим провайдером, ни с другими транзитными туннелями. Два разных VPN — два совершенно разных туннеля.
Совсем иначе стоит вопрос в провайдерском VPN — одна и та магистральная сеть должна переносить данные сотен клиентов. Как тут быть?
Нет, можно, конечно, и тут GRE, OpenVPN, L2TP и иже с ними, но тогда всё, чем будут заниматься инженеры эксплуатации — это настраивать туннели и лопатить миллионы строк конфигурации.
И, да, очень остро стоит вопрос изоляции — если к одному маршрутиазтору подключено два клиента с пересекающимся адресным пространством? Например, у обоих есть подсеть 10.0.0.0/24.
Здесь мы приходим к понятию VRF — Virtual Routing and Forwarding instance. Терминология тут не устоявшаяся: в Cisco — это VRF, в Huawei — VPN-instance, в Juniper Routing Instance. Все названия имеют право на жизнь, но суть одна — виртуальный маршрутизатор. Это что-то вроде виртуальный машины в каком-нибудь VirtaualBox — там на одном физическом сервере поднимается много вирутальных, а здесь на одном физическом маршрутизаторе есть много виртуальных.
Каждый такой виртуальный маршуртизатор — это по сути отдельный VPN. Их таблицы маршрутизации, FIB, список интерфейсов и прочие параметры не пересекаются — они строго индивидуальны и изолированы. Ровно так же они обособлены и от самого физичесого маршрутизатора. Но как и в случае виртуальных серверов, между ними возможна коммуникация.
Раз уж мы рассматриваем все примеры на оборудовании Cisco, то позвольте придерживаться их терминологии.
VRF — он строго локален для маршрутизатора — за его пределами VRF не существует. Соответственно VRF на одном маршрутизаторе никак не связан с VRF на другом.
VRF Lite
Так называется создание провайдерского VPN без MPLS.
Вот, например, так можно настроить VPN в пределах одного маршрутизатора:
VRF_Lite_0_for_article.png!!!
Тут у нас есть два клиента — TAR’s Robotics и C3PO Electronic.
Интерфейсы FE0/0 и FE0/1 принадлежат VPN C3PO Electronic, интерфейсы FE1/0 и FE1/1 — VPN TAR’s Robotics. Внутри одного VPN узлы общаются без проблем, между собой — уже никак.
VRF_Lite.gif!!!
Вот так выглядят их таблицы маршрутизации на провайдерском маршрутизаторе:
45.png!!!
46.png!!!
Маршрутизаторы C3PO Electronic не попадут в сети TARS’ Robotics и наоборот.
Клиентские интерфейсы здесь привязаны к конкретному VRF.
Один интерфейс не может быть членом двух VRF сразу или членом и VRF и глобальной таблицы маршрутизации.
Используя VRF Lite можно легко пробросить VPN между разными концами сети. Для этого нужно настроить одинаковые VRF на всех промежуточных узлах и правильно привязать их к интерфейсам:
VRF_Lite_2.png!!!
То есть 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, где указаны разные VLAN. R2 принимает этот пакет интерфейсом, который также член VRF TARS’s Robotics.
R2 варит пакет в нужном FIB и отправляет дальше, согласно IGP. И так до самого выхода пакета ну другой стороне сети.
Как узел определяет, что полученный пакет относится к определённому VPN? Очень просто: данный интерфейс привязан («прибинден») к конкретному VPN.
Эти интерфейсы помечены колечками соответсвующего цвета:
!!!
Включим немного воображение:
Если пакет проходит через серое колечко, он переходит на серую сторону окрашивается в серый цвет. Далее он будет уже проверяться по серой таблице маршрутизации.
Аналогично, когда пакет проходит через золотое кольцо, он покрывается благородной позолотой и проверяется по золотой таблице маршрутизации.
Точно также выходные интерфейсы привязаны к VPN, и соответствующие таблицы маршрутизации знают, какие за ними сети находятся.
Учитывайте, что всё, что мы говорим о таблицах маршрутизации, касается и FIB — в каждом VPN свой собственный FIB.
Вот он простой и прозрачный VPN — для клиента сформирована самая что ни на есть частная сеть.
VRF_Lite_2.gif!!!
Но этот способ удобен, пока у вас 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 на примере такой сети:
MPLS_VPN_Basic_0.png!!!
Итак, это три филиала нашего клиента TARS’ Robotics: головной офис в Москве и офисы в Новосибирске и Красноярске — весьма удалённые, чтобы дотянуть до них своё оптоволокно. А у нас туда уже есть каналы.
Центральное облако — это мы — linkmeup — провайдер, который предоставляет услугу L3VPN.
Вообще говоря, TARS Robotics как заказчику, совершенно без разницы, как мы организуем L3VPN — да пусть мы хоть на поезде возим их пакеты, лишь бы в SLA укладывались. Но в рамках данной статьи, конечно, внутри нашей сети — MPLS.
Data Plane или передача пользовательских данных
Сначала надо бы сказать, что в MPLS VPN VRF создаётся только на тех маршрутизаторах, куда подключены клиентские сети. В нашем примере это !!!.. Любым промежуточным узлам не нужно ничего знать о VPN.
А между ними нужно как-то обеспечить изолированную передачу пакетов разных VPN.
Вот какой подход предлагает MPLS VPN: коммутация в пределах магистральной сети осуществляется, как мы описывали в предыдущей статье, по одной метке, а принадлежность конкретному VPN определяется другой — дополнительной меткой.
Подробнее:
1) Вот ПК1 из сети 172.16.0.0/24 отправляет пакет на ПК2 в сеть 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 можно через интерфейс GE0/1.
До сих пор это самый обычный пакет, потому что стык идёт по чистому IP с частными адресами.
4) Дальше один из наших маршрутизаторов, а именно R1, получает этот пакет, знает, что он принадлежит определённому VRF (интерфейс привязан к VRF), проверяет таблицу маршрутизации — в какой из филиалов отправить пакет — и инкапсулирует его в пакет MPLS.
Метка MPLS на этом пакете означает как раз его принадлежность определённому VPN. Это называется «Сервисная метка».
5) Далее наш маршрутизатор должен отправить пакет на !!!.. Естественно, по MPLS. Для этого при выходе с R1 на него навешивается транспортная метка MPLS.
Продвижение пакета MPLS по облаку происходит ровно так, как было описано в выпуске про базовый MPLS.
6) R5 в итоге получает пакет, отбрасывает транспортную метку, а по сервисной понимает, что тот принадлежит к VPN TARS’ Robotics.
7) Он снимает все заголовки MPLS и отправляет пакет в интерфейс таким, какой он пришёл на R1 изначально.
На диаграмме железо-углерод видно, как преображается пакет по ходу движения от ПК1 до ПК2:
MPLS_VPN_Basic.gif!!!
Помните, чем хорош MPLS? Тем, что никому нет дела до того, что находится под меткой. Поэтому в пределах магистральной сети не важно, какие адресные пространства у клиента, то есть, какой IP-пакет кроется под заголовком MPLS.
Поскольку пакет коммутируется по меткам, а не маршрутизируется по IP-адресам — нет нужды поддерживать и таблицу маршрутизации VPN на промежуточных узлах.
То есть у нас получается такой удобный MPLS-туннель, который сигнализируется, как вы увидите дальше, автоматически.
Итак, между R1 и R5 (то есть в облаке MPLS) ни у кого нет понимания, что такое VPN – пакеты VPN движутся с метками. Это убирает необходимость поднимать VRF на каждом узле и, соответственно, поддерживать таблицу маршрутизации, FIB, список интерфейсов итд.
Учитывая, что путь пакета определяется на первом маршрутизаторе (R1) отпадает нужда и в дополнительном протоколе маршрутизации, хотя остаётся вопрос, как найти выходной маршрутизатор.
1) Как распределяются метки MPLS?
2) Как распространяется маршрутная информация по каждому VPN?
3) Как VPN изолируются друг от друга?
На эти и другие вопросы отвечаем ниже.
Роль меток MPLS
Если мы вернёмся к изначальной схеме с VRF-Lite, то проблема в том, что серый цвет IP-пакета (индикатор принадлежности к VPN TARS’ Robotics) существует только в пределах узла, при передаче его на другой эта информация потеряется. И если мы откажемся от VRF на промежуточных узлах, начнётся каша.
Чтобы этого не произошло в сценарии с MPLS, Ingress LSR на пакет навешивает специальную метку MPLS — Сервисную — она идентификатор VPN. Egress LSR (второй маршрутизатор) по этой метке понимает, что IP-пакет принаделжит VPN TARS’s Robotics и просматривает соответствующий FIB.
Но на основе сервисной метки пакет не может коммутироваться по MPLS-сети — если мы где-то её поменяем, то Egress LSR не сможет распознать, какому VPN она принадлежит.
И тут на выручку приходит стек меток, который мы так тщательно избегали в прошлом выпуске.
Сервисная метка оказывается внутренней — последней в стеке, а сверху на неё ещё навешивается транспортная.
То есть по сети MPLS пакет путешествует с двумя метками — верхней — транспортной и нижней — сервисной).
Для чего нужно две метки, почему нельзя обойтись одной сервисной? Пусть бы, например, одна метка на Ingress LSR задавал один VPN, другая — другой. Соответственно дальше по пути они бы тоже коммутировались как обычно, и Egress LSR точно знал бы какому VRF нужно передать пакет.
Вообще говоря, сделать так можно было бы, и это бы работало, но тогда в магистральной сети для каждого VPN был бы отдельный LSP. И если, например, у вас идёт пучок в 20 VPN с R1 на R6, то пришлось бы создавать 20 LSP. А это сложнее поддерживать, это перерасход меток, это лишняя нагрузка на транзитные LSR.
Куда ведь проще создать один LSP, который будет туннелировать сразу все 20 VPN?
Транспортная метка
Таким образом, нам необходима транспортная метка. Она верхняя в стеке.
Transport_Label.png!!!
Она определяет LSP и меняется на каждом узле.
Она добавляется Ingress LSR и удаляется Egress LSR (или Penultimate LSR в случае PHP).
Распространением транспортных меток занимаются протоколы LDP и RSVP-TE. Об этом мы тоже очень хорошо поговорили в прошлой статье и не будем останавливаться сейчас.
В целом транспортная метка нам мало интересна, поскольку всё и так уже понятно, за исключением одной детали — FEC.
FEC здесь уже не сеть назначения пакета, а адрес последнего LSR в сети MPLS, куда подключен клиент.
Это очень важно, потому что LSP не в курсе про всякие там VPN, соответственно ничего не знает о их приватных маршрутах/префиксах. Зато он хорошо знает адреса интерфейсов Loopback всех LSR. Так вот на какой именно LSR нужно отправить каждый конкретный пакет, подскажет BGP.
В нашем примере R1, опираясь на адрес назначения клиентского пакета, должен понять, что нужно выбрать тот LSP, который ведёт к R6.
Чуть позже мы ещё вернёмся к этому вопросу.
Сервисная метка
Service_Label.png!!!
Нижняя метка в стеке — сервисная. Она является уникальным идентификатором префикса в конкретном 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’ах:
MPLS_VPN_2VRF.gif!!! гиф
Обратите внимание, что для двух разных VPN отличаются сервисные метки – по ним выходной машрутизатор узнаёт, в какой VRF передавать пакет.
А транспортные в данном случае одинаковые для пакетов обоих VRF, потому что они используют один LSP – R1<->R2<->R3.
Терминология
Пока мы не ушли слишком далеко, надо ввести терминологию.
Когда речь заходит о MPLS VPN, появляется несколько новых терминов, которые, впрочем, вполне очевидны:
CE — Customer Edge router — граничный маршрутизатор клиента, который подключен в сеть провайдера.
PE — Linkmeup Edge router — граничный маршрутизатор провайдера. Собственно к нему и подключаются CE. На PE зарождается VPN, на нём они и кончаются. Именно на нём расположены интерфейсы, привязанные к VPN. Именно PE назначает и снимает сервисные метки. Именно PE являются Ingress LSR и Egress LSR.
То есть по сути это то, что в обычном MPLS мы называли LER — Label Edge Router. PE должны знать таблицы маршрутизации каждого VPN, ведь это они принимают решение о том, куда посылать пакет, как в пределах провайдерской сети, так и в плане клиентских интерфейсов.
P — Linkmeup router — транзитный маршрутизатор, который не является точкой подключения — пакеты VPN проходят через него без каких-либо дополнительных обработок, иными словами просто коммутируются по транспортной метке. P нет нужды знать таблицы маршрутизации VPN или сервисные метки. На P нет интерфейсов привязанных к VPN.
Terms.png!!!
На самом деле роль P-PE индивидуальна для VPN. Если в одном VPN R1 и R6 — это PE, а R2 — P, то в другом они могут поменять свои роли.
CE-PE-P.png!!!
Будет и ещё ряд терминов, но их пока рано вводить.
Протоколы маршрутизации
Итак мы имеет два типа сетей и стыки между ними:
- Клиентская IP-сеть;
- Магистральная сеть провайдера с запущенным на ней MPLS.
Граница этих сетей находится на PE. То есть одной своей половиной он уже клиентский, а другой — провайдерский. Как PE не настраивай, он всё равно на клиентов смотрит.
MPLS настраивается только на магистральных интерфейсах.
IP_MPLS.png!!!
Напоминаю, речь о L3VPN. А тут нужно заботиться о связности. Причём теперь у нас куча ограничений. Разберёмся, какие протоколы на каких участках нам пригодятся.
Во-первых, нужно обеспечить базовую IP-связность внутри магистральной сети провайдера. Чтобы были известны все Loopback-адреса, линковые сети, служебные префиксы, возможно, какие-то выходы вовне.
Для этого запускается IGP.
Уже поверх связной сети поднимается MPLS.
Так мы обеспечили работоспособность магистральной сети.
Во-вторых, у клиента в филиалах может стоять не по одному маршрутизатору, а какие-никакие сети. Эти сети тоже надо маршрутизировать внутри себя как минимум.
Очевидно, что внутри своей собственной сети клиент волен распространять маршрутную информацию, как ему угодно. Мы как провайдер на это повлиять не можем, да нам и без разницы.
Так обеспечивается передача маршрутов в пределах сетей клиентов.
В-третьих, клиенту нужно как-то сообщать своим маршруты провайдеру. На стыке CE-PE клиенту и провайдеру уже нужно договариваться о том, какой протокол будет использоваться.
Хотя, едва ли у клиента какой-то свой самописный протокол IGP. Наверняка, это OSPF/ISIS/RIP. Поэтому обычно провайдер идёт навстречу и выбирает тот, который удобен клиенту.
Тут надо понимать, что вот этот протокол взаимодейтвия с клиентом работает в VPN и никак не пересекается с IGP самого провайдера. Это разные независимые процессы.
На этом стыке вполне может работать и BGP, если клиенту это удобно. Это даже в некотором смысле проще.
Так провайдер получает маршруты клиентов.
До сих пор всё было понятно.
В-четвёртых, и это самое интересное — осталось передать маршруты одного филиала другому через магистральную сеть. При этом их надо по пути не потерять, не перепутать с чужими, доставить в целости и сохранности. Тут нам поможет расширение протокола BGP — MBGP — MultiProtocol BGP. О нём мы сейчас и поговорим.
Но сначала посмотрите, что и где работает:
Routing_Protocols.png!!!
Может, на примере из реальной жизни будет немного понятнее.
Допустим, вы живёте в посёлке Ола и решили отдохнуть в Шеньчжене.
1) На своих двоих, на машине или на такси вы добираетесь до автовокзала (IGP внутри сети).
2) Садитесь на автобус, и он довозит вас до Магадана (IGP/BGP с провайдером).
3) В Магадане вам туроператор выдаёт ваши загранпаспорта, билеты и ваучер (внутренняя мервисная метка). Теперь вы стали членом определённого рейса (VPN).
4) В аэропорту всем без разницы, в какую гостиницу вы в итоге едете — их задача доставить вас в Шеньчжень (BGP), а для этого нужно посадить вас на правильный самолёт согласно вашему ваучеру (назначить внешнюю транспортную метку и отправить в правильный интерфейс)
Итак, вы сели в самолёт. Этот самолёт является вашей внешней транспортной меткой, а ваучер — сервисной. Самолёт доставит вас до следующего хопа, а ваучер до гостиницы.
5) Самолёт летит из Магадана в Шеньчжень не напрямую, а с пересадками. Сначала вы вышли в Москве, пересели в новый самолёт до Пекина. Потом в Пекине вы пересели на самолёт уже до Шеньчженя. (Так прозошла коммутация по меткам). При этом ваучер — сервисная метка по-прежнему у вас в кармане.
6) В Шеньчжене вы вышли из самолёта (Pop Label) и уже тут проверят ваш ваучер — а куда вас собственно нужно везти (в какой VPN).
7) Вас садят в автобус до вашей гостиницы (IGP/BGP с провайдером).
8) Во дворе гостиницы вы самостоятельно находите дорогу до номера, через ресепшн (IGP внутри сети).
Итак, аэропорт Магадана — это PE/Ingress LSR, аэропорт Шеньчженя — это другой PE/Egress LSR, аэропорт Москвы — P/Intermediate LSR.
MBGP
Сейчас ответим на два вопроса: как маршруты передаются в провайдерской сети от одного PE к другому и как обеспечивается изоляция.
В общем-то до сих пор не придумано ничего лучше для передачи маршрутов на удалённые узлы, чем BGP: и гибкость передачи самих маршрутов, и масса инструментов по влиянию на выбор маршрута, и политики получения и передачи маршрутов, и Community, сильно упрощающие групповые действия над маршрутами.
Если вдруг вы забыли, тот вот обычное сообщение BGP Update:
!!!
В секции NLRI оно переносит информацию о маршруте. А в других секциях масса параметров этого маршрута.
К его помощи и прибегают при реализации MPLS L3VPN. Поэтому его часто называют MPLS BGP VPN.
Вы ведь помните, как это происходит? BGP устанавливает сессию со своими соседями через TCP на порт 179. Это позволяет в качестве соседей выбирать не непосредственно подключенного соседа, а маршрутизаторы, находящиеся в нескольких хопах. Так и работает IBGP, где в пределах магистральной сети предполагается связь «каждый с каждым».
Когда несколько маршрутов, ведущих в одну сеть, приходят на узел, BGP просто выбирает из них лучший и инсталлирует его в таблицу маршрутизации.
То есть в целом нам ничего не стоит передать маршрут VPN через сеть на другой её конец.
BGP должен взять маршруты из VRF на одном узле, доставить их на другой и там экспортировать в правильный VRF.
Только дело в том, что BGP изначально ориентирован на работу с публичными адресами, которые предполагаются уникальными во всём мире. А клиенты-негодяи обычно хотят передавать маршруты в частные сети (RFC1918) и как назло они запросто могут пересекаться как с сетями других VPN, так и со внутренним адресным пространством самого провайдера.
То есть, если, например, R3 получит два маршрута в сеть 10.0.0.0 (один от TARS’s Robotics, другой от C3PO Electronic), он выберет только один — с лучшими показателями, как предписывает стандарт — он думает, что это два маршрута в одну и ту же сеть.
MPLS_2_Prefixes!!!
Естественно, нам это не подходит. Нужно, чтобы выполнялось два условия:
1) Маршруты разных VPN были уникальными и не смешивались при передаче между PE.
2) Маршруты в конечной точке должны быть переданы правильному VRF.
Этим проблемам было найдено элегантное решение. Начнём с п.1 — уникальность маршрутов.
В нашем примере 10.0.0.0/32 от TARS’s Robotics должны чем-то отличаться от 10.0.0.0/32 же от C3PO Electronic.
BGP невероятно гибкий протокол (не зря ведь он стал единственным протоколом внешнего шлюза). Он легко масшатбируется и с помощью так называемых Address Family он может передавать маршруты IPv6 и IPX. Хочешь передать что-то новое — заведи свою Address Family,
И создал бог IETF новый Address Family. И дал он имя ему VPNv4 (или VPN-IPv4).
Для того, чтобы различать маршруты различных VPN, обычный IPv4 префикс дополняется специальной приставкой длиной 8 байтов — RD — Route Distinguisher.
Существует 3 типа RD:
Картинка с сайта http://packetlife.net.
Первая часть — сам тип (0, 1 или 2);
Вторая часть — Административное поле (Administrator field) — это всегда публичный параметр — публичный IP-адрес или публичный номер AS. Она необходима для того, чтобы ваши RD были уникальны не только в пределах сети но и в пределах планеты.
То есть в Административной части не должен появиться случайно IP адрес 172.16.127.2 или AS 65001. Это может пригодиться в том случае, когда VPN нужно передать в сеть другого провайдера (Inter-AS VPN).
Третья часть — Выделенный номер (Assigned Number) — это уже то, что назначаете вы. Эта часть позволяет RD быть уникальным в пределах вашей сети.
Как видите, RD уникальны в пределах планеты.
Вот два примера преобразования обычного IPv4-префикса 10.0.0.0/24 в VPNv4:
0:64500:100:10.0.0.0/24
1:100.0.0.1:100:10.0.0.0/24.Какой выберете вы не имеет значения, даже если в пределах сети вы будете испольовать оба подхода одновременно. RD главное разделить префиксы.
Обычно используют, тип — 0, Административное поле — это номер AS, а Выделенный номер вы выбираете самостоятельно. При настройке RD первый «0:» сокращается и получается так: 64500:100.
Cisco позволяет использовать типы 0 и 1.
Да, RD придётся настроить вручную и самому следить за его уникальностью. Но по-другому тут и не получится — сами маршрутизаторы не умеют отслеживать, есть ли на других узлах уже такой RD или нет.
И что же у нас получается?
1) Пришёл от CE анонс новой сети. Пусть это будет 10.0.0.0/32, как мы и договаривались. PE добавил этот маршрут в таблицу маршрутизации конкретного VRF. Заметьте, что в таблице маршрутизации хранится обычный IPv4 маршрут — никаких VPNv4. А это и не нужно: VRF изолированы друг от друга, как мы уже говорили раньше — это виртуальный маршрутизатор.
2) BGP заметил, что появился новый префикс в VPN. Из конфигурации VRF он нашёл какой RD нужно использовать. Скомпилировал из RD и нового IPv4-префикса, VPNv4-префикс. Получилось так:
C3PO: 64500:100:10.0.0.0/32
TARS: 64500:200:10.0.0.0/32
3) Создавая BGP Update, маршрутизатор вставляет туда полученный VPNv4-префикс и прочие атрибуты BGP. Но кроме всего прочего, он добавляет в поле NLRI информацию о метке. Эта метка привязана к маршруту, или точнее говоря, VPNv4-префикс — это FEC, а в NLRI передаётся связка данного FEC и метки.
По-английски это называется Labeled Route — по-русски, пожалуй, маршрут, снабжённый меткой. Так данный PE уведомляет своих соседей, что если те получили от CE IP-пакет в эту сеть, ему нужно назначить такую сервисную метку.
!!!
4) Дальше BGP Update передаётся всем соседям, настроенным в секции VPNv4 family. Передаётся он самым обычным образом, как и любое другое BGP-сообщение.
!!!
* Сообщение тоже передаётся по MPLS.
5) Удалённый PE получает этот Update, видит в NLRI, что это не обычный IPv4 маршрут, а VPNv4. Помните, да, если придёт два маршрута в одну сеть от разных клиентов — они не перепутаются, потому что разные RD. Далее Egress PE определяет, в какой VRF этот маршрут нужно экспортировать и, собственно, делает это. Так маршрут появляется в таблице маршрутизации и FIB нужного VRF, а оттуда уходит в сеть клиента.
Теперь, когда PE получает от CE пакет, который следует в сеть 10.0.0.0\32 в FIB этого VPN он находит сервисную метку и Next-Hop. Инкапсулирует IP в MPLS, дальше ищет в уже глобальном FIB транспортную метку для Next Hop.
То есть транспортная метка как и прежде доставляется протоколами LDP или RSVP-TE, а сервисная — MBGP.
Сравните поле NLRI в обычном BGP и в MP-BGP.
!!!
RD.gif!!!
Я ведь не зря выделил фразу «определяет, в какой VRF этот маршрут нужно экспортировать» курсивом. За этой простотой скрывается ещё одна вещь — RT — Route Target.
Дело в том, что единственная роль RD — разнообразить жизнь BGP, то есть сделать маршруты уникальными. Несмотря на то, что он настраивается для VRF, он не является каким-то его уникальными идентификатором и на всех точках подключения это значение может быть даже разным. Поэтому PE не может определить в какой VRF засунуть маршрут на основе RD.
Да и это было бы не совсем в традициях BGP — разбирать переданный адрес, анализировать его перед тем, как куда-то анонсировать. Для этих целей у нас есть политики.
То есть в классическом BGP, пришлось бы вешать политики на экспорт маршрутов в VRF для каждого отдельно. И мы бы вручную отфильтровывали куда нужно пристроить каждый маршрут.
Один шаг в сторону упрощения — использование community. При отправке маршрута с одного PE на другой можно устанавливать определённый community — свой для каждого VRF, а на удалённой по этому community уже настраивать экспорт в соответствующий VRF.
В MBGP зашли ещё немного дальше — идею community развили до понятия Route Target. По сути, это то же community — RT даже передаётся в атрибуте Extended Community, только все политики работают автоматически.
Формат RT, точно такой же, как у обычного Extended Community. Например:
64500:100
То есть он похож на первый тип RD. Отчасти поэтому RD и RT так часто путают.
На одной стороне в VRF настраивается RT на экспорт маршрута — тот RT, с которым он будет путешествовать к удалённому PE. На другой именно это же значение RT устанавливается на импорт. И наоборот.
Обычно, если задача — просто организовать услугу VPN для одного клиента, то RT на экспорт и на импорт совпадают на всех точках подключения.
Возвращаясь к нашему примеру:
R1 посылает R6 маршрут к сети 10.0.0.0/32 (TARS’ Robotics), указывает метку и всяческие другие параметры, и в числе прочего в атрибут Extended Community он записывает RT на экспорт маршрута, который настроен для данного VRF: 64500:200.
R6 получает этот анонс, проверят community, видит 64500:200, а из конфигурации он знает, что маршруты с этим RT нужно импортировать в VRF TARS’ Robotics.
Красиво? Элегантно? Но это ещё не всё. Гибкость BGP и здесь проявляется в очередной раз. С помощью механизма RT вы можете импортировать маршруты как вам заблагорассудится как в пределах одного VPN, так и между различными VPN.
Вот вам два сценария:
1) Клиент хочет организовать топологию звезда, а не каждый с каждым. То есть центральная точка должна знать маршруты во все точки подключения, а вот те должны знать только маршруты до центра. Таким образом, любые взаимодействия между разделёнными клиентскими сетями будут осуществляться через центральный узел. Без всяких действий со стороны клиента — удобно же!
Решение: У каждого филиала — свой RT на экспорт. В филиалах RT на импорт равен RT на экспорт, настроенный на центральном узле — то есть они могут получать маршруты от центра. При этом на импорт нет RT других филиалов — соответственно напрямую их маршруты они не видят. Зато в центре на импорт настроены RT всех филиалов, то есть он будет получать всё-всё-всё.
2) Допустим, помимо наших двух VPN появился третий — Local Robotics Alliance. У них есть какие-то свои задача, но ещё они поддерживают сервера с прошивками для микропроцессоров, шаблонами, дополнительными модулями итд, которые необходимы TARS’ Robotics и C3PO Electronic. При этом они не хотят светить в мир своими серверами, а для клиентов обеспечить доступ через сеть провайдера.
И тогда с помощью RT можно обеспечить взаимодействие между различными VPN. Для этого в TARS’ Robotics и в C3PO Electronic мы настраиваем такой RT на импорт, который в VPN Local Robotics Alliance был указан на экспорт. И, соответственно, наоборот.
Правда в этом случае нужно следить за тем, не пересекаются ли используемые подсети. Ведь несмотря на все RD и RT, BGP выберет только один маршрут в каждую подсеть в VRF.
RT.gif!!!
Routing.gif!!!
Практика
Традиционно на практике повторим всё то, что было до сих пор в теории.
VRF-Lite
Так и пойдём от простого к сложному. Начнём с ситуации, когда один клиент имеет два подключения в один маршрутизатор:
Practice_VRF_Lite_1.png!!!
Сначала попробуем настроить всё так, как мы делали это раньше:
Linkmeup
Linkmeup(config)# interface FastEthernet0/0
Linkmeup(config-if)# description To C3PO_1
Linkmeup(config-if)# ip address 192.168.0.1 255.255.255.0
Linkmeup(config)# interface FastEthernet0/1
Linkmeup(config-if)# description To C3PO_2
Linkmeup(config-if)# ip address 192.168.1.1 255.255.255.0
C3PO_1
C3PO_1(config)# interface FastEthernet0/0
C3PO_1(config-if)# description To Linkmeup
C3PO_1(config-if)# ip address 192.168.0.2 255.255.255.0
C3PO_1(config)#ip route 0.0.0.0 0.0.0.0 192.168.0.1
C3PO_2
C3PO_1(config)# interface FastEthernet0/0
C3PO_1(config-if)# description To Linkmeup
C3PO_1(config-if)# ip address 192.168.1.2 255.255.255.0
C3PO_1(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.1
!!!
Пинг между филиалами появляется — они друг друга видят. 
47.png!!!
Но при этом они видят и, например, адрес Loopback R1:
48.png!!!
Соответственно, они видят всю сеть провайдера и будут видеть сети других клиентов.
Поэтому настраиваем VRF:
Linkmeup(config)#ip vrf C3O
Чтобы в этот VRF поместить клиентов, нужно их интерфейсы привязать к VRF:
Linkmeup(config)# interface FastEthernet0/0
Linkmeup(config-if)# ip vrf forwarding C3PO
% Interface FastEthernet0/0 IP address 192.168.0.1 removed due to enabling VRF C3PO
Обратите внимание, что после выполнения команды ip vrf forwarding C3PO, IOS удалил IP-адреса с интерфейсов, теперь их нужно настроить повторно. Это произошло для того, чтобы удалить указанные подсети из глобальной таблицы маршрутизации.
Linkmeup(config)# interface FastEthernet0/0
Linkmeup(config-if)# ip address 192.168.0.1 255.255.255.0
Linkmeup(config-if)#interface FastEthernet0/1
Linkmeup(config-if)# ip vrf forwarding C3PO
% Interface FastEthernet0/0 IP address 192.168.1.1 removed due to enabling VRF C3PO
Linkmeup(config-if)# ip address 192.168.1.1 255.255.255.0
После повторной настройки адреса эти подсети появятся уже в таблице маршрутизации VRF.
49.png!!!
Проверяем снова пинг:
50.png!!!
51.png!!!
Аналогичные настройки нужно сделать и для клиента TARS:
Linkmeup(config)#ip vrf TARS
Linkmeup(config-if)#interface FastEthernet1/0
Linkmeup(config-if)# ip vrf forwarding TARS
Linkmeup(config-if)# ip address 172.16.0.1 255.255.255.0
Linkmeup(config-if)#interface FastEthernet1/1
Linkmeup(config-if)# ip vrf forwarding TARS
Linkmeup(config-if)# ip address 172.16.1.1 255.255.255.0
Вот и славно. VRF TARS и C3PO полностью изолированы от сети провайдера и друг от друга:
52.png!!!
53.png!!!
54.png!!!
Теперь растягиваем удовольствие на сеть linkmeup:
Practice_VRF_Lite_2.png!!!
Первый шаг настройки — создать VRF на каждом узле от R1 до R3:
Linkmeup_R1(config)# ip vrf C3PO
Linkmeup_R1(config)# ip vrf TARS
Linkmeup_R2(config)# ip vrf C3PO
Linkmeup_R2(config)# ip vrf TARS
Linkmeup_R3(config)# ip vrf C3PO
Linkmeup_R3(config)# ip vrf TARS
* Следует понимать, что VRF — это локальное понятие. Вполне можно устанавливать разные имена VRF на разных маршрутизаторах.
Второй шаг — создать цепочку линковых сетей между всеми узлами и привязать каждую пару интерфейсов к нужному VRF.
Мы не стали указывать на схеме линковые адреса, чтобы не загромождать её. Для порядку выберем префиксы 10.0/16 для собственно сети провайдера (VLAN1), 192.168/16 для C3PO Electronic (Vlan 2) и 172.16/16 для TARS’ Robotics (Vlan 3).
Linkmeup_R1:
Linkmeup_R1(config-if)#interface FastEthernet0/0
Linkmeup_R1(config-if)# description To C3PO_Electronic_1
Linkmeup_R1(config-if)# ip vrf forwarding C3PO
Linkmeup_R1(config-if)# ip address 192.168.0.1 255.255.255.0
Linkmeup_R1(config-if)#interface FastEthernet0/1
Linkmeup_R1(config-if)# description To Linkmeup_R2
Linkmeup_R1(config-if)# ip address 10.0.12.1 255.255.255.0
Linkmeup_R1(config-if)#interface FastEthernet0/1.2
Linkmeup_R1(config-subif)# description to Linkmeup_R2_vrf_C3PO
Linkmeup_R1(config-subif)# encapsulation dot1Q 2
Linkmeup_R1(config-subif)# ip vrf forwarding C3PO
Linkmeup_R1(config-subif)# ip address 192.168.12.1 255.255.255.0
Linkmeup_R1(config-subif)#interface FastEthernet0/1.3
Linkmeup_R1(config-subif)# description To Linkmeup_R2_in_TARS
Linkmeup_R1(config-subif)# encapsulation dot1Q 3
Linkmeup_R1(config-subif)# ip vrf forwarding TARS
Linkmeup_R1(config-subif)# ip address 172.16.12.1 255.255.255.0
Linkmeup_R1(config-subif)#interface FastEthernet1/0
Linkmeup_R1(config-if)# description To TASR_1
Linkmeup_R1(config-if)# ip vrf forwarding TARS
Linkmeup_R1(config-if)# ip address 172.16.0.1 255.255.255.0
Linkmeup_R2:
Linkmeup_R2(config)#interface FastEthernet0/0
Linkmeup_R2(config-if)# description To Linkmeup_R1
Linkmeup_R2(config-if)# ip address 10.0.12.2 255.255.255.0
Linkmeup_R2(config-if)#interface FastEthernet0/0.2
Linkmeup_R2(config-subif)# description To Linkmeup_R1_vrf_C3PO
Linkmeup_R2(config-subif)# encapsulation dot1Q 2
Linkmeup_R2(config-subif)# ip vrf forwarding C3PO
Linkmeup_R2(config-subif)# ip address 192.168.12.2 255.255.255.0
Linkmeup_R2(config-subif)#interface FastEthernet0/0.3
Linkmeup_R2(config-subif)# description To Linkmeup_R1_vrf_TARS
Linkmeup_R2(config-subif)# encapsulation dot1Q 3
Linkmeup_R2(config-subif)# ip vrf forwarding TARS
Linkmeup_R2(config-subif)# ip address 172.16.12.2 255.255.255.0
Linkmeup_R2(config-subif)#interface FastEthernet0/1
Linkmeup_R2(config-if)# description To Linkmeup_R3
Linkmeup_R2(config-if)# ip address 10.0.23.2 255.255.255.0
Linkmeup_R2(config-if)#interface FastEthernet0/1.2
Linkmeup_R2(config-subif)# description To Linkmeup_R3_vrf_C3PO
Linkmeup_R2(config-subif)# encapsulation dot1Q 2
Linkmeup_R2(config-subif)# ip vrf forwarding C3PO
Linkmeup_R2(config-subif)# ip address 192.168.23.2 255.255.255.0
Linkmeup_R2(config-subif)#interface FastEthernet0/1.3
Linkmeup_R2(config-subif)# description To Linkmeup_R3_vrf_TARS
Linkmeup_R2(config-subif)# encapsulation dot1Q 3
Linkmeup_R2(config-subif)# ip vrf forwarding TARS
Linkmeup_R2(config-subif)# ip address 172.16.23.2 255.255.255.0
Linkmeup_R3:
Linkmeup_R3(config)#interface FastEthernet0/0
Linkmeup_R3(config-if)# description To Linkmeup_R2
Linkmeup_R3(config-if)# ip address 10.0.23.3 255.255.255.0
Linkmeup_R3(config-if)#interface FastEthernet0/0.2
Linkmeup_R3(config-subif)# description To Linkmeup_R2_vrf_C3PO
Linkmeup_R3(config-subif)# encapsulation dot1Q 2
Linkmeup_R3(config-subif)# ip vrf forwarding C3PO
Linkmeup_R3(config-subif)# ip address 192.168.23.3 255.255.255.0
Linkmeup_R3(config-subif)#interface FastEthernet0/0.3
Linkmeup_R3(config-subif)# description To Linkmeup_R2_vrf_TARS
Linkmeup_R3(config-subif)# encapsulation dot1Q 3
Linkmeup_R3(config-subif)# ip vrf forwarding TARS
Linkmeup_R3(config-subif)# ip address 172.16.23.3 255.255.255.0
Linkmeup_R3(config-subif)#interface FastEthernet0/1
Linkmeup_R3(config-if)# description To C3PO_2
Linkmeup_R3(config-if)# ip vrf forwarding C3PO
Linkmeup_R3(config-if)# ip address 192.168.1.1 255.255.255.0
Linkmeup_R3(config-if)#interface FastEthernet1/0
Linkmeup_R3(config-if)# description To TARS_2
Linkmeup_R3(config-if)# ip vrf forwarding TARS
Linkmeup_R3(config-if)# ip address 172.16.1.1 255.255.255.0
Третий — поднять IGP в VRF.
Linkmeup_R1:
Linkmeup_R1(config-router)#router ospf 2 vrf C3PO
Linkmeup_R1(config-router)# network 192.168.0.0 0.0.255.255 area 0
Linkmeup_R1(config)#router ospf 3 vrf TARS
Linkmeup_R1(config-router)# network 172.16.0.0 0.0.255.255 area 0
Linkmeup_R1(config-router)#router isis 1
Linkmeup_R1(config-router)# net 10.0000.0000.0001.00
Linkmeup_R1(config)#interface FastEthernet0/1
Linkmeup_R1(config-if)# ip router isis 1
Linkmeup_R2:
Linkmeup_R2(config-router)#router ospf 2 vrf C3PO
Linkmeup_R2(config-router)# network 192.168.0.0 0.0.255.255 area 0
Linkmeup_R2(config)#router ospf 3 vrf TARS
Linkmeup_R2(config-router)# network 172.16.0.0 0.0.255.255 area 0
Linkmeup_R2(config-router)#router isis 1
Linkmeup_R2(config-router)# net 10.0000.0000.0001.00
Linkmeup_R2(config)#interface FastEthernet0/0
Linkmeup_R2(config-if)# ip router isis 1
Linkmeup_R2(config)#interface FastEthernet0/1
Linkmeup_R2(config-if)# ip router isis 1
Linkmeup_R1:
Linkmeup_R3(config-router)#router ospf 2 vrf C3PO
Linkmeup_R3(config-router)# network 192.168.0.0 0.0.255.255 area 0
Linkmeup_R3(config)#router ospf 3 vrf TARS
Linkmeup_R3(config-router)# network 172.16.0.0 0.0.255.255 area 0
Linkmeup_R3(config-router)#router isis 1
Linkmeup_R3(config-router)# net 10.0000.0000.0001.00
Linkmeup_R3(config)#interface FastEthernet0/0
Linkmeup_R3(config-if)# ip router isis 1
ISIS для связности внутренней сети провайдера, OSPF для VRF.
OSPF поднимается и с клиентами, чтобы они изучали маршруты динамически. Соответственно, в них должна быть конструкция вроде этой:router ospf 1
network 192.168.0.0 0.0.255.255 area 0
Собственно всё. Теперь каждая сеть знает свои маршруты:
55.png!!!
56.png!!!
В принципе, на базе одной физической сети мы создали 3 абсолютно самостоятельных виртуальных сети, внутри которых можно делать практически всё, что угодно — хоть MPLS поднимать.
Но, как и было сказано раньше — это очень инертное решение, поэтому переходим к MPLS BGP VPN.
MPLS L3VPN
Я предлагаю в этот раз не брать уже готовую сеть, где уже всё преднастроено. Сейчас интереснее будет пройти этот путь с нуля, пусть и только вехами, не вдаваясь в детали.
Итак, мучаем всё ту же сеть:
Practice_MPLS_VPN_Basic_0.png!!!
Поменять картинку
Начнём с одного клиента и двух точек подключения.
Клиентские маршрутизаторы имеют очень простую конфигурацию:
C3PO_1:
interface Loopback0
ip address 192.168.255.1 255.255.255.255
!
interface FastEthernet0/0
description To Linkmeup
ip address 192.168.0.2 255.255.255.0
!
router ospf 1
network 192.168.0.0 0.0.255.255 area 0
C3PO_2:
interface Loopback0
ip address 192.168.255.2 255.255.255.255
!
interface FastEthernet0/0
description To Linkmeup
ip address 192.168.1.2 255.255.255.0
!
router ospf 1
network 192.168.0.0 0.0.255.255 area 0
Настроены линковые адреса с провайдером и инетрфейс Loopback (как и прежде, мы используем этот интерфейс, чтобы имитировать сеть, дабы не плодить маршрутизаторы). То есть если на C3PO_2 мы увидим сеть 192.168.255.1/32, это значит, что мы увидели бы и всю сеть полностью.
В качестве локального протокола динамической маршрутизации используется OSPF. Собственно, именно он позволит сообщить адрес Loopback-интерфейса всем заинтересованным.
Что же касается сети провайдера:
1) Настроены IP-адреса: линковые и loopback, клиентские пока не трогаем.
Linkmeup_R1:
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/1
description To Linkmeup_R2
ip address 10.0.12.1 255.255.255.0
Linkmeup_R2:
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
description To Linkmeup_R1
ip address 10.0.12.2 255.255.255.0
!
interface FastEthernet0/1
description To Linkmeup_R3
ip address 10.0.23.2 255.255.255.0
Linkmeup_R3:
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
description To Linkmeup_R2
ip address 10.0.23.3 255.255.255.0
Файл начальной конфигурации.
2) Теперь поднимаем ISIS в качестве IGP — он свяжет всю сеть linkmeup, распространив маршрутную информацию о линковых и Loopback-адресах.
Linkmeup_R1:
Linkmeup_R1(config)# router isis 1
Linkmeup_R1(config-router)# net 10.0000.0000.0001.00
Linkmeup_R1(config)# interface FastEthernet 0/1
Linkmeup_R1(config-if)# ip router isis 1
Linkmeup_R2:
Linkmeup_R2(config)# router isis 1
Linkmeup_R2(config-router)# net 10.0000.0000.0002.00
Linkmeup_R2(config)# interface FastEthernet 0/0
Linkmeup_R2(config-if)# ip router isis 1
Linkmeup_R2(config)# interface FastEthernet 0/1
Linkmeup_R2(config-if)# ip router isis 1
Linkmeup_R3:
Linkmeup_R3(config)# router isis 1
Linkmeup_R3(config-router)# net 10.0000.0000.0002.00
Linkmeup_R3(config)# interface FastEthernet 0/0
Linkmeup_R3(config-if)# ip router isis 1
На этом шаге получили глобальную таблицу маршрутизации — необходимая платформа для следующего шага.
1.png!!!
3) Включаем MPLS и LDP:
Linkmeup_R1:
Linkmeup_R1(config)#mpls ip
Linkmeup_R1(config)#interface FastEthernet 0/1
Linkmeup_R1(config-if)#mpls ip
Linkmeup_R2:
Linkmeup_R2(config)#mpls ip
Linkmeup_R2(config)#interface FastEthernet 0/0
Linkmeup_R2(config-if)#mpls ip
Linkmeup_R2(config)#interface FastEthernet 0/1
Linkmeup_R2(config-if)#mpls ip
Linkmeup_R3:
Linkmeup_R3(config)#mpls ip
Linkmeup_R3(config)#interface FastEthernet 0/0
Linkmeup_R3(config-if)#mpls ip
На этом шаге у нас построены LSP между всеми парами LSR:
2.png!!!
*Пример выделения меток на Linkmeup_R1.
Это базис для VPN. Эти LSP — это набор транспортных меток.
Мы выбрали здесь LDP, чтобы не усложнять конфигурацию. С RSVP-TE ещё поразбираемся в статье про Traffic Engineering.
4) Создаём VRF на двух узлах: Linkmeup_R1 и Linkmeup_R3.
Linkmeup_R1:
Linkmeup_R1(config)#ip vrf C3PO
Linkmeup_R1(config-vrf)# rd 64500:100
Linkmeup_R1(config-vrf)# route-target both 64500:100
Linkmeup_R3:
Linkmeup_R3(config)#ip vrf C3PO
Linkmeup_R3(config-vrf)# rd 64500:100
Linkmeup_R3(config-vrf)# route-target both 64500:100
Это позволяет нам обособить все данные клиента от других клиентов и от сети самого провайдера.
Здесь же указываем RD и RT. Поскольку задача у нас простая — связать все филиалы C3PO Electronic, то сделаем RD и RT совпадающими. Причём RT на import и RT на Export тоже будут одинаковыми. Поскольку это обычная практика, существует даже специальная директива — both — тогда создаются оба RT сразу одинаковыми.
В 8-м выпуске мы выбрали номер AS для сети linkmeup — 64500. Он и используется в качестве административного поля.
Выделенный номер выбирается произвольно, но отслеживается, чтобы не было совпадения с другим, уже использованным.
5) Привязываем интерфейсы к VRF и указываем на них IP-адреса.
Linkmeup_R1:
Linkmeup_R1(config)#interface FastEthernet0/0
Linkmeup_R1(config-if)# description To C3PO_Electronic_1
Linkmeup_R1(config-if)# ip vrf forwarding C3PO
Linkmeup_R1(config-if)#ip address 192.168.0.1 255.255.255.0
Linkmeup_R3:
Linkmeup_R3(config)#interface FastEthernet0/1
Linkmeup_R3(config-if)# description To C3PO_Electronic_2
Linkmeup_R3(config-if)# ip vrf forwarding C3PO
Linkmeup_R3(config-if)#ip address 192.168.1.1 255.255.255.0
В таблицах маршрутизации VRF C3PO должны появиться настроенные сети, как Directly connected.
3.png!!!
4.png!!!
6) Нужно поднять протокол маршрутизации с клиентом. В нашем случае это будет OSPF, хотя с равным успехом это мог бы быть и ISIS. Данный процесс никак не должен пересекаться с глобальной таблицей маршрутизации, поэтому помещаем его в VRF:
Linkmeup_R1:
Linkmeup_R1(config)#router ospf 2 vrf C3PO
Linkmeup_R1(config-router)# network 192.168.0.0 0.0.255.255 area 0
Linkmeup_R3:
Linkmeup_R3(config)#router ospf 2 vrf C3PO
Linkmeup_R3(config-router)# network 192.168.0.0 0.0.255.255 area 0
Учитывая, что у клиента OSPF уже настроен, мы должны увидеть адреса Loopback-интерфейсов в таблице маршрутизации.
5.png!!!
6.png!!!
Как видите, Linkmeup_R1 видит 192.168.255.1, но не видит удалённый Loopback – 192.168.255.2. Аналогично и Linkmeup_R2 видит только маршруты со своей стороны. Это потому, что через сеть провайдера пока не передаются маршруты клиента.
7) Вот и пришло время MBGP.
Помните, мы говорили о BGP Free Core в прошлом выпуске. Этот приём мы вполне можем использовать и здесь. Нам без надобности BGP на Linkmeup_R2 — там и не будем его поднимать.
!!!
Первая часть — это базовая настройка соседей iBGP.
Linkmeup_R1:
Linkmeup_R1(config)#router bgp 64500
Linkmeup_R1(config-router)# neighbor 3.3.3.3 remote-as 64500
Linkmeup_R1(config-router)# neighbor 3.3.3.3 update-source Loopback0
Linkmeup_R3:
Linkmeup_R3(config)#router bgp 64500
Linkmeup_R3(config-router)# neighbor 1.1.1.1 remote-as 64500
Linkmeup_R3(config-router)# neighbor 1.1.1.1 update-source Loopback0
Вторая часть — настройка Address Family VPNv4 — это то, что позволит с Linkmeup_R1 на Linkmeup_R3 передать клиентские маршруты. Заметьте, что мы активировали передачу community, потому что этот атрибут используется RT.
Linkmeup_R1:
Linkmeup_R1(config-router)# address-family vpnv4
Linkmeup_R1(config-router-af)# neighbor 3.3.3.3 activate
Linkmeup_R1(config-router-af)# neighbor 3.3.3.3 send-community both
Linkmeup_R3:
Linkmeup_R3(config-router)# address-family vpnv4
Linkmeup_R3(config-router-af)# neighbor 1.1.1.1 activate
Linkmeup_R3(config-router-af)# neighbor 1.1.1.1 send-community both
Третья часть — это Address Family для данного конкретного VRF. Он работает с обычными IPv4 префиксами, но из VRF C3PO Electronic. Он нужен для того, чтобы передавать маршруты между MBGP и OSPF.
Linkmeup_R1:
Linkmeup_R1(config-router)# address-family ipv4 vrf C3PO
Linkmeup_R1(config-router-af)# redistribute ospf 2 vrf C3PO
Linkmeup_R3:
Linkmeup_R3(config-router)# address-family ipv4 vrf C3PO
Linkmeup_R3(config-router-af)# redistribute ospf 2 vrf C3PO
Как видите здесь настроен импорт маршрутов из процесса OSPF с номером 2.
Соответственно, нужно настроить и импорт маршрутов в OSPF из BGP:
Linkmeup_R1:
Linkmeup_R1(config)#router ospf 2
Linkmeup_R1(config-router)# redistribute bgp 64500 subnets
Linkmeup_R3:
Linkmeup_R3(config)#router ospf 2
Linkmeup_R3(config-router)# redistribute bgp 64500 subnets
И вот теперь всё завертится, закрутится.
Маршруты на PE
7.png!!!
8.png!!!
Маршруты на CE
9.png!!!
Пинг между клиентскими сетями.
10.png!!!
Попытка пинга провайдерской сети.
11.PNG!!!
Теперь подключим клиента TAR’S Robotics. Маршруты между CE и PE будут передаваться по BGP или, иными словами поднимаем EBGP с клиентским маршрутизатором.
Шаги 4 и 5 не будут отличаться, приведём конфигурацию только одной стороны:
ip vrf TARS
rd 64500:200
route-target export 64500:200
route-target import 64500:200
interface FastEthernet1/0
description To TARS_1
ip vrf forwarding TARS
ip address 172.16.0.1 255.255.255.0
6) На CE EBGP настраивается самым обычным образом.
TARS_1:
TARS_1(config)#router bgp 64501
TARS_1(config-router)# network 172.16.255.1 mask 255.255.255.255
TARS_1(config-router)# neighbor 100.0.0.1 remote-as 64500
Здесь указано, что TARS’ Robotics будет анонсировать свою сеть 172.16.255.1/32.
OSPF по-прежнему может быть нужен, но он уже будет использоваться для маршрутизации внутри этого филиала и только.
На PE всё то же самое, только удаляется процесс OSPF 3 (потому что с клиентом теперь EBGP, вместо OSPF) и меняется address family ipv4 vrf TARS:
Linkmeup_R1:
Linkmeup_R1(config-router)# address-family ipv4 vrf TARS
Linkmeup_R1(config-router-af)# redistribute connected
Linkmeup_R1(config-router-af)# neighbor 100.0.0.2 remote-as 64501
Linkmeup_R1(config-router-af)# neighbor 100.0.0.2 activate
Вместо импорта из OSPF используется импорт подключенных сетей. Это нужно для того, чтобы в таблице маршрутизации данного VRF были линковые сети. Их мог бы прописать и клиент в своей секции BGP, а мог бы и не прописать, поэтому лучше это сделаем мы.
Кроме того, добавилось полноценное соседство в VRF с клиентом, которого не было в предыдщем случае.
Теперь Linkmeup_R1 является соседом TARS_1:
12.png!!!
7) Всё, что касается MBGP — то же самое. От того, что мы поменяли протокол взаимодействия с клиентом, в нём ничего не перевернётся.
То есть уже сейчас всё должно заработать:
13.png!!!
14.png!!!
15.png!!!
Полная конфигурация всех узлов с комментариями и без
Давайте теперь проследим распространение меток
BGP_Update_message.png!!!
Вот, что передал Linkmeup_R1 узлу Linkmeup_R3. Вы видите здесь метку 22 для FEC 192.168.255.1.
Как её понимает маршрутизатор?
16.png!!!
Вот она метка 22.
Вот она видна и в таблице BGP:
17.png!!!
А что такое 17 в записи {17 22}? А это ни что иное, как транспортная метка для FEC 1.1.1.1:
18.png!!!
Спойлер!!! Короткое объяснение, почему это всё так.
Всё это именно так, потому что префикс 192.168.255.1 доступен через узел 1.1.1.1, пусть даже он и внутри VPN. То есть по идее выполняется рекурсивное обращение к таблице маршрутизации:
Найти маршрут в ТМ VRF C3PO:
19.png!!!
Узнать сервисную метку: 20.png!!!
3) Узнать транспортную метку для FEC 1.1.1.1: 21.png!!!
4) Рекурсивно вычислить, как доступен 1.1.1.1:
22.png!!!
И только потом передать пакет с двумя MPLS-метками в FE0/0.
Но, как обычно FIB содержит всю актуальную информацию без многократных обращений к ТМ:
23.png!!!
CEF говорит нам: отправить пакет со стеком меток 17, 22 в сторону 10.0.23.2 в интерфейс FE0/0.
!!!
Ещё два сценария, которые я бы хотел рассмотреть в рамках практики — это организация взаимодействия между VPN и доступ из VPN в Интернет.
Взаимодействие между VPN
Здесь мы поработаем с RT — сделаем так, чтобы маршруты из VPN TARS и C3PO передавались в LRA самим BGP.
Конфигурация компьютера R2D2:
interface Loopback0
ip address 10.10.10.10 255.255.255.255
!
interface FastEthernet0/0
description To Linkmeup
ip address 10.10.10.2 255.255.255.252
!
router ospf 1
network 10.10.10.0 0.0.0.255 area 0
Настройка VRF на Linkmeup_R3:
Linkmeup_R3(config)#ip vrf R2D2
Linkmeup_R3(config-vrf)#rd 64500:300
Linkmeup_R3(config-vrf)#route-target both 64500:300
Linkmeup_R3(config-vrf)#route-target import 64500:100
Linkmeup_R3(config-router)#interface FastEthernet1/1
Linkmeup_R3(config-if)#ip vrf forwarding R2D2
Linkmeup_R3(config-if)#ip address 10.10.10.1 255.255.255.252
Linkmeup_R3(config-vrf)#router ospf 3 vrf R2D2
Linkmeup_R3(config-router)#redistribute bgp 64500 subnets
Linkmeup_R3(config-router)#network 10.10.10.0 0.0.0.3 a 0
Linkmeup_R3(config)#router bgp 64500
Linkmeup_R3(config-router)#address-family ipv4 vrf R2D2
Linkmeup_R3(config-router-af)#redistribute ospf 3
Собственно ничего здесь нового нет, за исключением настройки route-target в VRF.
Как видите, кроме обычной команды «route-target both 64500:300» мы дали ещё и «route-target import 64500:100». Она означает, что в VRF необходимо импортировать маршруты с RT 645500:100, то есть из VPN C3PO, как мы этого и хотели.
Сразу после этого маршруты появляются на R2D2:
24.png!!!
!!!
Но, если запустить пинг до адреса 192.168.255.1, то он не пройдёт. Почему?
25.png!!!
Для интереса добавим на TARS_2 Loopback 1 с адресом 10.10.10.10/32 — такой же, как у Loopback 0 R2D2, перезапустим BGP и посмотрим что из этого получится.
Intersect_IPs.png!!!
Здесь видно, как с Linkmeup_R3 передаются на Linkmeup_R1 два маршрута в одну сеть — 10.10.10.10/32, но у них разные RD.
Полная конфигурация всех узлов для сценария взаимодействия между VPN.
!!!
Доступ в Интернет из VPN
Эта тема очень плохо раскрыта в рунете. Мне не удалось найти сколько-нибудь вменяемого описания что это вообще такое.
Восполняя этот пробел, я добавляю этот параграф в статью.
Итак, может статься, что провайдер в тот же самый VPN продаёт и доступ в Интернет. Именно в VPN, не отдельный кабель, не отдельный VLAN, а именно доступ в Интернет через то же самое подключение, через те же адреса.
Ясное дело, что понадобится NAT, чтобы спрятать частные сети.
Так вот есть 3 подхода к реализации этого функционала, которые различаются лишь местом, где происходит трансляция адресов:
- В сети заказчика, например, на CE.
- На Ingress PE — маршрутизаторе, к которому подключен CE.
- На Egress PE — маршрутизаторе, который подключен к Интернету.
Каждый из них имеет право на жизнь. Рассмотрим все.
NAT на CE
Такой NAT возможен, например, когда у клиента уже есть публичные адреса. Тогда в этот пул транслируются внутренние адреса. Всё, что остаётся сделать провайдеру — настроить маршрутизацию между VRF и глобальной таблицей.
Учитывая, что трансляция будет на CE, то нужно выбрать только один филиал, пусть это будет TARS_2.
Картинка!!!
Как видите, для этого теста нам нужно что-то в качестве Интернета и компьютер, которому доступ туда нужен.
В новом GNS есть такой чудесный объект, как VPCS, который прекрасно подходит на эту роль.
На TARS_2 нужно настроить NAT, ниже его конфигурация:
interface Loopback0
ip address 172.16.255.2 255.255.255.255
!
interface FastEthernet0/0
description To Linkmeup
ip address 100.0.1.2 255.255.255.252
ip nat outside
!
interface FastEthernet0/1
description To LAN
ip address 172.16.1.1 255.255.255.0
ip nat inside
!
router bgp 64502
network 172.16.1.0 mask 255.255.255.0
network 172.16.255.2 mask 255.255.255.255
neighbor 100.0.1.1 remote-as 64500
!
ip nat inside source list 100 interface FastEthernet0/0 overload
!
access-list 100 deny ip 172.16.0.0 0.0.255.255 172.16.0.0 0.0.255.255
access-list 100 permit ip 172.16.0.0 0.0.255.255 any
access-list 100 состоит из двух строк — первая запрещает трансляцию адресов для пакетов, которые идут из своей сети в свою же сеть, находящуюся на другом конце провайдера.
Вторая строка разрешает трансляцию только для адресов своей сети. Если вдруг вы пропишите permit ip any any, то сразу же упадёт BGP-сессия с Linkmeup_R3.
Подробности по настройке NAT были освещены в пятой части СДСМ
!!!
Конфигурация Интернета:
interface Loopback0
ip address 101.0.0.101 255.255.255.255
!
interface FastEthernet0/0
description To linkmeup
ip address 101.0.0.1 255.255.255.252
!
router bgp 64501
network 101.0.0.0 mask 255.255.240.0
neighbor 101.0.0.2 remote-as 64500
!
ip route 101.0.0.0 255.255.240.0 Null0
!!!
Настройки BGP на Internet точно такие же, как были в Балаган-Телекоме в восьмом выпуске, мы только позволили себе некоторые вольности с IP-адресами.
Интерфейс Loopback 0 олицетворяет в себе весь интернет. Пинг до него и будем проверять.
Соответствующим образом настроен и Linkmeup_R1:
interface FastEthernet1/1
description To Balagan-Telecom
ip address 101.0.0.2 255.255.255.252
!
router bgp 64500
network 100.0.0.0 mask 255.255.254.0
network 101.0.0.0 mask 255.255.255.252
neighbor 101.0.0.1 remote-as 64501
!
ip route 100.0.0.0 255.255.254.0 Null0
Что же касается доступа в Интернет из VPN, то в данном случае конфигурацию нужно менять только на ближайшем к CE PE — в нашем случае Linkmeup_R3:
Во-первых создадим маршрут по умолчанию для VRF TARS. Это для того, чтобы пакеты, пришедшие от TARS_2 не были отброшены и знали куда двигаться.
Linkmeup_R3(config)# ip route vrf TARS 0.0.0.0 0.0.0.0 102.0.0.2 global
Обратить внимание здесь нужно на две вещи:
Ключевое слово global. Оно говорит о том, что Next Hop (101.0.0.2) нужно искать в глобальной таблице маршрутизации.
В качестве адрес Next-Hop выбран линковый адрес Linkmeup_R1 в сторону Интернета. Почему не Loopback, как мы любим? Это позволяет избежать так называемого blackholing’a. Дело в том, что loopback всегда доступен, а в случае падения канала между нашим шлюзом (Linkmeup_R1) и Интернетом, TARS_2 этого никак не заметит и продолжит слать трафик на Linkmeup_R3, а тот, тоже ничего не подозревая, на Linkmeup_R1. Если же мы укажем ликновый адрес, то он пропадёт из таблиц маршрутизации сразу, как упадёт линия.
Результат:
26.png!!!
2. Теперь этот маршрут нужно сообщить клиенту, чтобы у того появился маршрут по умолчанию (хотя он может настроить его и самостоятельно).
address-family ipv4 vrf TARS
neighbor 100.0.1.2 default-originate
Результат:
27.png!!!
Итак, маршруты туда, то есть в Интернет у нас уже есть, теперь что касается обратно.
next-hop-self!!!
3. На Linkmeup_R3 настроим статический маршрут для сети 100.0.1.0/30.
Зачем нам это нужно? Чтобы был маршрут, логично ведь. Если из Интернета пакет прилетит на Linkmeup_R3, а на нём не будет маршрута к 100.0.0.0/30 в глобальной таблице маршрутизации (в VRF-то он, конечно, будет), пакет будет отброшен.
Было:
28.png!!!
Стало:
29.png!!!
Далее об этой сети нужно сообщить BGP-соседям — о такой сети должны узнать все. В частности нас интересует Linkmeup_R1.
router bgp 64500
network 100.0.1.0 mask 255.255.255.252
Результат:
30.png!!!
BGP в принципе и прежде знал об этой сети, но только в address-family ipv4 vrf TARS, куда она попадала с помощью команды redistribute connected. В глобальной же таблице маршрутизации её не было.
Итак, всё готово, проверяем:
31.png!!!
32.png!!!
Это говорит о том, что заработал route leaking, то есть доступ из VRF в глобальную таблицу маршрутизации и наоборот работает.
Проверка доступности Интернета с компьютера — это формальность, которая покажет, что мы правильно настроили NAT. Фактически Route Leaking происходит на Linkmeup_R3, а трансляция на TARS_2, то есть вещи это по большому счёту не связанные.
Однако:
33.png!!!
Интернет доступен. Ура.
Полная конфигурация интересных нам узлов.
Давайте проследим, что происходит с пакетом по пути от PC1 до Internet.
Обычным образом пакет попадает на шлюз по умолчанию — TARS_2
TARS_2 видит, что адрес назначения подпадает только под маршрут по умолчанию, передаёт пакет в интерфейс FE0/0 на Linkmeup_R3. В последний момент он замечает, что заголовок пакета полностью удовлетворяет списку доступа (access-list 100) и транслирует локальный адрес 172.16.1.2 в 100.0.1.2
!!!
34.png!!!
!!!
Пакет приходит в VRF TARS на Linkmeup_R3, где снова подпадает под маршрут по умолчанию, который указывает на адрес 101.0.0.2 из глобальной таблицы маршрутизации. Уже из глобальной ТМ Linkmeup_R3 знает, что 101.0.0.2 доступен через 1.1.1.1 и рекурсивно через 10.0.23.2. Причём пакету выдаётся метка 16. То есть после Linkmeup_R3 пакет уже пойдёт по MPLS LSP.
!!!
35.png!!!
!!!
CE_NAT.png!!!
Пакет между Linkmeup_R3 и Provier_R2
Заметьте, что метки VPN здесь нет — пакет перекочевал из VPN в публичную сеть.
4) На Linkmeup_R2 с пакета снимается транспортная метка MPLS (PHP) и на Linkmeup_R1 уже передаётся чистый IP-пакет.
5) Этот чистый IP-пакет уходит с Linkmeup_R1 в Internet (BGP сообщил маршрут до сети 101.0.0.0/20)
6) Internet знает маршрут до 100.0.0.0/23 и передаёт пакет обратно.
7) Linkmeup_R1 знает, что адресат находится за 3.3.3.3 — помните, мы объявляли эту сеть в BGP?
Соответственно, по MPLS он доходит до Linkmeup_R3.
!!!
36.png!!!
!!!
8) Сеть 100.0.1.0/30 находится в VRF TARS, но мы ведь прописывали её статически в интерфейс FE1/0. Так что пакет передаётся благополучно на интерфейс.
9) Ну а дальше обратная трансляция и последняя миля до родного дома.
Этот сценарий называется Route Leaking — маршруты протекают из VRF в глобальную таблицу. Название функционала говорящее — прибегать к Route Leaking’у нужно только в крайних случаях!!! почему
VRF-Aware NAT
Более правильный и чуть более масштабируемый вариант — настройка трансляции на Egress PE — на выходе в Интернет. В этом случае у нас есть централизованный узел, где выполняются все операции и нет необходимости в Route Leaking’е
Единственное неудобство: несмотря на то, что ни один клиент может быть не подключенным к этому маршрутизатору, ему придётся поддержитвать все VRF, из которых нужно получать доступ в Интернет.
Соответственно, дело имеем с Linkmeup_R1, который является шлюзом в интернет для всей сети linkmeup — никаких абсолютно дополнительных настроек на других узлах.
PC2 из сети C3PO Electronic хочет получить доступ в Интернет.
PC2 из TARS’ Robotics не трогаем и оставляем без изменений — они со своими белыми адресами — отдельная история, хотя их тоже вполне можно натить.
Итак, во-первых на Linkmeup_R1 должен быть VRF C3PO. Он уже есть, но если бы не было, нужно было бы, чтобы было.
Конфигурация VRF типичная и она не поменялась:
ip vrf C3PO
rd 64500:100
route-target export 64500:100
route-target import 64500:100
Включаем ip nat inside в ту сторону, откуда получаем пакеты для трансляции, то есть в сторону P-маршрутизатора Linkmeup_R2:
Linkmeup_R1(config)#interface FastEthernet 0/1
Linkmeup_R1(config-if)#ip nat inside
В сторону Интернета включаем ip nat outside:
Linkmeup_R1(config)#interface FastEthernet 1/1
Linkmeup_R1(config-if)#ip nat outside
В BGP, как и в прошлый раз прописываем отправку маршрута по умолчанию в данный VRF:
Linkmeup_R1(config)#router bgp 64500
Linkmeup_R1(config-router)#address-family ipv4 vrf C3PO
Linkmeup_R1(config-router-af)#redistribute static
Linkmeup_R1(config-router-af)#default-information originate
Заметьте, что здесь недостаточно одной только команды redistribute static, чтобы забрать и анонсировать маршрут по умолчанию. Для этого дополнительно придётся выполнить явно команду default-information originate.
Чтобы этот маршрут анонсировался, нужно, чтобы он был в таблице маршрутизации:
Linkmeup_R1(config)#ip route vrf C3PO 0.0.0.0 0.0.0.0 101.0.0.1 global
Создаём ACL, где разрешаем доступ из сети C3PO в интернет:
Linkmeup_R1(config)#access-list 100 permit ip 192.168.0.0 0.0.255.255 any
И собcтвенно сам NAT:
Linkmeup_R1(config)#$ip nat inside source list 100 interface FastEthernet 1/1 overload
Сейчас сразу не заработает, потому что слегка слукавил, говоря, что никакие настройки нигде кроме интернет-шлюза не понадобятся.
Дело в том, что мы сгенерировали маршрут по умолчанию для VRF C3PO на Linkmeup_R1 и по BGP передали его на Linkmeup_R3, но тут он и застрял, не дойдя до C3PO_2 — нужно заставить OSPF анонсировать маршрут по умолчанию. Как и в предыдуший раз без явной команды default-information originate он этого делать не будет:
Linkmeup_R3(config)#router ospf 2 vrf C3PO
Linkmeup_R3(config-router)# default-information originate
Проверяем:
37.png!!!
!!!
Что происходит с пакетом?
От PC2 до Linkmeup_R3 он доходит без видимых изменений (только заголовок MAC меняется). На PC2 маршрут по умолчанию настроен вручну. На C3PO_2 он изучен по OSPF от Linkmeup_R3.
На интерфейсе FE0/1 пакет входит в CRF C3PO и приобретает сервисную метку.
Маршрут по умолчанию в VRF импортирован из BGP и он ведёт к 1.1.1.1 через 10.0.23.2:
38.png!!!
!!!
4) От Linkmeup_R3 до Linkmeup_R1 пакет идёт по MPLS с двумя метками: внутренней сервисной — 27 и внешней транспортной — 18.
ping_internet.png!!!
Не забывайте делать поправку на PHP — от Penultimate Router — Linkmeup_R2 — к Egress PE — Linkmeup_R1 — пакет пойдёт с одной сервисной меткой, потому что транспортная была снята в результате PHP.
5) На Linkmeup_R1 происходит Route leaking из VRF C3PO в глобальную таблицу — так пакет покидает VRF.
Также здесь происходит трансляция. Linkmeup_R1 записывает информацию об этом факте в свою таблицу трансляций для VRF C3PO:
39.png!!!
6) В Интернет пакет уходит уже, конечно, без меток MPLS и с публичным адресом отправителя — 101.0.0.2 в заголовке
ping_internet_R1.png!!!
7) Ответный пакет на Linkmeup_R1 попадает по глобальной таблице маршрутизации — Интернету известен адрес 101.0.0.2. На этоу узле происходит обратная трансляция. Адрес назначения меняется на 192.168.2.2 и искать его нужно уже в VRF C3PO — так сказала таблица NAT.
8) А дальше процесс вам уже известен — две метки, долгий путь до Linkmeup_R3 и далее до PC2.
Полная конфигурация узлов для VRF Aware NAT.
Common Services
Ещё один подход к предоставлению доступа в Интернет — вывести его в отдельный VRF.
Строго говоря — он наиболее масштабируемый, потому что нет необходимости настраивать что-то индивидуально для каждого клиентского VRF.
Важное условие — NAT происходит в сети клиента и в VRF Internet импортируются только маршруты к публичным сервисам префиксам.
Shared Services — это продолжение вопроса о взаимодействии между VRF, который мы рассмотрели ранее!!! Основная идея в том, что экспорт/импорт совершается засчёт особой настройки route-target. Только на этот раз нужно ограничить список передаваемых префиксов, чтобы избежать пересечения адресных пространств и разрешить только публичные маршруты.
Рассмотрим задачу снова на примере TARS, потому что у них уже есть публичные сети.
На шлюзе мы создаём VRF Internet.
Linkmeup_R1(config)#ip vrf Internet
Linkmeup_R1(config-vrf)#rd 64500:1
Linkmeup_R1(config-vrf)#route-target import 64500:11
Linkmeup_R1(config-vrf)#route-target export 64500:22
Обратите внимание, что route-target на импорт и на экспорт в этот раз разные и сейчас станет понятно почему.
2) Перенести интерфейс в сторону Интернета в VRF:
Linkmeup_R1(config)#interface FastEthernet 1/1
Linkmeup_R1(config-if)#ip vrf forwarding Internet
Linkmeup_R1(config-if)#ip address 101.0.0.2 255.255.255.252
3) Перенести BGP-соседство с маршрутизатором в Интернете в address-family ipv vrf Internet:
Linkmeup_R1(config-router)# router bgp 64500
Linkmeup_R1(config-router)# no neighbor 101.0.0.1 remote-as 64501
Linkmeup_R1(config-router)# address-family ipv4 vrf Internet
Linkmeup_R1(config-router-af)# neighbor 101.0.0.1 remote-as 64501
Linkmeup_R1(config-router-af)# neighbor 101.0.0.1 activate
4) Address-family для него:
Linkmeup_R1(config)#router bgp 64500
Linkmeup_R1(config-router-af)#network 0.0.0.0 mask 00.0.0.0
Linkmeup_R1(config-router-af)#default-information originate
Маршрут по умолчанию, чтобы он появился в таблице маршрутизации
Linkmeup_R1(config)#ip route vrf Internet 0.0.0.0 0.0.0.0 101.0.0.1
5) В клиентском VRF TARS нужно также настроить RT:
Linkmeup_R3(config-vrf)#ip vrf TARS
Linkmeup_R3(config-vrf)# route-target both 64500:200
Linkmeup_R3(config-vrf)# route-target export 64500:11
Linkmeup_R3(config-vrf)# route-target import 64500:22
Итак, помимо собственного RT, который обеспечивает обмен маршрутной информацией с другими филиалами, здесь настроены и те RT, что и для VRF Internet, но наоборот:
- то, что было на экспорт в VRF Internet, то стало на импорт в VRF TARS
- то, что было на импорт в VRF Internet, то стало на экспорт в VRF TARS
Почему так? Почему нельзя просто дать route-target both 64500:1, например, на всех VRF?
Основная идея концепции Common Service — предоставить доступ к нужно VRF всем клиентским, но не позволить им общаться им друг с другом напрямую, чтобы обеспечить изоляцию, как того требует определение VPN.
Если настроить одинаковый RT на всех VRF, то маршруты будут спокойно ходить между ними.
При указанной же выше конфигурации у всех клиентских VRF есть RT 64500:22 на импорт (все будут получать маршруты Internet), и также у них есть RT 64500:11 на экспорт, но только у VRF Internet есть такой RT 64500:11 на импорт — только VRF Internet будет получать маршруты клиентов. Друг с другом они обмениваться не смогут.
!!! Картинка.
Результат:
40.png!!! Лишние маршруты
41.png!!!
И у нас даже будет связность:
42.png!!!
Но что делать с этими лишними маршрутами в VRF Internet? Ведь если мы подключим ещё один VRF также, у нас и от него появятся ненужные серые подсети.
Тут как обычно поможет фильтрация. И конкретно поспользуемся prefix-list+route-map:
Linkmeup_R3(config)#ip prefix-list 1 deny 172.16.0.0/12 le 32
Linkmeup_R3(config)#ip prefix-list 1 deny 192.168.0.0/16 le 32
Linkmeup_R3(config)#ip prefix-list 1 deny 10.0.0.0/8 le 32
Linkmeup_R3(config)#ip prefix-list 1 permit 0.0.0.0/0 le 32
Первые три строки запрещают анонсы всех частных сетей. Четвёртая разрешает все остальные.
В нашем случае вполне можно было бы обойтись одной строкой: ip prefix-list 1 permit 100.0.0.0/23 le 32 — вся подсеть Linkmeup, но приведённый нами пример более универсальный — он допускает существование других публичных сетей и соответсвенно один prefix-list может быть применён для всех VRF.
Следующая конструкция применяет расширенное community к тем префиксам, что попали в prefix-list 1:
route-map To_Internet permit 10
match ip address prefix-list 1
set extcommunity rt 64500:11
Осталось дело за малым — применить route-map к VRF:
ip vrf TARS
export map To_Internet
После обновления маршрутов BGP (можно форсировать командой clear ip bgp all 64500) видим, что в VRF Internet остался только публичный маршрут:
43.png!!!
И, собственно, проверка доступности Интернета с PC1 (NAT уже настроен на TARS_2):
44.png!!!
Полная конфигурация всех узлов для Common Services.
packetlife.net/blog/2011/may/19/mpls-vpn-common-services/
blog.ipspace.net/2011/05/mplsvpn-common-services-design.html
supportforums.cisco.com/document/32341/providing-internet-access-mpls-l3-vpns
supportforums.cisco.com/discussion/11567421/route-leaking-between-vrfs-shared-services
ВиО
Замечательная глава Вопросы и Ответы. Мне очень нравится, потому что сюда можно засунуть всё, чему не хватило места в основной статье.
В: Можно ли говорить, что P — это Intermediate LSR, а PE — это LER?
О: Строго говоря, нет. Как минимум, потому что понятия LER, LSR — это базовый MPLS и касаются LSP, а P, PE, CE — только в VPN.
Хотя, конечно, обычно тот узел, к которому подключен клиент, выполняет и роль Ingress/Egress LSR в MPLS и роль PE в VPN.
В: Почему MBGP — это MultiProtocol BGP, а не, например, MPLS BGP? Что в нём многопротокольного?
О: Задача BGP — передавать маршруты. Исторически и классически — это IPv4. Но помимо обычных префиксов BGP может передавать и массу других: IPv6, IPX, Multicast, VPN. Каждый тип префиксов настраивается как отдельный Address Family — то есть группа адресов одного типа. Собственно вот за эту возможность передавать маршрутные данные разных протоколов такой BGP и получил имя MBGP.
В: Где передаются сами маршруты, RD и их атрибуты в MBGP?
О: RD является частью VPNv4-маршрута и вместе с ним передаётся в секции NLRI — Network Layer Reachability Information.
RT передаётся в секции Extended Community, поскольку им и является по своей сути.
В: Так в чём всё-таки разница между RD и RT? Почему недостаточно только одного из них? И я правильно понял: RD не является идентификатором VPN, как и RT?
О: Да, ни RD, ни RT однозначно не идентифицируют VPN. Как для одного VPN на разных маршрутизаторах могут быть настроены разные RD/RT, так и для двух разных теоретически могут быть одинаковые RD/RT.
Ещё раз:
RD — Route Distinguisher — его основная и единственная задача — сделать так, чтобы маршруты не смешались в MBGP — два одинаковых маршрута из разных VPN должны быть таки двумя разными маршрутами. RD не говорит PE, куда нужно экспортировать маршрут и существует/работает только при передаче маршрута.
RT — Route Target. Он не помогает разделить маршруты разных VPN, но он позволяет экспортировать их в те VRF, в которые надо. То есть он имеет значение в момент импорта маршрута из VRF в самом начале и в момент экспорта в VRF на другом конце в самом конце. Передаётся в Extended Community.
Одного RD не хватит, потому что PE не будут знать, как правильно распорядиться маршрутами.
А одного RT не хватит, потому что маршруты смешаются при передаче и потеряются все, кроме одного.
Можно было бы оставить только RD, например, и на его основе решать, куда маршрут передать, но это и не гибко и идёт в разрез с принципами BGP.
В: Если я не планирую подключать клиентов, то я зря прочитал это гигантскую статью, да? Иными словами, есть ли у MPLS L3VPN другие применения?
О: Вовсе не зря. Как минимум ещё одно примнение — это разделение своих собственных услуг в пределах своей же сети.
Например, если вы оператор сотовой связи и предоставляете услуги в сетях 2G, 3G, 4G и строите уже вовсю 5G, то свою сеть Mobile Backhole (MBH!!!) вы можете разбить на 5 VPN: по одной для каждого поколения радиосвязи и одну для сети управления элементами. Это позволит к каждой сети применять свои правила маршрутизации, качества обслуживания, политики обработки трафика. А если совместить это ещё и с Traffic Engineering…
Причём тут даже не надо будет настраивать взаимосвязь между VPN в пределах MBH — каждая сеть изолирована от абонента до Core Network: у 2G в ядре стоит BSC, у 3G — RNC, у 4G — MME. И только в ядре сети на спецаильном маршрутизаторе или файрволе можно их скрестить.
А вот ещё пример: столь популярная ныне технология MVNO — Mobile Virtual Network Operator — когда одна сеть MBH используется для двух и более операторов. Здесь уже однозначно нужно будет разделять и властвовать.
Но как ни крути, да, MPLS VPN — это всё-таки преимущественно игрушка больших воротил.
В: Не возьму в толк: как Egress PE, получив пакет с одной меткой, то есть если произошёл PHP, определяет что эта метка VPN, а не транспортная, и, соответственно, что по метке нужно передать его в VRF, а не скоммутировать куда-то дальше?
О: Всё очень просто — пространство меток для VPN, для LSP, для всевозможных FRR и CSC — общее. Не может быть такого, что для VPN и для LSP была выделена одна и та же метка. Ну а каждой метке при её создаении ставиться в соответствие её роль и действия при её получении.
Полезные ссылки
Горячо мной любимый Джеф Дойл: VPN в двух частях: Part I, Part II.
Мне почему-то тяжеловато читать примеры конфигурации cisco, но лучше них эту тему пока никто не раскрыл: NAT — Integration with MPLS VPN.
О различиях RD и RT пишет Jeremy Stretch: Route Distinguishers and Route Targets.
Как вы могли заметить, создание L3VPN — это большое количество ручной работы. И в случае необходимости организовать взаимодействие между VPN, придётся настроить не только один Интернет-шлюз даже в самом правильном и красивом способе, но и клиентские PE.
Но вся эта работа необходима, здесь нет избыточности. Для контраста вспомните, во что бы вам встала настройка, VPN с помощью GRE или VRF-Lite.
И обратите внимание, маршратизатор P — Linkmeup_R2 — оставался асболютно неизменным в течение всех стадий настройки с момента первоначального включения на нём MPLS. Это ли не прелестно?!
Нельзя сказать, что этой небольшой статьёй мы объяли весь L3VPN, в частности остались за пределами общей картины такие интереснейшие вещи, как Inter-AS VPN, коих 3 вида, и CSC (Carrier Support Carrier). Но я надеюсь конкретно по этим двум механизмам написать отдельную статью.
L3VPN — вещь зрелая, продуманная и стандартизированная. У всех производителей она работает плюс/минус одинаково.
А вот в впереди ещё статья про L2VPN, которая включит в себя AToM, VLL, PWE3 и VPLS. В ней узнаем, какую роль сыграли Cisco и Juniper в развитии этого направления, какие радости в нашу жизнь привносят такие услуги, как CES или EoMPLS. Наберитесь терпения — в этом году я постараюсь увеличить темпы, набрать обороты, раскрутиться и увеличить КПД.
0
2587
0
Ещё статьи
0 коментариев