Компоненты MPLS L3 VPN

Я напомню, что предыдущее занятие закончилось тем, что мы включили в лабораторной среде MPLS, подняли BGP между двумя роутерами, которые символизируют пограничные роутеры нашего воображаемого провайдера и убедились, что на транзитных роутерах внутри сети провайдера действительно не видно префиксы, которые соответствуют некоторому клиентскому адресному пространству. При этом трафик этих субклиентов находят нормально. Алексей, я так понимаю, сейчас будет нам показывать куда более интересную вещь, как сделать так, чтобы не просто трафик между клиентскими сетями ходил, а так, чтобы он еще и ходил с соблюдением некоторых требований. Я правильно понимаю? Мы сегодня про это будем рассказывать, правда? Да, мы с ним будем строить литвены третьего уровня. В частности, мы посмотрим, как туннелировать трафик, если, например, у заказчиков или просто у каких-то клиентов, неважно, это может быть интерпрайс на самом деле,

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

Либо же вы, например, можете, скажем, давать услуги доступа к вашей сети, например, как сделано почти во всех аэропортах. То есть там где-то есть MPLS-ное кольцо. Ну, и, соответственно, там, например, магазинчики такие как duty-free. Они, например, могут пользоваться услугами VPN-а, либо доступа к интернету. Да, при этом… Вы хотя бы… Вы, хоть и интерпрайс, но тем не менее, предоставляете услуги некого сервиса. Давайте начнем с вот такой задачки. Берем как данность то, что у нас уже есть наша работающая MPLS-орбака. У нас есть некий наш граничный маркетизатор. Наш граничный маркетизатор. Два, например. И, соответственно, к каждому из этих граничных маркетизаторов подключено по два заказчика. Будет красный заказчик. И будет зеленый заказчик.

И будет зеленый заказчик. Смотрите, с точки зрения терминологии MPLS-а, ну, на самом деле, наверное, не столько MPLS-а, сколько общепринятая терминология, амортизатор, который стоит как бы на границе между сетью заказчика и вашей MPLS-сетью, называется Payeral. П в данном случае расшифровывается как провайдер. И Е расшифровывается как Edge. То есть, собственно, такое пограничное устройство провайдера. Далее. Амортизаторы заказчика, которые стоят, соответственно, называются CE-раутеры, где C это Customer. То есть, у нас получается Customer Edge-раутер. CE1 и CE2. Наша задача сделать так, чтобы зелененький CE-раутер могли общаться между собой, чтобы красненький CE-раутер могли общаться между собой. Соответственно, чтобы, очевидно, чтобы транзитные амортизаторы,

которые у нас здесь, их, кстати, также называют Pay-раутеры. То есть, это просто провайдер-раутеры. То есть, те, которые занимаются тем, что слопают меточки между интерфейсами для проходящего трафика. Эти па-раутеры ничего не должны знать о клиентских подключениях. И при этом мы накладываем требования, что у нашего красного и зеленого заказчика может быть пересекающаяся опять адресация. В частности, предположим, что слева у нас используется сеть, например, 10.1.1.0.24. Здесь, например, используется сеть 10.2.0.24. Ну, и зелененькие абсолютно те же самые под сеть. 2.2.0. И 10.1.1.0.24. Обратимся к нашей топологии на лабе.

У меня есть такая топология, которая называется ROS Basic. Я здесь красными, собственно, зелеными цветами выделил то, как мы будем настроить наши IP-н-сети. Как мы видим, в частности, у нас есть маршрутизатор R1, маршрутизатор R2, который смотрит в сторону своих кастомов. Давайте посмотрим, что будет, если я просто влог попытаюсь удовлетворить условия, условия, что у меня на двух интерфейсах может быть одна клайка описаться. Я беру, например, некий интерфейс G3. Интерфейс G3 – это интерфейс, который смотрит в сторону моего заказчика. И говорю, некий IP-адрес. Здесь, кстати, уже он, наверное, прописан. Вот так, видите, здесь уже прописан адрес 10.1.11.1.

Я просто создам, думаю, это некий лукбэк и пропишу на нем адрес 10.1.11.1. Ну, как вы видите, сделать это не получится, поскольку он говорит, что адрес из этой сети уже существует на другом интерфейсе. Поэтому нам нужно, на самом деле, некое решение, которое позволит нам, тем не менее, на двух разных интерфейсах прописать одни и те же IP-адреса. Такое решение называется VRAF, что как аббревиатура шифра «Virtual Routing and Forwarding», или по-русски просто некая, скажем так, «Виртуальная таблица мультизации и коммутации». Что же такое VRAF? Что же такое VRAF? Ребята, на самом деле, все из вас знают, что такое VRAF, поскольку все из вас, скажем так, те из вас, кто так или иначе работал с мультизаторами,

с VRAF уже работали, даже если вы раньше не слышали этого слова. Дело в том, что если я дам команду «show IP-Rout», «show IP-Rout», «show IP-Rout», и если я дам команду «show IP-Routes», я не уверен, что это прямо так работает на фиксии. По умолчанию, по умолчанию, на любом архитизаторе существует так называемый VRAF-default. Иногда его называют GRT, Global Routing Table. Суть. Что же такое VRAF? Смотрите, вот здесь, чуть-чуть ниже, я буду разрисовывать наш амортизатор по яде. Я его могу представить как некую коробку. Как некую коробку.

У этой коробки есть, условно говоря, некое системное имя. И оно по умолчанию называется Default. Default или то же самое, как у GRT, глобальная таблика с амортизацией. У этого амортизатора есть некое количество интерфейсов. Здесь некое количество интерфейсов. Соответственно, все эти интерфейсы вы настраиваете, то есть настраиваете майки адреса, либо еще что-то. Все эти интерфейсы принадлежат вот этому амортизатору с именем Default. Упрощенно говоря, упрощенно говоря, можно подумать, что GRT, ну, в самом деле, что GRF это некая виртуальная машина, упрощенно, которая крутится внутри вашего физического бокса. Я так думаю, что с виртуализацией на том или ином уровне

наверняка все сталкиваются, или большинство из вас. То есть, например, вы можете установить на ваш хост, на вашу рабочую станцию, скажем, программу VMware Player, VMware Workstation. И внутри, собственно говоря, самой программы вот этой VMware Workstation вы можете запустить некую гостевую операционную систему, скажем, там, Windows, Linux, Mac. При этом вот эта гостевая операционная система, она будет работать независимо от того, от вашей хостовой операционной системы, то есть, на которой она запущена. Здесь, ребята, на самом деле идея примерно та же самая. То есть, в качестве вашей хостовой, родительской операционной системы выступает ваш физический амортизатор. И далее вы внутри вот этой физической коробки начинаете нарезать ваши виртуалы. Единственное отличие в том, что,

если мы говорим про VMware, про OpenStack, про KVM и прочее, у вас действительно подгружается новая операционная система со своими конфигурационными файлами и прочее. Здесь немножко не так. Она как бы создается условно, то есть, она существует так, виртуально, живет, может жить свою жизнь, то есть, она живет как бы в рамках таблицы муфтизации. Она не подгружает какую-то новую операционную систему и прочее. То есть, в том, что у вас внутри, внутри вашего физического бокса, внутри вашего физического бокса создается, скажем так, вот этот вот красненький амортизатор и создается зелененький амортизатор. Это зелененький амортизатор. Следующий шаг, следующий шаг, который вы должны сделать, это следующий. Предположим, что у нас

интерфейс, вот это, скажем, интерфейс 00, это интерфейс 01. По умолчанию, по умолчанию все интерфейсы относятся к вашей физической коробке, к вашему дефолтному амортизатору. То есть, вот они были, 00, 01, 02, 03. Если мы хотим, если мы говорим, что некий красный заказчик подключается к нашему красному виртуальному амортизатору, то он подключается к красному амортизатору, мы должны взять, выключить этот интерфейс. То есть, мы должны просто переместить интерфейс из физического устройства в наш виртуальный амортизатор. Если у нас этот интерфейс 01, он теперь будет жить здесь. То же самое, то же самое мы делаем с интерфейсом 00. мы берем и перемещаем вот сюда. Перемещаем вот сюда.

После этого мы совершенно спокойно можем на интерфейсе 01 и на интерфейсе 00 настроить IP-адреса из одинаковой подсети. Почему? Потому что это будут уже не это будут интерфейсы, которые относятся по сути к двум разным логическим устройствам. То есть, к красному амортизатору и к зеленым. Ребята, этот момент понятен всем, как, то есть, для чего нужны VRF-ы. и одно важное уточнение. Одно важное уточнение. Смотрите, поскольку это два получается таких логически независимых амортизатора,

у нас между ними по умолчанию не будет никакой связанности. То есть, вы не сможете перекинуть пакеты с интерфейсом 0.1 на интерфейс 0.0. Есть различные способы, как это сделать. Можно организовать некий так называемый ликинг внутри глобальной коробки и таким образом просто на уровне логики внутри одного шасси перекидывать трафик с интерфейса 0.0 на интерфейсе 0.1. Это первый вариант. Либо на самом деле второй вариант он скажем так он наиболее в жизни применим. Вот здесь можно поставить некое устройство третьего уровня. Некое устройство третьего уровня. Чаще всего это бывает какой-то мешцевой экран. Например, циска аса, палальто, что-то такое. Соединяем их вот

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

есть какая-то зона бэкэнда, и вы хотите, чтобы трафик между сетями фронтенда и бэкэнда обязательно проходить через межсетевой экран. Соответственно, если вы просто возьмете и затерминируете две сети фронтендовскую и бэкэндовскую на одном и том же махтизаторе, условно говоря, то трафик между ними будет ходить напрямую, просто по раутингу. Если вы поместите бэкэнд и фронтенд в разные VRF с точки зрения всех махтизаторов сети, вам придется выбрать некую точку, где трафик между двумя зонами безопасности сможет миксоваться. В основном такой точкой обмена трафиком выступает какой-то межсетевой экран, если мы говорим про интерфайс. То есть, я к тому, что VRF они находят применение далеко не только в SPI, а во многих организациях. Отвечая на вопрос Ивана,

это VRF-Lite. Иван, как таковое VRF и VRF-Lite различаются только тем, что это одни и те же самые VRF-ы. Суть только в том, что VRF-Lite это VRF без использования MPLS. Без использования MPLS. Окей. Предположим, что мы теперь знаем, что такое что такое VRF. Что такое VRF и для чего она может быть нам нужна. Так. Так. Так. Так. Так. Следующий шаг. Следующий шаг. Смотрите. мы строим

VPN третьего уровня. То есть в том, что у нас слева у заказчика сеть 10.1.1.0, справа 10.2.2.0. Поэтому что необходимо? Чтобы маршрутизатор маршрутизатор CE1 красный мог переслать пакет на CE2 красный необходимо, чтобы CE1 каким-то образом смог этот пакет отмаршрутизировать. Правильно? То есть он должен отослать, то есть он должен как-то подружиться с точки зрения раутинга с нашим PE маршрутизатором. И то же самое должно произойти вот здесь. То же самое должно произойти вот здесь. То есть на самом деле что с точки зрения заказчика происходит? То есть что происходит с точки зрения CE раутинга? У нас есть CE1 у нас есть CE2 и между ними просто помещается некий маршрутизатор провайдера. То есть это буквально

один маршрутизатор раутинга. И у нас есть вот такие интерфейсы. Мы здесь запускаем какой-то протокол маршрутизации. Это может быть SPF, это может быть BGP. Мы запускаем какой-то протокол маршрутизации здесь. Это также может быть SPF или BGP. И соответственно для CE1 раутеров просто происходит прозрачный обмен маршрутом. Просто происходит прозрачный обмен маршрутом. Основная задача наша основная задача как организовать этот обмен маршрутом. Почему? То есть условно говоря если мы вот сюда подключим еще нашего зеленого заказчика и поднимем здесь маршрутизацию нам нужно не допустить вот этого литинга префиксов. То есть у нас префиксы от красного заказчика ни в коем случае не должны уйти в зеленом. Как это вам

удобиться? Как это удобиться? Очевидно нам нужно сети заказчика как-то разделять. То есть как-то разделять. Что ж посмотрим что мы для этого можем сделать. первое примите как данность что между этими PE маршрутизаторами между этими PE граничными маршрутизаторами мы поднимаем BGP сессию. Для чего нам нужна BGP сессия на самом деле по сути мы с вами рассмотрели на прошлом занятии. То есть по сути BGP это единственный протокол который позволяет нам обмениваться маршрутной информацией при этом можно спокойно миновать транзитные хопы. Это раз. Второе маршрутная информация то есть если мы обмениваемся BGP маршрутами мы выставляем

некий next hop и дальше у нас LDP генерирует метку для этого next hop таким образом мы спокойно туннелируем POS трафик. То есть мы еще обмениваемся того что все транзитные раутеры могут спокойно передавать пакеты хотя они не знают кому этот трафик реально предназначается. То есть мы как раз смотрели с вами концепт прошлом сайта. Соответственно у нас здесь будет BGP то есть протокол BGP будет ответственен за распространение маршрута информации между сайтами заказчика между CE1 и CE2. Что же происходит? Прежде всего я хочу вам сказать что BGP процесс на CISK ну и наверное на всех вендорах он может быть всего один. Соответственно все префиксы которые мы получим от красного нашего заказчика и от зеленого заказчика попадут в одну и ту же BGP таблицу.

У нас стоит вопрос. Вот у нас слева да у нас слева два заказчика имеют одну и ту же адресацию 10.1.1.1. Если мы просто так возьмем и заинсталируем оба этих префиксов BGP табличку мы их не сможем разделять. Мы не сможем понять чей это префикс зеленый или красный. Поэтому у каждой есть параметр который называется root distinction. В рамках муртизатора этот параметр должен быть уникальным для каждой графа. По сути это некий тег. Условно говоря root distinction состоит из двух частей и обычно записывается как x двоеточие y. В теории числа x и y могут быть любыми но есть некие RFC for recommendations которые определяют

формат записи этого параметра root distinction наиболее принятый в мире наиболее принятый в мире формат следующий x подразумевает под собой номер автономной системы BGP то есть словно говоря если у вас работает раутер BGP скажем 100 это значит о том что для всех VRAF которые созданы на вашем дефектизаторе первое число будет 100 а параметр y это просто некий variable то есть это некое число которое будет организовать данный VRAF предположим что для зеленой VRAF мы говорим что у нас root distinction будет 100 двоеточие 1 и для красного VRAF параметр будет 100 двоеточие 2 100 двоеточие 2 для чего нам это нужно все очень просто смотрите наша BGP табличка BGP табличка

предположим предположим что мы узнали префикс 10 1 1 0 от красного заказчика пока не важно по какому протоколу мы его узнали это может быть статический маршрут это может быть OSPF это может быть RIP это может быть EGRP соответственно если мы используем например тот же OSPF то мы что должны сделать мы должны просто взять полученные красные префиксы и зарегистрирутировать их внутрь нашего BGP процесса если у нас между провайдер и кастомер и кастомер работает по BGP то никакой дополнительной дистрибуции нам для этого делать не нужно окей соответственно мы этот префикс получаем и считаем условно говоря пусть это будет OSPF мы помещаем этот префикс в нашу BGP табличку мы помещаем как 10 1 1 0 слэш 24 и к нему спереди к нему спереди добавляем root distribution

то есть вот общий префикс общий префикс который вы получите от красного заказчика будет выглядеть вот таким вот образом от зеленого заказчика префикс будет выглядеть вот таким префикс естественно это два уникальных префикса вот такие префиксы вот такие префиксы называются VPN префиксами то есть сам префикс плюс root distribution порождает собой так называемый VPN маршрут в частности в частности поскольку мы с вами говорим сейчас о IPv4 адресах то такой префикс будет называться VPN v4 если если бы мы здесь с вами оперировали IPv6 адресами это был бы VPN v6 окей окей

окей дальше дальше мы берем мы берем передаем этот апдейт то есть по сути мы берем и передаем апдейт с марштизатора по E1 на марштизатор P2 вот сюда вот наш префикс сюда вот наш префикс сюда вот наш префикс на марштизатор P2 получает данные BGP апдейт естественно он прежде всего производит обычные BGP манипуляции такие как проверяет доступность скопа выбирает лучший маршрут сравнивает вес local preference меды в общем чего душе угодно то есть обычные BGP правила здесь также работают логика BGP ни в коем случае не меняется мы просто начинаем обмениваться не IPv4 префиксами а VPNv4

префиксами окей у марштизатора P2 прежде чем заинсталлировать этот префикс BGP табличку марштизатор P2 должен понять какой из VRF относится данный префикс получаем все дело в том что вот этот параметр вот этот параметр который мы с вами поговорили root destination он к сожалению не может использоваться для этих целей почему потому что это просто идентификатор VRF который существует на данном муштизаторе это VRF может как присутствовать на другом устройстве так и нет то есть я веду к тому что VRF это понятие сугубо локальное для конкретной железки естественно если у меня на удаленном муштизаторе то есть на P2 настроено VRF

с именем Red например то я должен понять вот ко мне прилетает BGP префикс я должен понять нужно ли мне этот префикс потом передавать в сторону моего заказчика либо нет поэтому поэтому был придуман дополнительный атрибут в частности этот атрибут называется routeTarget этот атрибут называется routeTarget ребята на самом деле упрощенно говоря упрощенно говоря routeTarget это есть не что иное как еще один тег то есть это еще одно некое число которое записывается абсолютно в таком же формате как x двоеточие или и этот этот тег он присоединяется к BGP апдейту как атрибут который называется который носит тип extended community extended community

то есть то есть то есть когда вы помещаете когда вы помещаете префикс из vrf внутрь BGP таблицы вы помимо всех основных атрибутов таких как aspath nexthop origin type еще что-то просто дополнительно просто дополнительно ставить атрибут routeTarget ну например для красного префикса у меня этот атрибут будет routeTarget скажем 100 двоеточие 2 для зеленого префикса routeTarget 100 двоеточие 1 такой процесс навешивания routeTarget когда префикс попадает из vrf в BGP табличку называется экспортом routeTarget соответственно мы ожидаем что на приемной стороне что на приемной стороне

у нас будет настроен импорт то есть если на маркизаторе PE2 если на маркизаторе PE2 предположим что у нас существует там скажем vrf1 vrf2 и условно говоря vrf3 для этой vrf3 мы говорим импорт routeTarget скажем 100 двоеточие 10 для vrf2 мы говорим импорт 100 двоеточие 2 здесь мы говорим импорт 100 двоеточие 1 то есть маршрут то есть маршрут па2 получает bgp апдейт и начинает проверять настройку своих vrf и смотрит может ли он импортировать этот маршрут в какую-либо из vrf в частности в частности если к нам прилетит апдейт помеченный routeTarget 102.2

то такой маршрут поместится в vrf номер 2 и после этого после этого может быть спокойно передан либо по bgp маршрутизатору c2 либо же он может быть например заредистрибутирован в успех в дайснесс уже передан по успеху уже передан по успеху таким образом таким образом заказчик например как раз красный заказчик узнает о префиксах которые находятся на всех его сайтах вопрос к вам на понимание соответственно если у меня есть два заказчика красный и зеленый как мне сделать так чтобы их префиксы не смешивались какие параметры должны быть уникальны процентов

дар 새�pal беды российских Да, вот Алексей, Булат, Виктор. Да, дали правильный ответ. Действительно, раут-таргет. Смотрите, root-distinguisher, root-distinguisher, вы просто не сможете, на самом деле, настроить одинаковым для двух VRF в пределах одного маркетизатора. Ну, вы сможете. Что касается комментария Василия, имена VRF могут быть абсолютно любые, на самом деле. То есть, имя VRF – это просто описательный параметр. Сама VRF характеризуется набором root-distinguisher и root-target. То есть, теоретически, у вас слева может называться VRF-red, а справа, я не знаю, VRF-blue, условно говоря. Но это не помешает передавать между ними маршрутами.

То есть, основное – это внимательно следить, какие raw-target вы экспортируете и какие raw-target вы импортируете. Помимо всего прочего, когда вы маршрут экспортируете, вы можете туда навесить несколько raw-target. И импорт делать вы можете также на основе нескольких raw-target. Мы о нескольких raw-target мы с вами еще поговорим, когда будем говорить немножко более расширенные сценарии L3VPN. Л경 and Train