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
Хабы:
Сетевые технологии
