RouteLeacking: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
(Новая страница: «Категория:Cisco =Route Leaking= <PRE> Leaking Routes with MP-BGP Last Updated: [last-modified] (UTC) VRF’s do a good job of keeping routes sep...»)
 
Строка 264: Строка 264:
 
The answer is yes. This can be done with an export-map. But, that’s a story for another time…
  
The answer is yes. This can be done with an export-map. But, that’s a story for another time…
 
</PRE>
  
</PRE>
  +
  +
  +
<PRE>
  +
Разница между Route Distinguisher и Route Target
  +
Сетевые технологии *
  +
Ожидает приглашения
  +
Когда-то, начиная изучать MPLS и реализуемые на его основе сервисы, я уперся в два понятия — Route Target и Route Distinguisher. Информация по этим понятиям была в основном на английском языке (спасибо родителям за то что заставляли меня учить английский), на русском был или машинный перевод или общая информация, которая порождала больше вопросов, чем давала ответов.
  +
  +
В статье буду использовать выводы с оборудования Juniper, так как испытываю большую симпатию к оборудованию данного производителя, нежели к Cisco, Huawei или Broсade. Статья написана полностью мной и не является переводом, дампы трафика и выводы с оборудования взяты с собранного в GNS3 стенда (для эмуляции использовал; vSRX, Cisco IOS-XR (vXR) и IOS).
  +
  +
Для того что бы перейти к пониманию назначения Route Target и Route Distinguisher, надо понять, что такое VRF, так как часть сетевых инженеров полностью не понимают принцип работы VRF (для некоторых даже открытием является то, что VRF используется и без MPLS).
  +
  +
Итак VRF — это не маршрутизатор в маршрутизаторе, а всего лишь изоляция таблицы маршрутизации одного клиента от другого и от основной таблицы маршрутизации роутера — это надо твердо усвоить (маршрутизатор в маршрутизаторе — это например logical systems в JunOS). По сути можно провести аналогию с VLAN — между различными VLAN пакеты напрямую не передаются (между VLAN пакеты должны идти через маршрутизируемый интерфейс), так же и два VRF, живущих на одном маршрутизаторе не могут общаться друг с другом без перераспределения маршрутов, так как их таблицы маршрутизации не имеют маршрутов к друг другу.
  +
  +
Теперь мы можем перейти к основной теме статьи. Начнем с Route Destingisher (дословно различитель маршрутов). Route Distinguisher представляет из себя 64-битную последовательность вида type (2 байта):administrator(2 или 4 байта):value(4 или 2 байта). Поле type указывает в каком формате будут следующие два поля, значения которых указаны ниже:
  +
  +
image
  +
  +
Что бы понять назначение RD, разберем топологию ниже:
  +
  +
image
  +
  +
К PE-маршрутизатору подключены два клиента, но есть проблема — оба клиента имеют одно и то же приватное адресное пространство — 10.0.0.0/24. Предположим что между CE1 и PE запущен OSPF, а между CE2 и PE — RIP. На PE нам необходимо сделать перераспределение маршрутов из IGP протоколов в BGP, что бы передать маршруты клиентов на другие PE-маршрутизаторы. Для BGP это один и тот же префикс 10.0.0.0/24, поэтому перераспределен и анонсирован соседям по BGP будет только один лучший маршрут. Но нам то надо анонсировать оба маршрута. Вот тут нам на помощь приходит Route Distinguisher. Его единственной, но очень важной задачей является сделать заведомо не уникальный префикс уникальным. Получается это с помощью добавления 64-битного Route Distinguisher к искомому префиксу:
  +
  +
image
  +
  +
К примеру, имея два одинаковых префикса 192.168.1.0/24 и Route Distinguisher 100:10 и 100:20, получаем уникальные VPNv4 unicast префиксы, длинной 96 бит.
  +
  +
bgp.l3vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
  +
+ = Active Route, - = Last Active, * = Both
  +
  +
100:10:192.168.1.0/24
  +
*[BGP/170] 00:46:53, localpref 100, from 10.3.3.3
  +
AS path: I
  +
> to 10.0.0.1 via ge-0/0/1.0, Push 17, Push 17(top)
  +
  +
100:20:192.168.1.0/24
  +
*[BGP/170] 00:46:53, localpref 100, from 10.3.3.3
  +
AS path: I
  +
> to 10.0.0.1 via ge-0/0/1.0, Push 16, Push 17(top)
  +
  +
Теперь эти префиксы можно передать другим PE маршрутизаторам. Но один из моих коллег задал вот такой вопрос: как PE маршрутизатор выделяет IPv4 префикс из полученного VPNv4 префикса, если не знает значение Route Distinguisher. Тут все просто, рассмотрим BGP Update message. Для начала посмотрим, как передается обычный IPv4 префикс:
  +
  +
image
  +
  +
Как видно из BGP анонса, в теле сообщения в поле NLRI и находится префикс. С помощью расширения MP-BGP, данный протокол может обеспечивать обмен префиксами различных address family идентифицируя их различными значениями AFI/SAFI. Рассмотрим Update message, в котором будет содержаться VPNv4 префикс:
  +
  +
image
  +
  +
Так как маршрутизатор знает длину Route Distinguisher (она фиксирована и равна 64 битам) и начало VPNv4 префикса, то ему не составляет труда отбросить значение первых 64-х бит и поместить в таблицу маршрутизации клиента только IPv4 префикс:
  +
  +
red.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
  +
+ = Active Route, - = Last Active, * = Both
  +
  +
192.168.0.0/24 *[Direct/0] 00:48:11
  +
> via ge-0/0/2.0
  +
192.168.0.1/32 *[Local/0] 00:48:13
  +
Local via ge-0/0/2.0
  +
192.168.0.100/32 *[Direct/0] 00:48:37
  +
> via lo0.1
  +
192.168.1.0/24 *[BGP/170] 00:46:53, localpref 100, from 10.3.3.3
  +
AS path: I
  +
> to 10.0.0.1 via ge-0/0/1.0, Push 17, Push 17(top)
  +
  +
Думаю, что с Route Distinguisher мы разобрались, поэтому перейдем к обсуждению Route Target.
  +
  +
Для понимания назначения Route Target надо понять, что такое l3vpn. К примеру клиент хочет объединить свои географически разнесенные сайты в одну сеть с помощью сети провайдера. Применение например GRE или IPSec-тоннелей в данном случае не возможно (физически возможно — но как администрировать такую кучу тоннелей?). Так как GRE или IPSec создают тоннель типа точка-точка, то чтобы соединить например 5 сайтов клиента нам надо связать каждый сайт с каждым (full mesh топология), то есть создать вручную n(n-1)/2, то есть 5(5-1)/2=10 тоннелей. А если сайтов будет 10 или 20?? l3vpn использует механизм автоматического поиска PE маршрутизаторов, к которым подключены сайты клиента (сконфигурированы соответствующие VRF), для автоматического создания между ними LSP -тоннелей. Когда у провайдера всего один клиент, то проблем с распределением анонсов нет, так как все маршруты должны быть приняты всеми PE-маршрутизаторами. Но в реальности клиентов много, а значит между PE маршрутизаторами передается много различной маршрутной информации различных клиентов. Но PE-маршрутизаторам не нужны все маршруты, а только маршруты клиентов, которые непосредственно подключены к этому PE-маршрутизатору. Получается, что надо как-то маркировать префиксы различных клиентов, которые будут передаваться по BGP между PE-маршрутизаторами и использовать эту маркировку для фильтрации маршрутной информации на PE-маршрутизаторах. Тут нам на помощь приходит BGP, а точнее атрибут community. Community бывают двух видов стандартные и расширенные. Route Target как раз таки и является частным случаем расширенного community, имеет длину 64 бита и формат type:administrator:assigned-number (например target:65501:100):
  +
  +
image
  +
  +
Ниже показан вывод марштутов, анонсируемых по протоколу BGP, к которым прикреплены расширенные community:
  +
  +
root@PE2> show route advertising-protocol bgp 10.1.1.1 detail
  +
  +
blue.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
  +
* 192.168.1.0/24 (1 entry, 1 announced)
  +
BGP group internal-vpn type Internal
  +
Route Distinguisher: 100:20
  +
VPN Label: 16
  +
Nexthop: Self
  +
Flags: Nexthop Change
  +
Localpref: 100
  +
AS path: [100] I
  +
Communities: target:1:2
  +
  +
red.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
  +
  +
* 192.168.1.0/24 (1 entry, 1 announced)
  +
BGP group internal-vpn type Internal
  +
Route Distinguisher: 100:10
  +
VPN Label: 17
  +
Nexthop: Self
  +
Flags: Nexthop Change
  +
Localpref: 100
  +
AS path: [100] I
  +
Communities: target:2:2
  +
  +
Route Target делятся на два значения import и export. Первое предназначено для фильтрации префиксов PE маршрутизатором на приеме. Принятые префиксы в последствии будут установлены в таблицу маршрутизации соответствующего VRF ( как RT import может быть указано более одного значения, в случае его отсутствия ни одни из маршрутов не будет принят и установлен в таблицу маршрутизации). Что бы можно было на приеме произвести фильтрацию на основании community, надо, чтобы это community кто то добавил к анонсу. Для этого и используется Route Target export, значение которого будет добавлено как расширенное community к BGP анонсу (в случае отсутствия в конфигурации VRF данного занчения ни один из маршрутов данного VRF не будет передан на другие PE маршрутизаторы).
  +
  +
root@PE2> show configuration routing-instances
  +
blue {
  +
instance-type vrf;
  +
interface ge-0/0/0.0;
  +
route-distinguisher 100:20;
  +
vrf-target {
  +
import target:2:1;
  +
export target:1:2;
  +
}
  +
vrf-table-label;
  +
protocols {
  +
ospf {
  +
export bgp-to-vpn;
  +
area 0.0.0.2 {
  +
interface ge-0/0/0.0;
  +
}
  +
}
  +
}
  +
}
  +
  +
  +
Теперь, понимая различи между этими понятиями расставим все точки над i. Рассмотрим схему:
  +
  +
image
  +
  +
На схеме два PE маршрутизатора, между которыми установлена BGP сессия с address family vpnv4 unicast. На первом PE1 маршрутизаторе два VRF: red и blue, на PE2 три VRF: red, blue и black. Как видно, все сайты имеют одинаковое адресное пространство, но так как у нас сконфигурированы уникальные для данной сети RD, все префиксы становятся уникальными. Теперь надо понять, какие маршруты принимают и отдают PE маршрутизаторы.
  +
  +
PE1 имеет два VRF, согласно RT import, он должен принимать все BGP анонсы с расширенными community 2:10 и 2:11, а так же отправлять BGP анонсы с расширенными community 1:10 и 1:11 согласно RT export. Маршруты с расширенными community, не соответствующие сконфигурированным RT-import, маршрутизатор просто отбрасывает. Маршруты с RT import 2:10 маршрутизатор помещает в таблицу маршрутизации клиента red, а с RT 2:11 — в таблицу маршрутизации клиента blue. Оправляя маршруты клиента red, маршрутизатор «навешивает» на анонс расширенное community 1:10, и соответственно для анонсов клиента blue — 1:11.
  +
  +
PE2 имеет три VRF, и согласно RT import он принимает BGP анонсы с расширенными community 1:10, 1:11 и 10:10, и отправляет BGP анонсы с расширенными community 2:10, 2:11 и 20:30.
  +
  +
Так как на PE1 не сконфигурирован VRF black, то маршруты данного клиента ему не нужны, а значит, получая маршрут с расширенными community 20:30, PE1 их просто отбрасывает на основании того, что указанное в анонсе расширенное community не задано для данного маршрутизатора.
  +
  +
Бывает случаи, когда необходимо принимать маршруты со всеми расширенными community (например interAS-option B). При настройке маршрутизатора необходимо разрешить принимать все анонсы, так как это не дефолтное поведение маршрутизатора. Если маршрутизатор сконфигурирован как route-reflector, то он принимает и отдает все анонсы в не зависимости от расширенных community. Кроме того сам PE маршрутизатор может ограничить получаемые анонсы от других PE маршрутизаторов или роут-рефлекторов, тем самым уменьшая количество сигнальной информации. Но это уже тема другой статьи.
  +
  +
Спасибо за внимание! Надеюсь, я смог донести данную до читателя разницу между двумя этими с виду идентичными, но абсолютно разными по назначению понятиями.
  +
Теги:
  +
juniperrdrt
  +
Хабы:
  +
Сетевые технологии
  +
</PRE>
  +
  +
  +
* https://habr.com/ru/sandbox/99255/
  +
* https://networkdirection.net/articles/routingandswitching/mp-bgp/leakingrouteswithmp-bgp/

Версия 10:50, 19 апреля 2022

Route Leaking

Leaking Routes with MP-BGP
Last Updated: [last-modified] (UTC)

 

VRF’s do a good job of keeping routes separate. Each VRF represents a different routing table, allowing isolation between tenants.

But now imagine that you’re a small service provider. You have VRF’s for your customers and an extra VRF for your own services. How do you share routes to your services with your customers?

One way is to use MP-BGP to leak routes between VRF’s. In this scenario, BGP is aware of each of the VRF’s and their contents. It selectively shares routes between them.

In this article, we’ll run through a simple lab, and show how to use MP-BGP to leak routes. You can also use the skills you learn here in MPLS networks.

 

Consider a review of VRF-Lite and MP-BGP

[maxbutton id=”4″ text=”VRF-Lite” url=”https://networkdirection.net/VRF+Lite”][maxbutton id=”4″ text=”MP-BGP” url=”https://networkdirection.net/MP-BGP”]

 

 

 

Lab Topology

This is going to be a simple lab. In fact, we’ll only use one router. Keep in mind that in the real world, the solution will encompass many routers.

As shown below, our router has three VRF’s. Each VRF has three networks, implemented as loopback interfaces. Initially, loopbacks in one VRF will not be able to ping loopbacks in another VRF.

The initial configuration also includes an empty instance of BGP, using AS 65535.

The initial MP-BGP Config files are available for download.

 

The goals of this lab are:

All networks in VRF-C should be available to the other two VRF’s
All networks in VRF-A and VRF-B should be available in VRF-C
VRF-A and VRF-B should remain isolated from each other



 

 

Keeping Traffic Separate

Prefixes from many VRF’s can be added into BGP. This raises the question, ‘how does BGP keep the prefixes separate?’

This is especially interesting if you have overlapping IP spaces. The answer is Route Distinguishers.

 

Route Distinguishers

Key Concept: Route Distinguishers keep routes unique

 

A Route Distinguisher (RD) is a special value that is included with the prefix in the BGP database. Each VRF can have a single RD.
This means that in the BGP database, the RD distinguishes one VRF from another.

The RD is a 64-bit value, which you can format in a few different ways. The most common way is to break it into two 32-bit values, separated by a colon.

Generally, the first value is the ASN. The second value is assignable by you. For example, you may use an RD of 65000:10 in AS 65000.

When you start adding RD information to prefixes, these become VPNv4 or VPNv6 routes in BGP. This is commonly seen in MPLS networks.

 

Configuring Route Distinguishers

An RD is configured within the VRF with the rd keyword. This can be verified with show ip vrf.

 

Route Distinguishers
Router(config)#vrf definition VRF-A
Router(config-vrf)#rd 65535:1

Router(config)#vrf definition VRF-B
Router(config-vrf)#rd 65535:2          

Router(config)#vrf definition VRF-C
Router(config-vrf)#rd 65535:3

Router#show ip vrf
  Name                             Default RD            Interfaces
  VRF-A                            65535:1               Lo10
                                                         Lo11
                                                         Lo12
  VRF-B                            65535:2               Lo20
                                                         Lo21
                                                         Lo22
  VRF-C                            65535:3               Lo30
                                                         Lo31
                                                         Lo32
 

 

BGP Database

Now that our VRF’s have an RD associated with them, we need to get the prefixes into BGP. BGP treats each VRF as a separate address-family. From here, we can redistribute connected routes into BGP.

 

Route Redistribution
Router(config)#router bgp 65535
Router(config-router)#address-family ipv4 vrf VRF-A
Router(config-router-af)#redistribute connected 

Router(config-router)#address-family ipv4 vrf VRF-B
Router(config-router-af)#redistribute connected       

Router(config-router)#address-family ipv4 vrf VRF-C
Router(config-router-af)#redistribute connected
 

To verify this, use the show ip bgp vpnv4 all command. This will show all prefixes, their RD, and the associated VRF.

Keep in mind that so far, all we’ve done is make prefixes unique in BGP. We have not enabled leaking between VRF’s yet.

 

Route Redistribution
Router#show ip bgp vpnv4 all
BGP table version is 10, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65535:1 (default for vrf VRF-A)
 *>  172.16.1.0/24    0.0.0.0                  0         32768 ?
 *>  172.16.2.0/24    0.0.0.0                  0         32768 ?
 *>  172.16.3.0/24    0.0.0.0                  0         32768 ?
Route Distinguisher: 65535:2 (default for vrf VRF-B)
 *>  192.168.1.0      0.0.0.0                  0         32768 ?
 *>  192.168.2.0      0.0.0.0                  0         32768 ?
 *>  192.168.3.0      0.0.0.0                  0         32768 ?
Route Distinguisher: 65535:3 (default for vrf VRF-C)
 *>  10.10.1.0/24     0.0.0.0                  0         32768 ?
 *>  10.10.2.0/24     0.0.0.0                  0         32768 ?
 *>  10.10.3.0/24     0.0.0.0                  0         32768 ?
 

 

Sharing Routes

Route Targets

Key Concept: Route Targets Import and Export Routes

We now need to export routes from certain VRFs, and import them into selected VRF’s. This is done with Route Targets.
An RT specifies which VRF’s to export routes from, and which VRF’s to import routes into. They use the same formatting as RD’s, and they often use the same values. While they may look the same, it’s important to remember that they’re different things.

Exporting tags a prefix with the RT value. This is entered into BGP, and shared with other routers as extended communities. Hint: Make sure you enable extended communities!

Importing selects routes based on their RT, and inserts them into a VRF.

 

Exporting Routes

We start by assigning a tag to the routes in each VRF. This is done with the route-target export command.

Under the hood, this creates a BGP community that is sent to neighbours along with the prefix.

 

Exporting Routes
Router(config)#vrf definition VRF-A
Router(config-vrf)#route-target export 65535:1

Router(config)#vrf definition VRF-B       
Router(config-vrf)#route-target export 65535:2

Router(config)#vrf definition VRF-C       
Router(config-vrf)#route-target export 65535:3
 

Use the show ip bgp vpnv4 all detail command, and you will be able to see the extended community that it’s using.

 

Verify Communities
Router#show ip bgp vpnv4 all detail 

Route Distinguisher: 65535:1 (default for vrf VRF-A)
BGP routing table entry for 65535:1:172.16.1.0/24, version 11
  Paths: (1 available, best #1, table VRF-A)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    0.0.0.0 (via vrf VRF-A) from 0.0.0.0 (1.1.1.1)
      Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:65535:1
      rx pathid: 0, tx pathid: 0x0

! Additional output omitted for brevity
 

Importing Routes

We import routes by looking for any prefixes with a certain ‘tag’. In this example, we import routes into VRF-C by looking for VRF-A and VRF-B’s Route Target.

This is where the route leaking happens. Notice that we don’t share routes between VRF-A and VRF-B.

 

Importing Routes
Router(config)#vrf definition VRF-C
Router(config-vrf)#route-target import 65535:1
Router(config-vrf)#route-target import 65535:2

Router(config)#vrf definition VRF-A
Router(config-vrf)#route-target import 65535:3

Router(config)#vrf definition VRF-B
Router(config-vrf)#route-target import 65535:3
 

To verify this, simply look at the route tables.

Verifying Routes
Router#show ip route vrf VRF-A
Routing Table: VRF-A
! Output omitted for brevity

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
B        10.10.1.0/24 is directly connected, 00:00:48, Loopback30
L        10.10.1.1/32 is directly connected, Loopback30
B        10.10.2.0/24 is directly connected, 00:00:48, Loopback31
L        10.10.2.1/32 is directly connected, Loopback31
B        10.10.3.0/24 is directly connected, 00:00:48, Loopback32
L        10.10.3.1/32 is directly connected, Loopback32
      172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks
C        172.16.1.0/24 is directly connected, Loopback10
L        172.16.1.1/32 is directly connected, Loopback10
C        172.16.2.0/24 is directly connected, Loopback11
L        172.16.2.1/32 is directly connected, Loopback11
C        172.16.3.0/24 is directly connected, Loopback12
L        172.16.3.1/32 is directly connected, Loopback12
 

Optionally, you can use route-target both. The both keyword imports and exports at the same time.

Some implementations (such as IOS-XR and NXOS) let you use the auto keyword. This generates an RT value for you, based on the router-id rather than AS number.

As a final thought, you may be wondering if we can selectively import and export routes. After all, you may not want to leak every route in your VRF.

The answer is yes. This can be done with an export-map. But, that’s a story for another time…



Разница между Route Distinguisher и Route Target
Сетевые технологии *
Ожидает приглашения
Когда-то, начиная изучать MPLS и реализуемые на его основе сервисы, я уперся в два понятия — Route Target и Route Distinguisher. Информация по этим понятиям была в основном на английском языке (спасибо родителям за то что заставляли меня учить английский), на русском был или машинный перевод или общая информация, которая порождала больше вопросов, чем давала ответов.

В статье буду использовать выводы с оборудования Juniper, так как испытываю большую симпатию к оборудованию данного производителя, нежели к Cisco, Huawei или Broсade. Статья написана полностью мной и не является переводом, дампы трафика и выводы с оборудования взяты с собранного в GNS3 стенда (для эмуляции использовал; vSRX, Cisco IOS-XR (vXR) и IOS). 

Для того что бы перейти к пониманию назначения Route Target и Route Distinguisher, надо понять, что такое VRF, так как часть сетевых инженеров полностью не понимают принцип работы VRF (для некоторых даже открытием является то, что VRF используется и без MPLS). 

Итак VRF — это не маршрутизатор в маршрутизаторе, а всего лишь изоляция таблицы маршрутизации одного клиента от другого и от основной таблицы маршрутизации роутера — это надо твердо усвоить (маршрутизатор в маршрутизаторе — это например logical systems в JunOS). По сути можно провести аналогию с VLAN — между различными VLAN пакеты напрямую не передаются (между VLAN пакеты должны идти через маршрутизируемый интерфейс), так же и два VRF, живущих на одном маршрутизаторе не могут общаться друг с другом без перераспределения маршрутов, так как их таблицы маршрутизации не имеют маршрутов к друг другу. 

Теперь мы можем перейти к основной теме статьи. Начнем с Route Destingisher (дословно различитель маршрутов). Route Distinguisher представляет из себя 64-битную последовательность вида type (2 байта):administrator(2 или 4 байта):value(4 или 2 байта). Поле type указывает в каком формате будут следующие два поля, значения которых указаны ниже:

image

Что бы понять назначение RD, разберем топологию ниже:

image

К PE-маршрутизатору подключены два клиента, но есть проблема — оба клиента имеют одно и то же приватное адресное пространство — 10.0.0.0/24. Предположим что между CE1 и PE запущен OSPF, а между CE2 и PE — RIP. На PE нам необходимо сделать перераспределение маршрутов из IGP протоколов в BGP, что бы передать маршруты клиентов на другие PE-маршрутизаторы. Для BGP это один и тот же префикс 10.0.0.0/24, поэтому перераспределен и анонсирован соседям по BGP будет только один лучший маршрут. Но нам то надо анонсировать оба маршрута. Вот тут нам на помощь приходит Route Distinguisher. Его единственной, но очень важной задачей является сделать заведомо не уникальный префикс уникальным. Получается это с помощью добавления 64-битного Route Distinguisher к искомому префиксу:

image

К примеру, имея два одинаковых префикса 192.168.1.0/24 и Route Distinguisher 100:10 и 100:20, получаем уникальные VPNv4 unicast префиксы, длинной 96 бит. 

bgp.l3vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

100:10:192.168.1.0/24                
                   *[BGP/170] 00:46:53, localpref 100, from 10.3.3.3
                      AS path: I
                    > to 10.0.0.1 via ge-0/0/1.0, Push 17, Push 17(top)

100:20:192.168.1.0/24                
                   *[BGP/170] 00:46:53, localpref 100, from 10.3.3.3
                      AS path: I
                    > to 10.0.0.1 via ge-0/0/1.0, Push 16, Push 17(top)

Теперь эти префиксы можно передать другим PE маршрутизаторам. Но один из моих коллег задал вот такой вопрос: как PE маршрутизатор выделяет IPv4 префикс из полученного VPNv4 префикса, если не знает значение Route Distinguisher. Тут все просто, рассмотрим BGP Update message. Для начала посмотрим, как передается обычный IPv4 префикс:

image

Как видно из BGP анонса, в теле сообщения в поле NLRI и находится префикс. С помощью расширения MP-BGP, данный протокол может обеспечивать обмен префиксами различных address family идентифицируя их различными значениями AFI/SAFI. Рассмотрим Update message, в котором будет содержаться VPNv4 префикс: 

image

Так как маршрутизатор знает длину Route Distinguisher (она фиксирована и равна 64 битам) и начало VPNv4 префикса, то ему не составляет труда отбросить значение первых 64-х бит и поместить в таблицу маршрутизации клиента только IPv4 префикс:

red.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.0/24     *[Direct/0] 00:48:11
                    > via ge-0/0/2.0
192.168.0.1/32     *[Local/0] 00:48:13
                      Local via ge-0/0/2.0
192.168.0.100/32   *[Direct/0] 00:48:37
                    > via lo0.1
192.168.1.0/24     *[BGP/170] 00:46:53, localpref 100, from 10.3.3.3
                      AS path: I
                    > to 10.0.0.1 via ge-0/0/1.0, Push 17, Push 17(top)

Думаю, что с Route Distinguisher мы разобрались, поэтому перейдем к обсуждению Route Target.

Для понимания назначения Route Target надо понять, что такое l3vpn. К примеру клиент хочет объединить свои географически разнесенные сайты в одну сеть с помощью сети провайдера. Применение например GRE или IPSec-тоннелей в данном случае не возможно (физически возможно — но как администрировать такую кучу тоннелей?). Так как GRE или IPSec создают тоннель типа точка-точка, то чтобы соединить например 5 сайтов клиента нам надо связать каждый сайт с каждым (full mesh топология), то есть создать вручную n(n-1)/2, то есть 5(5-1)/2=10 тоннелей. А если сайтов будет 10 или 20?? l3vpn использует механизм автоматического поиска PE маршрутизаторов, к которым подключены сайты клиента (сконфигурированы соответствующие VRF), для автоматического создания между ними LSP -тоннелей. Когда у провайдера всего один клиент, то проблем с распределением анонсов нет, так как все маршруты должны быть приняты всеми PE-маршрутизаторами. Но в реальности клиентов много, а значит между PE маршрутизаторами передается много различной маршрутной информации различных клиентов. Но PE-маршрутизаторам не нужны все маршруты, а только маршруты клиентов, которые непосредственно подключены к этому PE-маршрутизатору. Получается, что надо как-то маркировать префиксы различных клиентов, которые будут передаваться по BGP между PE-маршрутизаторами и использовать эту маркировку для фильтрации маршрутной информации на PE-маршрутизаторах. Тут нам на помощь приходит BGP, а точнее атрибут community. Community бывают двух видов стандартные и расширенные. Route Target как раз таки и является частным случаем расширенного community, имеет длину 64 бита и формат type:administrator:assigned-number (например target:65501:100):

image

Ниже показан вывод марштутов, анонсируемых по протоколу BGP, к которым прикреплены расширенные community:

root@PE2> show route advertising-protocol bgp 10.1.1.1 detail 

blue.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 192.168.1.0/24 (1 entry, 1 announced)
 BGP group internal-vpn type Internal
     Route Distinguisher: 100:20
     VPN Label: 16
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [100] I
     Communities: target:1:2

red.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

* 192.168.1.0/24 (1 entry, 1 announced)
 BGP group internal-vpn type Internal
     Route Distinguisher: 100:10
     VPN Label: 17
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [100] I
     Communities: target:2:2

Route Target делятся на два значения import и export. Первое предназначено для фильтрации префиксов PE маршрутизатором на приеме. Принятые префиксы в последствии будут установлены в таблицу маршрутизации соответствующего VRF ( как RT import может быть указано более одного значения, в случае его отсутствия ни одни из маршрутов не будет принят и установлен в таблицу маршрутизации). Что бы можно было на приеме произвести фильтрацию на основании community, надо, чтобы это community кто то добавил к анонсу. Для этого и используется Route Target export, значение которого будет добавлено как расширенное community к BGP анонсу (в случае отсутствия в конфигурации VRF данного занчения ни один из маршрутов данного VRF не будет передан на другие PE маршрутизаторы).

root@PE2> show configuration routing-instances 
blue {
    instance-type vrf;
    interface ge-0/0/0.0;
    route-distinguisher 100:20;
    vrf-target {
        import target:2:1;
        export target:1:2;
    }
    vrf-table-label;
    protocols {
        ospf {
            export bgp-to-vpn;
            area 0.0.0.2 {
                interface ge-0/0/0.0;
            }
        }
    }
}


Теперь, понимая различи между этими понятиями расставим все точки над i. Рассмотрим схему:

image

На схеме два PE маршрутизатора, между которыми установлена BGP сессия с address family vpnv4 unicast. На первом PE1 маршрутизаторе два VRF: red и blue, на PE2 три VRF: red, blue и black. Как видно, все сайты имеют одинаковое адресное пространство, но так как у нас сконфигурированы уникальные для данной сети RD, все префиксы становятся уникальными. Теперь надо понять, какие маршруты принимают и отдают PE маршрутизаторы.

PE1 имеет два VRF, согласно RT import, он должен принимать все BGP анонсы с расширенными community 2:10 и 2:11, а так же отправлять BGP анонсы с расширенными community 1:10 и 1:11 согласно RT export. Маршруты с расширенными community, не соответствующие сконфигурированным RT-import, маршрутизатор просто отбрасывает. Маршруты с RT import 2:10 маршрутизатор помещает в таблицу маршрутизации клиента red, а с RT 2:11 — в таблицу маршрутизации клиента blue. Оправляя маршруты клиента red, маршрутизатор «навешивает» на анонс расширенное community 1:10, и соответственно для анонсов клиента blue — 1:11.

PE2 имеет три VRF, и согласно RT import он принимает BGP анонсы с расширенными community 1:10, 1:11 и 10:10, и отправляет BGP анонсы с расширенными community 2:10, 2:11 и 20:30. 

Так как на PE1 не сконфигурирован VRF black, то маршруты данного клиента ему не нужны, а значит, получая маршрут с расширенными community 20:30, PE1 их просто отбрасывает на основании того, что указанное в анонсе расширенное community не задано для данного маршрутизатора.

Бывает случаи, когда необходимо принимать маршруты со всеми расширенными community (например interAS-option B). При настройке маршрутизатора необходимо разрешить принимать все анонсы, так как это не дефолтное поведение маршрутизатора. Если маршрутизатор сконфигурирован как route-reflector, то он принимает и отдает все анонсы в не зависимости от расширенных community. Кроме того сам PE маршрутизатор может ограничить получаемые анонсы от других PE маршрутизаторов или роут-рефлекторов, тем самым уменьшая количество сигнальной информации. Но это уже тема другой статьи.

Спасибо за внимание! Надеюсь, я смог донести данную до читателя разницу между двумя этими с виду идентичными, но абсолютно разными по назначению понятиями.
Теги:
juniperrdrt
Хабы:
Сетевые технологии


Источник — https://noname.com.ua/mediawiki/index.php?title=RouteLeacking&oldid=9809