RouteLeacking

Route Leaking

Это заметка о том как настроить перетекание маршрутов с фильтрацией между 2 VRF.
Пока только конфиг

hostname c4948E
!
boot-start-marker
boot system bootflash:cat4500e-entservicesk9-mz.152-4.E.bin
boot-end-marker
!
!
vrf definition Customers
 description Customers
 rd 65532:1000
 route-target export 65532:1000
 route-target import 65532:2000
 !
 address-family ipv4
  import map IMPORT-TO-VRF-CUSTOMERS
  export map EXPORT-FROM-VRF-CUSTOMERS
 exit-address-family
!
vrf definition Radio
 description Radio
 rd 65532:2000
 route-target export 65532:2000
 route-target import 65532:1000
 !
 address-family ipv4
  import map IMPORT-TO-VRF-RADIO
  export map EXPORT-FROM-VRF-RADIO
 exit-address-family

!
ip domain-name donec.net.ua
ip name-server 172.31.100.0
ip name-server 172.31.100.1
ip dhcp smart-relay
ip dhcp relay information policy keep
no ip dhcp relay information check
ip dhcp relay information trust-all
ip dhcp snooping vlan 1995,2000-2099,2101-2124,3000-3099,3200-3299,3311-3399
ip dhcp snooping information option allow-untrusted
no ip dhcp snooping verify mac-address
ip dhcp snooping
!
!
vtp domain client
vtp mode off
!

!
interface Loopback100
 description --==Loopback for IpUnnumbered==--
 vrf forwarding Customers
 ip dhcp relay information trusted
 ip address 192.168.128.254 255.255.240.0
!
interface Loopback101
 description --==Loopback for IpUnnumbered Radio==--
 vrf forwarding Radio
 ip dhcp relay information trusted
 ip address 192.168.128.1 255.255.240.0

interface Vlan1995
 description Andreevka_via_Driada
 vrf forwarding Radio
 ip dhcp relay information trusted
 ip dhcp relay information option-insert
 ip dhcp relay information policy-action replace
 ip unnumbered Loopback101
 ip helper-address 172.31.100.18
 no ip redirects
 ip local-proxy-arp
 ip route-cache same-interface
!
interface Vlan2000
 description name 5gor__Office
 vrf forwarding Customers
 ip dhcp relay information trusted
 ip dhcp relay information policy-action keep
 ip unnumbered Loopback100
 ip helper-address 172.31.100.18

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


<PRE>
router bgp 65532
 bgp log-neighbor-changes
 !
 address-family ipv4 vrf Customers
  redistribute connected
  redistribute static
  neighbor 172.31.100.237 remote-as 57100
  neighbor 172.31.100.237 activate
  neighbor 172.31.100.237 soft-reconfiguration inbound
  neighbor 172.31.100.237 prefix-list 32-MASK-ONLY-DONEC-NETWORKS in
  neighbor 172.31.100.237 route-map FROM-VRF-CUSTOMERS-TO-BORDER out
 exit-address-family
 !
 address-family ipv4 vrf Radio
  redistribute connected
  redistribute static
  neighbor 172.31.100.225 remote-as 57100
  neighbor 172.31.100.225 activate
  neighbor 172.31.100.225 soft-reconfiguration inbound
  neighbor 172.31.100.225 prefix-list 32-MASK-ONLY-DONEC-NETWORKS in
  neighbor 172.31.100.225 route-map FROM-VRF-RADIO-TO-BORDER out
 exit-address-family
!
no ip http server
no ip http secure-server
ip forward-protocol nd
!
ip extcommunity-list standard VRF-CUSTOMERS-RT permit rt 65532:1000
ip extcommunity-list standard VRF-CUSTOMERS-RT deny rt 65532:2000
ip extcommunity-list standard VRF-RADIO-RT permit rt 65532:2000
ip extcommunity-list standard VRF-RADIO-RT deny rt 65532:1000
!
ip route 0.0.0.0 0.0.0.0 172.31.100.241
ip route vrf Customers 0.0.0.0 0.0.0.0 172.31.100.237
ip route vrf Radio 0.0.0.0 0.0.0.0 172.31.100.225
ip ssh version 1
!
!
!
ip prefix-list 32-MASK-ONLY seq 10 permit 0.0.0.0/0 ge 32
ip prefix-list 32-MASK-ONLY seq 20 deny 0.0.0.0/0 le 31
!
ip prefix-list 32-MASK-ONLY-DONEC-NETWORKS seq 10 permit 94.154.32.0/21 ge 32
ip prefix-list 32-MASK-ONLY-DONEC-NETWORKS seq 20 permit 192.168.128.0/20 ge 32
ip prefix-list 32-MASK-ONLY-DONEC-NETWORKS seq 100 deny 0.0.0.0/0 le 31
!
ip prefix-list ANY seq 10 permit 0.0.0.0/0 le 32
!
ip prefix-list NO-DEFAULT-ROUTE seq 5 deny 0.0.0.0/0
ip prefix-list NO-DEFAULT-ROUTE seq 10 permit 0.0.0.0/0 le 32
!
ip prefix-list NONE seq 10 deny 0.0.0.0/0 le 32
!
ip prefix-list ONLY-DEFAULT-ROUTE seq 5 permit 0.0.0.0/0
!
route-map FROM-VRF-RADIO-TO-BORDER deny 10
 match extcommunity VRF-CUSTOMERS-RT
!
route-map FROM-VRF-RADIO-TO-BORDER permit 20
 match ip address prefix-list 32-MASK-ONLY
!
route-map FROM-VRF-RADIO-TO-BORDER deny 1000
 match ip address prefix-list ANY
!
route-map FROM-VRF-CUSTOMERS-TO-BORDER deny 10
 match extcommunity VRF-RADIO-RT
!
route-map FROM-VRF-CUSTOMERS-TO-BORDER permit 20
 match ip address prefix-list 32-MASK-ONLY
!
route-map FROM-VRF-CUSTOMERS-TO-BORDER deny 1000
 match ip address prefix-list ANY
!
route-map EXPORT-FROM-VRF-CUSTOMERS permit 10
 match ip address prefix-list 32-MASK-ONLY
!
route-map EXPORT-FROM-VRF-CUSTOMERS deny 1000
 match ip address prefix-list ANY
!
route-map EXPORT-FROM-VRF-RADIO permit 10
 match ip address prefix-list 32-MASK-ONLY
!
route-map EXPORT-FROM-VRF-RADIO deny 1000
 match ip address prefix-list ANY
!
route-map IMPORT-TO-VRF-RADIO permit 10
 match ip address prefix-list 32-MASK-ONLY
!
route-map IMPORT-TO-VRF-RADIO deny 1000
 match ip address prefix-list ANY
!
route-map TO-BORDER permit 10
 match ip address prefix-list 32-MASK-ONLY
!
route-map TO-BORDER deny 1000
 match ip address prefix-list ANY
!
route-map IMPORT-TO-VRF-CUSTOMERS permit 10
 match ip address prefix-list 32-MASK-ONLY
!
route-map IMPORT-TO-VRF-CUSTOMERS deny 1000
 match ip address prefix-list ANY
!
!
!
!

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://habr.com/ru/sandbox/99255/
• https://networkdirection.net/articles/routingandswitching/mp-bgp/leakingrouteswithmp-bgp/