Route distinguisher что это

Шпаргалка по связке VRF-MPLS-MPBGP

Доброго времени суток! Первый раз пишу о сетях и сетевых протоколах, хотя по учебе приходилось изучать очень и очень многие из них. Кроме того, в интернете целая куча документации, блогов и циклов статей по каждому из протоколов, с настройкой и прочими прелестями. Основной причиной написания этой заметки послужило то, что я составил для себя неплохую шпаргалку по протоколам MPLS, MPBGP и технологии VRF, и не хочу, чтобы она потерялась и забылась.

Механизм MPLS

Multiprotocol Label Switching — мультипротокольная коммутация по меткам была придумана для того, чтобы удобно передавать любые пакеты любых протоколов одинаково и вне зависимости от содержимого пакета или реализации протокола. Суть в том, что в каждый пакет навешивается специальная MPLS-метка, которая несет информацию о том, откуда пришел пакет и куда дальше его оправить.

Определения:

LSR — label switch router — маршрутизатор, который умеет оперировать MPLS-метками;
Label — метка — число в диапазоне от 0 до 2^20;
Ingress LSR — маршрутизатор, который является точкой входа в сеть MPLS;
Egress LSR — маршрутизатор, который является точкой выхода из сети MPLS;
LER — label edge router — любой маршрутизатор, который находится на границе сети MPLS;
LSP — label switch path — путь по которому путешествуют пакеты, грубо говоря, набор меток(10->20->30->..). Не содержится в каком-то конкретном месте, его можно увидеть только скомпоновав таблицы меток всех LSR;
FEC — forwading equivalence class — грубо говоря, префикс на который идут пакет, эквивалентен для разных сетей(прим. если отправить пакет на 172.16.0.1 и 172.16.0.2 префикс 172.16.0.0/24 является FEC для этих пакетов).

Downstream — LSP от ingress LSR до Endgress LSR, от входа в сеть до выхода;
Upstream — наоборот, от выхода ко входу в сеть.

Для каждого FEC строится свой путь из меток и самая прелесть в том, что пакет не нужно разворачивать во время передачи на очередной роутер. Судьба пакета, то есть его путь(LSP) предопределен заранее.

Топовая гифка с визуализацией механизма из статьи из «Сетей для самых маленьких».

Механизм VRF

В связке с MPLS этот механизм позволит передавать трафик частных сетей через большую сеть провайдера по меткам. Просто для каждой частной сети навесить свою специальную сервисную метку.

Гифка с визуализацией работы двух механизмов вместе. Зеленые квадратики — транспортные метки, а желтый и серый — сервисные.

Протокол MPBGP

Хорошо, пакеты передавать мы научились, но надо же обменяться маршрутами! Для того, чтобы построить тот самый LSP и иметь возможность гонять пакеты с данными. Прелесть MPLS-сети заключается в том, что «умными» являются только граничные маршрутизаторы, в которых есть по несколько виртуальных маршрутизаторов, в каждом своя таблица маршрутизации с маршрутами клиента. Учитывая это нам нужен протокол динамической маршрутизации, который сможет установить соседство между удаленными маршрутизаторами. На помощь приходит IBGP, а точнее его улучшение — MPBGP — Multiprotocol BGP. Multiprotocol означает то, что теперь можно передавать маршруты всех типов, а не только ipv4.

Определения:

RD — route distinguisher — уникальная приставка к префиксу в VPNv4. Формата [ASNumber:уникальное число:ipv4 маршрут], например, 64500:100:10.0.0./24. Эта штука используется для того, чтобы разделить одинаковые маршруты разных VPN сетей;
RT — route target — уникальное число у каждого VRF`а. Формат такой же как у RD. Существует для того, чтобы правильно отдать маршрут в нужный VRF. Может быть на импорт и на экспорт.

Еще одна крутая гифка, которая иллюстрирует работу всех трех механизмов в совокупности.

Заключение

Это была супер краткая выжимка, за наиболее полной информацией обращаться по ссылкам, которые я дал в начале заметки. На этом у меня все, спасибо за внимание!

Источник

Внедрение Multicast VPN на Cisco IOS (часть 3 — BGP Auto-Discovery)

В прошлых выпусках мы с Вами познакомились с понятиями Default MDT, типами корневых деревьев и разобрали два варианта реализации mVPN на основе mGRE и mLDP:

На сегодняшний день адресное семейство BGP MDT (которое уже рассматривали) является устаревшим. Ему на замену пришло новое — SAFI = multicast VPN (mVPN). Что нового приносит данное адресное семейство? Какие случаи использования могут быть? Попробуем разобраться.

Заинтересованным — добро пожаловать под кат.

Авторы идеи предложили разделить сообщение BGP update на две составляющие:

Типы BGP mVPN маршрутов

Тип туннеля определяет используемое корневое дерево и может принимать одно из следующих значений:

0 — информация не представлена
1 — RSVP-TE P2MP LSP
2 — mLDP P2MP LSP
3 — PIM-SSM
4 — PIM-SM
5 — BIDIR-PIM
6 — Ingress Replication
7 — mLDP MP2MP LSP

Дополнительные community

В зависимости от того, используется ли BGP для сигнализации многоадресного трафика в рамках VRF, у маршрутов могут появляться дополнительные коммьюнити.

VRF Route Import (Добавляется к vpnv4/vpnv6 маршрутам)
Предназначение: импортирование многоадресных маршрутов (подобную функцию в vpnv4 выполняет аттрибут Route-Target)

Route Target Constraint (RTC)
Предназначение: в случае наличия RTC, Route-Reflector (или любой другой РЕ) отправляет только «желаемый» vpnv4/vpnv6 префикс к РЕ. «Желаемый» обозначает, что на принимаемом РЕ есть один или более VRF, в который указанный префикс может быть импортирован.

Прим. Более подробно про RTC написано в RFC4684

Source-AS Extended Community (Добавляется к vpnv4/vpnv6 маршрутам)
Предназначение: передача AS информации для организации Inter-AS mVPN сценариев

PE Distinguisher Label
Предназначение: построение PPMP дерева для участия в Partitioned MDT (на текущий момент я не планирую рассматривать данное дерево в рамках цикла статей).

Поскольку с появлением SAFI mVPN функционал BGP очень расширился, то и применять данное SAFI можно для разных сценариев, в частности:

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

Сначала рассмотрим случай когда в наложенной сети сохраняется PIM, но поиск заинтересованных РЕ происходит посредством BGP. Передача данных между РЕ осуществляется посредством GRE. Данная реализация известна под кодовым именем «Profile 3».

Как и раньше, будем использовать следующую лабораторную топологию:

В первую очередь рассмотрим ситуацию, когда в рамках vrf C-ONE работает C-PIM SSM.

access-list 98 permit 230.1.1.0 0.0.0.255
ip pim vrf C-ONE ssm range 98

На РЕ устройствах поднимается новый PMSTI:

Пока что нет PIM соседства (т.к. РЕ не знают друг о друге):

Активируем адресное семейство ipv4 mvpn:

На РЕ моментально появляются соседи в рамках C-VRF:

И соответствующие (S, G) деревья:

Как РЕ смогли «увидеть» друг друга? Ответ на этот вопрос нам даст анализ BGP таблицы:

Как видим, каждый РЕ маршрутизатор создал BGP IPv4 mvpn маршрут первого типа, в котором описал себя

Обратите внимание на PTA:

На РЕ этого сайта появляется многоадресный маршрут:

В качестве RPF nbr указан адрес 1.1.1.1 — как PE4 вычисляет его? На самом деле очень просто. Это адрес BGP next-hop для источника = 11.11.11.11

Соответственно, РЕ4 генерирует PIM Join и отправляет его в рамках Default MDT:

Данный PIM Join будет получен всеми РЕ, но обработан только на РЕ1 (т.к. только на нём Join пройдет RPF проверку)

Проверим работоспособность сервиса:

Как видно, многоадресные пакеты корректно передаются через опорную сеть. При этом стоит отметить, что способ передачи пакетов ничем не отличается от того, что мы с Вами наблюдали в рамках Profile0. Т.е. пакеты долетают до всех РЕ в рамках Default MDT и уже там отбрасываются в случае отсутствия активных подписчиков.

В этом можно убедиться, сняв дамп трафика на сети как это показано на рисунке ниже (vlan характеризует интерфейс между R3 и R7):

Выше мы рассмотрели случай использования PIM SSM внутри C-VRF. Изменится ли что-либо, если будет работать PIM ASM?

На РЕ сайта появляется дополнительный туннельный интерфейс для PIM encap:

Все маршрутизаторы внутри C-VRF корректно узнают о появившихся RP и BSR устройствах в сети:

До тех пор, пока нет активного источника трафика, внутри C-VRF будут наблюдаться только (*, G) маршруты согласно обычной логике работы PIM ASM:

При этом внутри BGP домена не появляется никаких дополнительных mvpn префиксов:

«Почему?» — спросите Вы? Потому что для сигнализации многоадресного трафика C-VRF используется протокол PIM.

О возможной замене сигнализации на BGP поговорим в следующий раз.

Источник

L3VPN

Содержание

Routing (Control plane)

RD решает проблему с пересечением маршрутов между разными клиентами.

Если внутри RI будет все же указан RD, то для построения VPN будет использован более специфический RD (тот что внутри routing-instance).

RT решает проблему распространения маршрутов, задает топологию отдельного VPN. Имеет такую же структуру как и RD.

Определяет какому клиенту принадлежит префикс (routing-instance = routing-table конкретного клиента).

С помощью import policy либо явно заданного RT, можно принимать либо нет маршруты с определенным RT.

Рассмотрим такую схему:

В inet.0 хранятся IPv4, не получится туда залить наши префиксы, т.к. они имеют совсем другую структуру.

Под новые NLRI создается своя таблица: bgp.l3vpn.0. Префиксы хранятся вместе с RD. Таблица используется только на control plane, не для форвардинга.

Для форвардинга будет использоваться отдельная таблица для VRF. В ней префиксы будут храниться в обычном IPv4 формате. Для этого нужно убрать RD и разложить префиксы по нужным VRF. То есть в сети должен существовать некий идентификатор клиента.

С помощью RT можно для клиента обеспечить связность не только full mesh, но и более сложные топологии: 1 ко всем, 2 между собой, 3-й только с конкретным сайтом.

NLRI с RT прилетает на удаленный PE, префикс запихивается в нужный VRF, убирается RD, сохраняем префикс в виде IPv4. По настроенному протоколу PE<>CE передает префикс CE.

BGP: по дефолту передает только маршруты, полученные по BGP. Но с VRF другое поведение: если конфигурируем VRF и в VRF пишет target, а не policy, то роутер берет все маршруты из этого VRF, присоединяет к ним target, и отправляет по MP-BGP.

Когда проанонсированный префикс прилетает соседу (используя vpn family), тот: смотрит на target, ищет у себя target. Если VRF с таким target нет, то BGP-update отбрасывается (даже не попадают в hidden), он не знает в какую таблицу его запихнуть. Как проверить, что все-таки update прилетает: включить traceoptions. Т.е. на P роутере prefix клиента отбросится. Но до PE2 по iBGP все-равно анонс долетит, но будет скрытым (не отрезолвился next-hop, он не попал в inet.3). Если prefix все-таки не прилетает даже в hidden, то скорей всего проблема с RT.

Forwarding

Допустим, к CE1 подключено устройство с default route, пакет идет на CE1. CE1 по BGP передает трафик к PE1. На PE1 пакет попадает в vrf1.table.inet.0, т.к. на PE1 интерфейс в сторону CE1 добавлен в VRF клиента. Forwarding next-hop: P-router (по IGP). P-router принимает пакет и не знает что с ним дальше делать. Схема не рабочая

Будем туннелировать пакеты от PE1 (не обязательно в mpls). Но рассматриваем mpls.

Делаем так, чтобы PE2 понял, что lookup нужно производить внутри VRF. RT и RD не проканают, т.к. они существуют только на уровне control plane, и не причастны к передаче трафика.

Какой-нибудь header можем использовать как идентификатор, что нужно смотреть в определенной таблице. Берем MPLS заголовок.

На PE2 делается 2 lookup.

Такая схема будет работать только если включить vrf-table-label.

Cisco по дефолту назначает метки для prefix. Но это не очень удобно, когда от клиента приходит много префиксов и тем самым занимается ASIC для хранения всех этих меток.

When using network commands like ping, traceroute, and ssh, the routing-instance switch is used to specify the routing table that should be used to forward packets for the session. By default, the router will use the inet.O table not the VRF table.

By default, an egress PE that has an Ethernet VRF interface cannot perform both a pop of the MPLS label and an ARP for packets that come from the core. Therefore, an ARP must be performed by the egress router prior to receiving packet from the core. This can be achieved simply by receiving at least one route from the connected CE (which causes an ARP to occur to determine next hop). Also, a static route can be configured within the VRF instance that points to the connected CEo This is generally sufficient. However, if it is necessary to ping the VRF interface without adding routes to the VRF table, vrf-table-label or a VT interface can be used to allow for both a pop and ARP operation by the egress router.

Если вдруг вместо MPLS для форвардинга используется GRE, то:

VRF-import / VRF-export

Если требуется передача не всех маршрутов, а специфических маршрутов, то вместо vrf-target будем использовать vrf-import/vrf-export.

— export политика тоже должна иметь последний term: the reject. Лучше делать then community [target] add.

Сначала отработает VRF, потом BGP.

Для l2vpn в vrf-export нужно делать then community add [не set], потому что при настроенном set затрутся служебные L2-info extended community.

Либо можно использовать такой вариант, если нужны просто разные target на import и export:

Route-origin

По сути имеет только вид extended-community, но функционально не отличается от обычного. Обращаться с ним как с обычным!

Route-target filtering

Уменьшает кол-во служебного трафика. По сути удаленный PE->PE [или RR->PE] посылает только маршруты тех vrf, которые запрашивает локальный PE.

По дефолту на локальный PE приходят маршруты всех vrf на сети и устанавливаются в таблицы vrf только те, target которых есть на локальном роутере.

Используется таблица: bgp.rtarget.0. Предаются новые target NLRI вида: 200:200:102/96 = as:rt/mask

На локальном PE, где был создан vrf, сразу генерируется NLRI на основании vrf-import target. Остальные PE [или RR] узнают префиксы каких vrf слать этому PE.

Фильтрация включается на ibgp сессии между PE [или на ibgp c RR]. Ну понятно, что при включении новой family сессия флапает, так что осторожней!

Можно задавать дополнительные параметры:

PE_eBGP»> CE<>PE eBGP

В настройке особенностей нет, но возникают проблемы с AS.

У клиента одна и та же AS с двух сторон (AS 65000) => PE1 (AS 10) получает префикс с AS-path 65000 * => на PE2 сработает split horizing, и он не будет анонсировать CE2 => решаем проблему.

PE_OSPF»> CE<>PE OSPF

Общие сведения об OSPF

Внутренний порядок выбора маршрутов, до попадания в routing-table:

Sham-link

Если все это применить к L3VPN.

Делаем так, чтобы из PE2 VRF к клиенту вылетела LSA1. LSA1 содержит в себе линки, а мы при передаче от клиента к RI превратили эту информацию в маршруты, которые дальше стали анонсироваться по BGP. Из маршрутов линки обратно сделать не получится. Как исправить?

Обязательно нужно в policy (vrf-import, vrf-export) добавить адреса Lo. иначе ничего не заработает.

Все заработало, к CE2 улетел LSA1.

НО! произошло небольшое изменение: маршрут 10.0.0.1/32 прилетел на PE2 в RI, как известный по OSPF и был выбран активным.

НО! на удаленный PE2 обязательно должен прийти маршрут CE1, полученные по BGP (для форвардинга) и OSFP (для распространения LSA1). В итоге на удаленном PE в vrf.inet.0 должны быть hidden маршруты, изученные по ospf.

— Если используем policy, то нужно не забыть, что OSPF маршрут нужно отправить по BGP на удаленный PE.

Sham-link годится только в случае, когда объединяются роутеры клиента в одной area и когда критично принимать именно LSA1, как было бы без вмешательства ISP.

Configuration

Со стороны удаленного РЕ конфиг аналочигный.

при использовании policy для vrf:

Также, если рассматривать топологию ospf домена клиента в целом, то наверняка между различными site, клиентские роутеры будут подключены не только через нашу сеть, но буду иметь дополнительные резервные/основные линки. Таким образом, клиент может попросить сделать линк через нашу сеть резервным/основным. Сделать это можно с помощью регулирования ospf-метрики на shamlink.

Проверка

До включения sham-link

После включения sham-link

т.к. соседство по OSPF должно быть внутри одной area, то shamlink не поднимется.

Domain ID

OSPF Domain ID используется, когда передаются маршруты между одинаковыми или разными доменами через MPLS сеть. Domain ID передается как extended community внутри MP-BGP вместе с OSPF route-type и OSPF router ID community.

Фича позволяет передавать на удаленный конец LSA1, LSA2, LSA3 как LSA3.

Также передаются LSA5, LSA7 как LSA5.

Stub и totally-stubby не поддерживают такую фичу.

Вводится правило трансляции типов LSA:

Как удаленный PE узнает что было с другой стороны?

BGP использует следующие extended community:

Генерируется автоматически. Когда iBGP передает OSPF маршрут, роутер смотрит как исходно пришел маршрут, создает для него соответствующее community, куда записывает тип LSA.

Удаленный PE смотрит тип, применяет правило трансляции.

Если Domain ID не задан с обоих концов в VRF, то это тоже является совпадением по Domain ID.

PE при передаче CE LSA также помечает из route tag. Пример: tag 3489662039. Рассчитывается автоматически, но можно и задать вручную.

Configuration

LSA3 дойдет до CE2 (area1), но ABR не отправит LSA3 в area0, т.к. это backbone area (splithorizing). Поднимаем virtual-link.

При использовании IS-IS все проще: редистрибьюция из BGP в ISIS. В любом случае в ISIS получим внешний маршрут.

PE_IPv6″> CE<>PE IPv6

на ядре MPLS на IPv4.

Нужно передавать ipv6 трафик.

Будут использоваться таблицы:

Exchanging routes between VRF tables

Если нам требуется передать маршруты из одного VRF в другой, в рамках одного маршрутизатора, можно осуществить такое двумя способами:

Либо если vrf-export одного instance будет совпадать c vrf-import другого instance.

Короче, в этом методе обмен маршрутов происходит только при совпадении targets, т.е. делается на per-table основе. Передаются ВСЕ маршруты.

Работает только на локальном роутере (не передается по MP-BGP). Правда если для route leaking править vrf-export политику (добавляя туда еще community таблицы, в которую будут передаваться маршруты) то маршрут улетит и на другие PE для этого vrf. В общем, если нужен обмен только на локальном PE через auto-export, то правь именно vrf-import политику в нужных vrf.

Последним термом в таких политиках должен быть then reject.

При подобной настройке: будут передаваться только интерфейсные маршруты.

Если требуется копировать статические маршруты, то rib-group добавляем в:

Если требуется копировать протоколы маршрутизации, то rib-group добавляем в:

[тут речь идет только от клиентов, включенных по тому или иному протоколу, НО не про маршруты, полученные по MP-BGP от RR]

Если требуется копировать маршруты, известные по протоколам маршрутизации, то потребуется также скопировать и direct маршруты, для резолвинга.

С помощью policy можно контролировать какими маршрутами обмениваться.

Hub-and-spoke

Смысл: spoke-spoke связь идет не напрямую, а обязательно проходит через hub.

Как и для обычного L3VPN нужно решать проблему с AS path loop detection (as-override, remove-private).

Или при использовании OSPF между CE <> PE следить за правильностью Domain ID.

Могут возникнуть сложности, если в топологии будут spoke, подключенные напрямую к hub. Или к PE будет подключаться несколько spoke.

Требуется создание двух RI: hub, spoke. Hub PE будет иметь 2 линка в сторону CE (можно 2 unit на физическом линке).

2 RT, 2 RD (если в схеме используем RR).

Control plane: маршруты от spoke PE передаются в spoke vrf на hub PE. Hub PE передает маршруты hub CE. Hub CE в свою очередь передает эти маршруты в hub instance hub PE. Hub PE передает маршруты к Spoke site.

На ingress доступны: firewall filtering, classification, rate limiting, precedence mapping.

На egress можно использовать: filtering, но дополнительно добавив vrf-table-label, vt-interface.

EXP bits в VRF метке выставляются на основании: firewall classification, IP precedence, ingress interface.

outer label (RSVP), может быть назначена CoS конфигурацией.

Internet Access

Option 1

PE роутеры не участвуют в роутинге интернета, т.е. PE роутеры не обмениваются маршрутами между master и vrf таблицами маршрутизации. Предоставление интернета в рамках опции 1 называется «non-VRF Internet Access».

Настраиваются политики на PE + static route [в routing-instance routing-options] с next-hop table inet.0. Оттуда уже резолвиться в инет.

Option 1.1

«Пусть строят как хотят». VPN-клиенты не получают интернет от провайдера VPN-услуг, а подключают в каждой локации IPS1 или ISP2 в отдельный маршрутизатор, и далее разруливают трафик как хотят. В каждой локации свой интернет.

По-умолчанию Juniper поддерживает именно эту опцию.

Option 1.2

В отдельном влане (CE-PE) идет L2 по провайдерской сети до провайдерского роутера, который раздает интернет. Можно вообще отдельным кабелем воткнуться между CE и PE. Сам PE ничего не знает про интернет и не обязан хранить маршруты в интернет, либо маршруты клиента, чтобы маршрутизировать что-либо в ту или иную сторону. В Juniper для этого предусмотрено либо L2VPN либо CCC.

Все VPN-ы, подключенные к данному PE пойдут в интернет одинаковым путем.

Option 2

PE имеет частичный или полный доступ в инет. РЕ будет перемещать маршруты между VRF и main instance.

Option 2.1

Option 2.2

«Отдельный интерфейс для обратного (который идет от Интернета к клиенту) трафика».

Option 2.3

«Все через одну дырку (Single VRF for VPN and Internet Access)».

Отдельного интерфейса не требуется. Опять же, не-ВПН трафик клиента будет лукапиться в master-е и маршрутизироваться по тамошним маршрутам в интернет. А чтобы схема работала и в обратную сторону, все клиентские анонсы будут редистрибьюированы в master.

Если клиент не использует приватные адреса, то VPN и inet связность может быть достигнута с помощью одного VRF и с помощью копирования всех маршрутов из VRF в main instance (RIB-groups).

Если клиент использует приватную и публичную адресацию, то паблик и приватные будут разделяться разными community.

Option 3

у Hub-PE в рамках vrf настраивается default, смотрящий в сторону ce-vpn. Дефолт анонсится остальным PE.

Если клиенту требуется NAT, то при такой схеме NAT делается на CE.

Источник