L3VPN

Routing (Control plane)

VPN-IPv4 NLRI format - только control plane: MPLS label | Type | Administrator | Assigned Number | IPv4 Prefix | Mask

• Mask : /32 = /120
• Route Distinguisher: Type | Administrator | Assigned Number

  Administrator - может быть двух типов: 2-байт (AS number), 4-byte (router ID = Lo0 address).

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

Уникальность RD:

• для L2VPN и VPLS c l2vpn-use-bgp-rules - обязательно уникальный RD.
• для L2VPN и VPLS с mesh-group - обязательно уникальный RD.
• для других типов VPN - не обязательно! НО горячо рекомендуется делать RD уникальным (для разных PE в рамках одного RI) - так будет однозначно понятно от какого PE прилетел NLRI.

automatic RD:

set routing-options route-distinguisher-id 172.30.5.3

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

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

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

Прикрепляется к маршруту либо явно внутри VPN, либо через export policy - более гибкий метод, при котором можно создавать разные топологии.

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

Routing tables:

• inet.0: IGP, IBGP learned routes.
• inet.3: RSVP/LDP learned Lo0 ip addresses.
• mpls.0: MPLS forwarding info
• vpn-name.inet.0: все unicast IPv4 локального CE, статические маршруты внутри VRF, маршруты от remote PE.
• bgp.l3vpn.0: все VPN-IPv4 NLRI маршруты от удаленных PE.

Не важно LDP или RSVP будет у вас на сети. Можно использовать оба, можно использовать какой-то один. Главное, чтобы были Lo PE-роутеров в net.3

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

CE1 <static> PE1 <mpls> P <mpls> PE2 <static> CE2

Между CE и PE - маршрутизация (static, bgp, ospf). CE присылает свои префиксы, но ISP должен отделить эти префиксы от других и поместить с отдельную таблицу. Для этого клиент заводится в routing-instance (vrf).

PE должен передать принятые префиксы от клиента другому PE на удаленный конец, и затем отдать их удаленному CE2. Используем iBGP между PE. В момент отправки префиксов с PE, нужно пометить их. Добавляем некое число - route-destinguisher (RD) - не идентифицирует клиента, просто делает префикс уникальным внутри процесса BGP. RD должен быть уникальным в пределах всей сети, поэтому зачастую используют IDrouter:число. RD - часть NLRI.

Типы RD:

1. AS[2 byte]:идентификатор клиента[4 byte]
2. AS[4 byte]:идентификатор клиента[2 byte]
3. router-ID[4 byte]:идентификатор клиента[2 byte] - можно руками не задавать, а поручить это маршрутизатору.

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

NLRI - абстрактная структура данных. Роутеры до установления сессии должны совпадать хотя бы по 2-м address family.

Включаем protocols bgp family inet-vpn any - только после этого BGP будет способен передавать новые NLRI. По умолчанию, если в конфиге указывается какая-то конкретная family, то требуется указать все family, которые будут передаваться через MP-BGP. То есть добавляем сюда и family inet обязательно.

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

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

Route target (RT) - не часть NLRI, это атрибут, который передается внутри объекта вместе с NLRI. RT - extended community типа 2. По сути будет определять какому 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.

• LSP на PE1 в inet.3: PE2: push 20 -> P. BGP резолвит next-hop для PE2, подставляет в inet.0.
• P смотрит в mpls.0: 20 pop.
• На PE2 прилетает голый ip пакет. PE2 делает lookup в inet.0, т.к. интерфейс, с которого пришел пакет - принадлежит master RI и сам пакет - просто ip. В inet.0 не будет нужного маршрута => тоже схема не рабочая.

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

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

• Исходный VRF каждому пакету выделяет уникальную для себя метку. Пакет будет иметь следующий вид: label:RD:prefix/mask.
• Добавлять метку будет egress, удаленный PE2 роутер. Поэтому выделенную метку нужно проанонсировать с PE1 на PE2 по MP-BGP. Family vpn: label:prefix/mask.
• Т.к. на PE2 префикс прилетает с меткой (смотрим в таблицу bgp.l3vpn vpn label), то для PE2 это означает, что с другой стороны пакеты ждут с этой меткой. Т.е. PE2 добавляет выделенную метку, затем resolve next-hop. В нашем случае произойдет следующее: push 20 (для LSP) push 50 (для VRF) -> P.
• На P делается 20 pop.
• На PE1 приходит пакет: 50:RD:prefix/mask. Пакет попадает в mpls.0, где должна быть запись: 50: pop -> vrf1. Такая запись будет создана, как только будет создан сам VRF (ему назначается определенная метка и запись инсталлируется в mpls.0).
• На PE1 далее метка снимается, RD снимается, пакет идет на второй lookup внутри таблицы vrf1. И далее пакет направляется к нужному next-hop, согласно таблицы vrf1.

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

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

В каких случаях нам может потребоваться делать второй lookup внутри VRF: если хотим осуществлять какие-то дополнительные функции для клиентов на основании ip внутри VRF - посчитать трафик, пофильтровать, пополисить... по ip заголовку. vrf-table-label заставляет роутер назначать метку на VRF и делать второй lookup. В основном этой схемой и пользуются. При включенном vrf-table-label PE начинает передавать Direct маршруты RR (или ibgp PE)

Но на самом деле Juniper по дефолту работает так: метка назначается не на VRF, а на next-hop, с которого исходно пришли клиентские маршруты. Каждому next-hop своя метка. Т.о. на PE2 в mpls.0: 51 pop -> CE1 next-hop, 52 pop -> CE2 next-hop. Это позволяет не делать второй lookup.

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.

GRE

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

• gre-туннули должны быть добавлены в inet.3 (т.к. VPN ревозвится в net.3)
• на туннельных интерфейсах должен быть включен MPLS (для лукапа меток под клиентский VPN (RI))

Config (минимальный для VRF, PE<>CE - static)

routing-instances {
   rabbit {
       instance-type vrf;
       interface ge-0/0/0.10;
       route-distinguisher 10.200.86.5:0001;
       vrf-target target:1111:0001;
       routing-options {
           static {
               route 11.11.11.11/32 next-hop 192.168.55.2;}}}}

bgp {
       group in {
           type internal;
           local-address 10.200.86.5;
           family inet {
               any;}                           
           family inet-vpn {
               any;}
           neighbor 10.200.86.3;
           neighbor 10.200.86.1;}}
mpls {
       label-switched-path dalw-oban {
           to 10.200.86.3;

VRF-import / VRF-export

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

- import политика может применяться несколько. Должен быть последний term: the reject. Исключение - если вся политика - это then reject.

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

Export политики на ibgp сессии между PE (или PE-RR) не влияют на передачу маршрутов в рамках vrf. Если хочется, чтобы export policy на BGP сессии также играло роль - включаем:

set protocols bgp (group|neighbor) vpn-apply-export 

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

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

Пример настройки:

blair> show configuration routing-instances oak    
instance-type vrf;
interface ge-0/0/0.600;  
route-distinguisher 10.200.86.1:100;
vrf-import import-to-oak;
vrf-export export-from-oak;

blair> show configuration policy-options
policy-statement export-from-oak {
  term 1 {
       from {
           route-filter 172.17.0.0/24 orlonger;
       then {
           community add vpn-oak;
           accept;
   term defaul {                       
       then reject;
policy-statement import-to-oak {
   term 1 {
       from {
           community vpn-oak;
           route-filter 172.17.0.0/24 orlonger;
       then accept;
   term defaul {
       then reject;
community vpn-oak members target:1111:100;

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

blair# set routing-instances test vrf-target import target:1111:100    
blair# set routing-instances test vrf-target export target:1111:101

Route-origin

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

policy-options {
community my-soo { 
members origin:100:1;

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 сессия флапает, так что осторожней!

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

family route-target {  
    advertise-default; 
    external-paths number; 
    prefix-limit number;

CE<>PE eBGP

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

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

1. На PE1 в VRF под протоколом BGP: advertise peer-as - отключает split horizont. AS path поменяется: 10 65000 *. СЕ2 принимает маршрут, но должен его отбросить, т.к. в AS-path видит свою AS => на CE2 отключаем проверку на loop: routing-options autonomous-system loops 2.
2. На РЕ1 в VRF под протоколом BGP group <*>: as-override - отключает split horizing + ищет в AS-path соседскую AS и заменяет ее на свою. Новый AS-path: 10 10. На CE2 проблемы не возникнет. переустанавливает сессию.
3. Если у клиента private AS => remove private. Можно включить во всех уровнях иерархии. Удаление private AS происходит при передаче маршрута (не приеме). Удаляет левую крайнюю private AS. Если после нее идет public AS, то на этом механизм останавливается и не ищет private AS далее. В случае, если хотим передать ebgp пиру с private AS префикс, где уже указана его AS, то роутер не будет удалять private AS, а следовательно и передавать префикс пиру. То есть по факту для решения проблем с лупами AS в рамках l3vpn лучше использовать - as-override. no-peer-loop-check - позволяет удалить private AS даже в таком случае (c 15.1 ветки)
4. На PE1 внутри VRF настраиваем AS CE1: routing-options autonomous-system <AS-CE1> + routing-instance <instance> routing-options autonomous-system independent-domain - исходные атрибуты BGP от CE1 сохраняются в новый атрибут: outer-set, который добавится при анонсе в iBGP провайдера. На PE2 тоже настраиваем independent-domain, который раскроет outer-set. Т.о. при передаче префикса CE2 AS-path не будет заполнен (при iBGP AS-path пустой). Внутри VRF настраиваем internal BGP. Также этот способ дает возможность сохранить local-preference от CE1.

CE<>PE OSPF

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

• Внутри area - LSA1 (router), LSA2(network) - описание топологии.
• Между area - LSA3 (summary) - внутренние сети.
• LSA 5 (external) - внешние маршруты.

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

• intra-area (LSA1, LSA2)
• inter-area (LSA3)
• external (LSA5)

Split horizont: area 0 - центральная. Все остальные area могут подключаться только через area 0. Все, что пришло из некой внешней area - не передается в area 0, т.к. оно впринцепе может прийти только из area 0.

Sham-link

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

Внутри VRF настраиваем OSPF, включаем в него интерфейс в сторону клиента. В core - iBGP, LSP.

1. A: отправляет свой Lo 10.0.0.1 в area как LSA1.
2. PE1: в RI попадает 10.0.0.1 как LSA3.
3. PE1: inet.0: 10.0.0.1/32 - [OSPF] -> A.
4. Все маршруты из RI передаются по iBGP.
5. PE2 получит анонос сети 10.0.0.1/32 ререз BGP. vrf.inet.0: 10.0.0.1/32 - [BGP] -> LSP.
6. Требуется сеть из BGP передать по OSPF. Пишем policy.
7. PE2 из RI сеть будет передаваться к клиенту как LSA3.

• !!Проблема 1: при поднятии OSPF клиенту требуется одна area.
• !!Проблема 2: по факту клиенту требуется объединить 2 своих роутера в одну сеть => маршруты от СЕ1 должны приходить как LSA1.

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

1. Придумать новый NLRI, повторяющий структуру LSA1. Но ведь итак для L3VPN уже есть свой NLRI, засовывать в него еще NLRI - уже страшно. Поэтому...
2. PE1 и PE2 требуется соединить с помощью sham-link. Роутеры при этом будут как бы в одной area и будут флудить между собой LSA1.

Задаем sham-link:

1. Создаем отдельный unit на Lo, заносим его в RI. PE1: 1.1.1.1, PE2: 1.1.1.2
2. Указываем local-end, remote-end.
3. Чтобы роутеры установили соседство - нужно отправить hello в LSP (между PE) => Lo уделанного PE мы должны получить по iBGP.

PE1: inet.0: 1.1.1.2 - [BGP] -> LSP.

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

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

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

PE2: vrf.inet.0: 
*10.0.0.1/32 - [OSPF/10] -> shamlink.0
 10.0.0.1/32 - [BGP/170]  -> LSP

При отправке пакета с dest = 10.0.0.1/32 будет также выбран маршрут, изученный по OSPF. Но shamlink - некая абстракция и в передаче трафика не участвует.

На самом деле умный роутер делает все маршруты, доступные через shamlink - скрытыми, чтобы их нельзя было использовать. А изученные по BGP - станут активными.

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

- Если используем vrf-target - то все само придет, т.к. при таком варианте передаются все маршруты, находящиеся в VRF.

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

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

Configuration

blair> show configuration routing-instances
beer {
   instance-type vrf;
   interface ge-0/0/0.510;
   interface lo0.1;
   route-distinguisher 10.200.86.1:500;
   vrf-target target:1111:500;
   protocols {
       ospf {
           export beer-l3vpn;
           sham-link local 1.1.1.1;
           area 0.0.0.0 {
               sham-link-remote 2.2.2.2;
               interface ge-0/0/0.510 {
                   interface-type p2p;
               }
               interface lo0.1;
blair> show configuration interfaces lo0.1
family inet {
   address 1.1.1.1/32;

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

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

policy-statement export-rabbit { - полиси применяется для vrf-export внутри VRF
	term 1 {
		from {
			route-filter 192.168.55.0/24 orlonger;
			prefix-list CE-lo;}
		then {
			community set rabbit;
			accept;}}
	term 2 {
		then reject;}}
prefix-list CE-lo {
	10.10.86.5/32; - sham-link
	11.11.11.11/32; - Lo CE1
	22.22.22.22/32; - Lo CE2
	33.33.33.33/32; - Lo CE3}
community rabbit members target:1111:0001;

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

blair# set routing-instances beer protocols ospf area 0.0.0.0 sham-link-remote 2.2.2.2 metric 700

Проверка

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

blair> show ospf database instance beer
   OSPF database, Area 0.0.0.0
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   1.1.1.1          1.1.1.1          0x80000017    59  0x22 0x310f  60
Router  *172.17.0.2       172.17.0.2       0x80000017    55  0x22 0xcffa  60
Summary  172.17.0.1       1.1.1.1          0x80000004    39  0xa2 0x4ca9  28
   OSPF AS SCOPE link state database
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   2.2.2.2          1.1.1.1          0x80000002    66  0xa2 0xa157  36
Extern   192.168.86.52    1.1.1.1          0x80000004    39  0xa2 0x7697  36

blair> show route table beer.inet.0
beer.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32         *[Direct/0] 00:15:29
                   > via lo0.1
2.2.2.2/32         *[BGP/170] 00:03:09, localpref 100, from 10.200.86.7
                     AS path: I
                   > to 192.168.86.10 via ge-0/0/0.60, label-switched-path blair-to-lagavulin
172.17.0.1/32      *[BGP/170] 00:00:11, MED 1, localpref 100, from 10.200.86.7
                     AS path: I
                   > to 192.168.86.10 via ge-0/0/0.60, label-switched-path blair-to-lagavulin
172.17.0.2/32      *[OSPF/10] 00:00:21, metric 1
                   > to 192.168.86.58 via ge-0/0/0.510
192.168.86.52/30   *[BGP/170] 00:00:11, localpref 100, from 10.200.86.7
                     AS path: I
                   > to 192.168.86.10 via ge-0/0/0.60, label-switched-path blair-to-lagavulin
192.168.86.56/30   *[Direct/0] 01:30:08
                   > via ge-0/0/0.510
192.168.86.57/32   *[Local/0] 01:30:08
                     Local via ge-0/0/0.510
224.0.0.5/32       *[OSPF/10] 01:30:11, metric 1
                     MultiRecv

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

blair> show ospf neighbor instance beer
Address          Interface              State     ID               Pri  Dead
192.168.86.58    ge-0/0/0.510           Full      172.17.0.2       128    33
2.2.2.2          shamlink.0             Full      2.2.2.2            0    3

blair> show ospf database instance beer
   OSPF database, Area 0.0.0.0
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *1.1.1.1          1.1.1.1          0x8000001c     6  0x22 0x3b7b  60
Router   2.2.2.2          2.2.2.2          0x80000017     7  0x22 0xdbe4  60
Router   172.17.0.1       172.17.0.1       0x8000001f     8  0x22 0x3f8a  60
Router   172.17.0.2       172.17.0.2       0x80000019     7  0x22 0xcbfc  60
   OSPF AS SCOPE link state database
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   1.1.1.1          2.2.2.2          0x80000006     7  0xa2 0xa94b  36
Extern  *2.2.2.2          1.1.1.1          0x80000005     6  0xa2 0x9b5a  36

blair> show route table beer.inet.0
beer.inet.0: 8 destinations, 10 routes (8 active, 0 holddown, 2 hidden)
1.1.1.1/32         *[Direct/0] 00:20:59
                   > via lo0.1
2.2.2.2/32         *[BGP/170] 00:08:39, localpref 100, from 10.200.86.7
                     AS path: I
                   > to 192.168.86.10 via ge-0/0/0.60, label-switched-path blair-to-lagavulin
172.17.0.1/32      *[BGP/170] 00:03:14, MED 1, localpref 100, from 10.200.86.7
                     AS path: I
                   > to 192.168.86.10 via ge-0/0/0.60, label-switched-path blair-to-lagavulin
172.17.0.2/32      *[OSPF/10] 00:03:28, metric 1
                   > to 192.168.86.58 via ge-0/0/0.510
192.168.86.52/30   *[BGP/170] 00:03:14, localpref 100, from 10.200.86.7
                     AS path: I
                   > to 192.168.86.10 via ge-0/0/0.60, label-switched-path blair-to-lagavulin
192.168.86.56/30   *[Direct/0] 01:35:38
                   > via ge-0/0/0.510
192.168.86.57/32   *[Local/0] 01:35:38
                     Local via ge-0/0/0.510
224.0.0.5/32       *[OSPF/10] 01:35:41, metric 1
                     MultiRecv

blair> show route table beer.inet.0 hidden
beer.inet.0: 8 destinations, 10 routes (8 active, 0 holddown, 2 hidden)
172.17.0.1/32       [OSPF] 00:00:44, metric 2
                   > via shamlink.0
192.168.86.52/30    [OSPF] 00:00:44, metric 2
                   > via shamlink.0

• Если у клиента с двух сторон разные area:

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

По факту LSA3 и LSA5 - одинаковые по структуре - маршрут, но имеют разный приоритет при выборе активного пути.

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

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 не поддерживают такую фичу.

• Если у клиента:

1. Одинаковые Domain ID.
2. Есть другой протокол, из которого сеть пришла в OSPF как external.
3. Внутри сети клиента по OSPF этот маршрут будет распространятся как LSA5.
4. Между PE маршрут передается по iBGP, к удаленному PE приходит как LSA3.

Как исправить:

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

• Если исходно маршрут пришел как LSA1, LSA2, LSA3 - его превращаем в LSA3.
• Если маршрут пришел как LSA5 - превращаем его в LSA5.

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

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

• OSPF route type - тип изначального LSA.
• OSPF Domain ID - обычно закодирован как 4 byte IP address
• OSPF router-id - требуется только при использовании sham-link

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

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

РЕ генерирует LSA3, когда route type - internal и передает Domain ID community в соответствии в тем, какой сконфигурирован в RI.

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

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

CE1> show route protocol ospf  
inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
1.1.1.1/32         *[OSPF/150] 18:38:53, metric 0, tag 3489662039
                   > to 192.168.86.53 via ge-0/0/0.500
2.2.2.2/32         *[OSPF/150] 18:36:15, metric 0, tag 3489662039
                   > to 192.168.86.53 via ge-0/0/0.500

Configuration

[edit policy-options policy-statement export-vpn-beer term 1 then]
       community add vpn-beer { ... }
+      community add domain-beer;
[edit policy-options policy-statement import-vpn-beer]
+    from community domain-beer;
[edit policy-options]
+   community domain-beer members domain-id:1.1.1.1:0;
[edit routing-instances beer]
+    routing-options {
+        router-id 10.200.86.7;
+    }
[edit routing-instances beer protocols ospf]
+      domain-id 1.1.1.1;

• Если у клиента разные домены:

Правило трансляции действует, когда домен одинаковый. При передаче пакета генерируется еще одно специальное community, которое говорит, на удаленном PE: все пришедшие маршруты - LSA5.

Domain-ID одинаковые:

blair> show ospf database instance beer             
   OSPF database, Area 0.0.0.0
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router   172.17.0.2       172.17.0.2       0x80000035   103  0x22 0x4176  60 
Router  *192.168.86.57    192.168.86.57    0x80000004   102  0x22 0x2a53  48
Summary *172.17.0.1       192.168.86.57    0x80000003   102  0xa2 0xac55  28

При изменении Domain-ID с одной стороны - несовпадение doamin-id => маршруты прилетают как external (LSA5)

blair> show ospf database instance beer    
   OSPF database, Area 0.0.0.0
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router   172.17.0.2       172.17.0.2       0x80000038    23  0x22 0x3b79  60
Router  *192.168.86.57    192.168.86.57    0x80000007    22  0x22 0x2456  48
   OSPF AS SCOPE link state database
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len  
Extern  *172.17.0.1       192.168.86.57    0x80000001    10  0xa2 0x4984  36

• Если у клиента по краям нашего L3VPN - area1, которая в свою очередь подключается к area0 на сети клиента:

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

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

CE<>PE IPv6

p2p CE<>PE - ipv6 адрес.

на ядре MPLS на IPv4.

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

• Для этого на PE<>CE настраиваем обычную eBGP на p2p-адресах [в рамках vrf, конечно же].
• На сессии PE<>RR (или PE<>PE) включаем family inet6-vpn unicast.
• В VRF также нужно задать router-id. Делается либо через routing-options. Либо создаем новый lo.<x>, добавляем его в VRF. Он и будет router-id.
• На RR маршруты CE будут передаваться с next-hop self [должно быть настроено]. Чтобы RR смог отрезолвить next-hop, нужно каким-то способом добавить lo PE в таблицу inet6.3 адреса lo PE. (если на rr настроены протоколы динамической маршрутизации, то через них (OSPF, ISIS). Если нет таких, то можно прописать статикой с опцией receive).
• не забываем as-override на ebgp.
• Опционально: чтобы передавались direct маршруты, добавляем vrf-table-lable.

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

 bgp.l3vpn-inet6.0 - PE<>RR
 inet6.3 - RR, PE
 <vrf-name>.inet6.0 - PE<>CE, PE<>PE

Пример конфига:

• PE:

Interface               Admin Link Proto    Local                 Remote
lo0.2                   up    up   inet     172.30.5.38         --> 0/0
                                  inet6    fd17:f0f4:f691:5::26
ge-0/0/0.325            up    up   inet6    fc09:c0:ffee::d/126
                                           fe80::aa08:aa01:4500:0/64

r8> show configuration routing-instances c3 
instance-type vrf;
interface ge-0/0/0.325;
interface lo0.2;
route-distinguisher 172.30.5.8:300;
vrf-target target:54591:300;
vrf-table-label;
protocols {
       group c3 {
           type external;
           peer-as 64601;
           as-override;
           neighbor fc09:c0:ffee::e;

r8> show configuration protocols bgp group ibgp-rr 
family inet6-vpn {
   unicast;

• RR:

rr> show configuration routing-instances 
rib inet6.3 {
   static {
       route ::ffff:172.30.5.0/124 receive;

rr> show configuration protocols bgp 
group ibgp-clients-1 {
   family inet6-vpn {
       unicast;

Exchanging routes between VRF tables

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

• включение auto-export: задаем в [routing-options] в нужных VRF. При этом если внутри разных VRF указаны одинаковые vrf-target или vrf-import/export, то маршруты будут скопированы между 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.

blair# run show route table oak.inet.0 
oak.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
13.13.13.13/32     *[Static/5] 00:00:09
                     Discard 
192.168.86.64/30   *[Direct/0] 00:00:07
                   > via ge-0/0/0.600
192.168.86.65/32   *[Local/0] 00:00:07
                     Local via ge-0/0/0.600

После включения:

blair# run show route table oak.inet.0                             
oak.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
13.13.13.13/32     *[Static/5] 00:01:57
                     Discard
15.15.15.15/32     *[Static/5] 00:00:08
                     Discard
192.168.86.64/30   *[Direct/0] 00:01:55
                   > via ge-0/0/0.600
192.168.86.65/32   *[Local/0] 00:01:55
                     Local via ge-0/0/0.600
192.168.86.68/30   *[Direct/0] 00:00:08
                   > via ge-0/0/0.610
192.168.86.69/32   *[Local/0] 00:00:08
                     Local via ge-0/0/0.610

• использование rib-groups: per-protocol основа.

Если юзаем vrf-target - то автоматом маршруты скопируются между таблицами в рамках роутера и далее улетит по сети.

Если юзаем vrf-import | vrf-export - с выделением в политике конкретных префиксов - то только желаемые префиксы полетят далее, а все остальное скопируется только в рамках роутера. (то есть политикой мы не навесим target для всего ненужного, а для всего нужного навесим).

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

При использовании в rib-group только import-rib первой определяется таблица - источник префиксов. Далее указываются таблицы, куда будут скопированы префиксы. Следовательно, копирование маршрутов производится в одну сторону. Если нужен взаимный обмен префиксами - пишем разные rib-groups, навешиваем каждую в свой vrf.

blair# top show | compare  
[edit routing-options]
+  rib-groups {
+      oak-to-spruce {
+          import-rib [ oak.inet.0 spruce.inet.0 ];
+      }
+      spruce-to-oak {
+          import-rib [ spruce.inet.0 oak.inet.0 ];
+      }
+  }
[edit routing-instances oak routing-options]
+     interface-routes {
+         rib-group inet oak-to-spruce;
+     }
[edit routing-instances spruce routing-options]
+     interface-routes {
+         rib-group inet spruce-to-oak;
+     }

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

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

sset routing-instances spoke routing-options static rib-group oak-to-spruce

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

set routing-instances spoke protocols bgp family inet unicast rib-group c2-to-c1 
или
set routing-instances vrf-ospf protocols ospf rib-group c1-to-c2

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

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

NOTE: rib-groups applied under the [routing-options interfaces-routes] stanza copies routes in both directions.
The order of the ribs in rib-groups definition does not matter.

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

set routing-options rib-groups oak-to-spruce import-policy oak-policy

set policy-options policy-statement oak-policy term 1 from route-filter 1.1.1.1/32 exact
set policy-options policy-statement oak-policy term 1 to spruce.inet.0
set policy-options policy-statement oak-policy term 1 then accept
set policy-options policy-statement oak-policy term 2 to spruce.inet.0
set policy-options policy-statement oak-policy term 2 then reject

Hub-and-spoke

Hub - центральный узел, с которым соединяются остальные 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.

QoS

На 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 <name> 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

"Отдельный интерфейс для интернета и для VPN-трафика". В отличие от Option 1.2, здесь сам PE маршрутизирует клиента в интернет. Хотя подключается так же - через отдельный влан или даже физический интерфейс. Маршруты в интернет хранятся в VRF PE маршрутизатора. Стало быть, маршруты клиента с его белыми адресами тоже (для обратного трафика).

Option 2.2

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

Суть в том, что в VRF содержатся маршруты в интернет (0/0, или чуть больше, или вообще FullView в худшем случае), и отдаются клиенту. Дальнейший путь клиентского трафика, который не подошел к VPN-маршрутам, лукапится из главной таблицы через операцию "next-table" (т.е. 0/0 в VRF с next-table master в качестве некст-хопа. Тогда все, что не проанонсировано удаленными сайтами пойдет по дефолту). Но все-равно нужен отдельный линк или влан между PE-CE, чтобы обратный трафик как-то попадал к клиенту. Т.е. еще раз - трафик от клиента в интернет идет через VRF, некстхоп лукапится из master (если некстхоп - не клиентский узел на удаленном сайте), а обратно трафик идет уже минуя VRF через отделный влан/линк. Как PE различает какой трафик vpn а какой - internet: в VRF создается default route в next-table master в качестве некст-хопа. И дальше уже понятно. Да?

Option 2.3

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

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

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

Также для корректной работы такой схемы требуется, чтобы внутри VRF было перенаправление в main instance с помощью static route -> next-table.

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

Option 3

У клиент один из CE имеет интернет, и шлет default route удаленным CE. Удаленные CE доступаются и до ВПН-а и до интернета через один интерфейс. Главный CE, когда получает пакеты, назначенные в Интернет, просто шлет их туда через свой НЕ-VRF интерфейс [интерфейс в inet.0]. Ну и - да, тот CE, у которого есть интернет должен к провайдеру подключиться и через VRF и через НЕ-VRF интерфейс. То, есть, через отдельный влан. Как-то так.

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

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

Дополнительная информация

• Глава 2. Label Distribution Protocols (RSVP, LDP)
• L2VPN
• Реализация MPLS в ядре сети