Выбор Лучшего Пути По Версии Bgp В L3Vpn: Скрытый Нюанс

Если вы когда-либо настраивали MPLS L3VPN, то у вас не будет сомнений, что весь подход вращается вокруг BGP. Будучи протоколом маршрутизации с сильным собственным смыслом (в конце концов, он является основой Интернета), BGP использует впечатляющий список атрибутов префиксов, которые лежат в основе его алгоритма выбора наилучшего маршрута.

Несмотря на неприличную длину этого списка, большинство параметров предназначены для обеспечения детерминированности результата алгоритма, а не для управления трафиком руками инженера.

Однако иногда даже самые популярные параметры не подходят для решения той или иной задачи.

Если вы видите EIGRP в сочетании с L3VPN, возможно, это наш сегодняшний пациент. Сестра, топология:

Выбор лучшего пути по версии BGP в L3VPN: скрытый нюанс

R1-R3 — это PE-маршрутизаторы, которые используют OSPF вместе с LDP в ядре.

Они также обеспечивают связь между сайтами с использованием разных IGP: R1↔R4 ≡ OSPF, R2↔R5 ≡ EIGRP, R3↔R6 ≡ eBGP. Клиентские устройства CE, R4-R6, находятся в одном VRF. R4 и R5 предоставляют R6 доступ к определенному сервису, который находится по адресу 8.8.8.8/32. Настройка R1 в качестве образца:

   

 R1(config)#vrf definition A
 R1(config-vrf)# rd 1:1
 R1(config-vrf)# route-target export 1:1
 R1(config-vrf)# route-target import 1:1
 R1(config-vrf)# address-family ipv4
 R1(config)#interface Loopback0
 R1(config-if)# ip address 1.1.1.1 255.255.255.255
 R1(config)#interface FastEthernet0/0
 R1(config-if)# vrf forwarding A
 R1(config-if)# ip address 192.168.14.1 255.255.255.0        
 R1(config)#interface FastEthernet1/0
 R1(config-if)# ip address 192.168.13.1 255.255.255.0
 R1(config)#interface FastEthernet1/1
 R1(config-if)# ip address 192.168.12.1 255.255.255.0
 R1(config)#router ospf 2 vrf A
 R1(config-router)# redistribute bgp 123 subnets
 R1(config-router)# network 0.0.0.0 255.255.255.255 area 0
 R1(config)#router ospf 1
 R1(config-router)# mpls ldp autoconfig
 R1(config-router)# router-id 1.1.1.1
 R1(config-router)# network 0.0.0.0 255.255.255.255 area 0
 R1(config)#router bgp 123
 R1(config-router)# bgp router-id 1.1.1.1
 R1(config-router)# no bgp default ipv4-unicast
 R1(config-router)# neighbor L3VPN peer-group
 R1(config-router)# neighbor L3VPN remote-as 123
 R1(config-router)# neighbor L3VPN update-source Loopback0
 R1(config-router)# neighbor 2.2.2.2 peer-group L3VPN
 R1(config-router)# neighbor 3.3.3.3 peer-group L3VPN
 R1(config-router)# address-family vpnv4
 R1(config-router-af)#  neighbor L3VPN send-community both
 R1(config-router-af)#  neighbor 2.2.2.2 activate
 R1(config-router-af)#  neighbor 3.3.3.3 activate
 R1(config-router-af)# exit-address-family
 R1(config-router)# address-family ipv4 vrf A
 R1(config-router-af)#  redistribute ospf 2

На СЕ роутерах все еще аскетичнее:

 R6(config)#interface Loopback0
 R6(config-if)# ip address 6.6.6.6 255.255.255.255
 R6(config)#interface FastEthernet0/0
 R6(config-if)# ip address 192.168.36.6 255.255.255.0
 R6(config)#router bgp 6
 R6(config-router)# bgp router-id 6.6.6.6
 R6(config-router)# no bgp default ipv4-unicast
 R6(config-router)# neighbor 192.168.36.3 remote-as 123
 R6(config-router)# address-family ipv4
 R6(config-router-af)#  network 6.6.6.6 mask 255.255.255.255
 R6(config-router-af)#  neighbor 192.168.36.3 activate

Loopback-интерфейсы эмулируют доступность определенного сервиса:

 R4(config)#interface Loopback1
 R4(config-if)# ip address 8.8.8.8 255.255.255.255

 R5(config)#interface Loopback1
 R5(config-if)# ip address 8.8.8.8 255.255.255.255

Посмотрим, есть ли в принципе связность между R6 и 8.8.8.8:

 R6#ping 8.8.8.8 source loopback 0
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
 Packet sent with a source address of 6.6.6.6 
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 52/60/80 ms

Основная цель данной схемы — обеспечить отказоустойчивый доступ R6 к 8.8.8.8/32 через R4 и R5, поэтому BGP-сессии строятся непосредственно между PE-маршрутизаторами.

R1 и R2 должны считать префиксы из IGP лучшими с точки зрения BGP RIB (это локальные маршруты); как следствие, R3 должен получить оба маршрута, по одному от каждого из своих соседей.

R3#sho bgp vpnv4 unicast all BGP table version is 13, local router ID is 3.3.3.3 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: 1:1 (default for vrf A) *>i 4.4.4.4/32 1.1.1.1 2 100 0 ? *>i 5.5.5.5/32 2.2.2.2 103040 100 0 ? *> 6.6.6.6/32 192.168.36.6 0 0 6 i *>i 8.8.8.8/32 2.2.2.2 103040 100 0 ? *>i 192.168.14.0 1.1.1.1 0 100 0 ? *>i 192.168.25.0 2.2.2.2 0 100 0 ?

По странному совпадению R3 получил только один префикс вместо двух.

Вполне вероятно, что R1 вообще ничего не отправлял про 8.8.8.8/32:

R1#sho bgp vpnv4 unicast all BGP table version is 13, 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: 1:1 (default for vrf A) *> 4.4.4.4/32 192.168.14.4 2 32768 ? *>i 5.5.5.5/32 2.2.2.2 103040 100 0 ? *>i 6.6.6.6/32 3.3.3.3 0 100 0 6 i r>i 8.8.8.8/32 2.2.2.2 103040 100 0 ? r 192.168.14.4 2 32768 ? *> 192.168.14.0 0.0.0.0 0 32768 ? *>i 192.168.25.0 2.2.2.2 0 100 0 ?

R1 считает 8.8.8.8/32, полученный от R2, лучшим маршрутом (символ «> »).

Поскольку этот префикс принимается по iBGP, он не включается в обновления, предназначенные для обычных соседей iBGP. Почему выбор пал на R1? Согласно алгоритму выбора наилучшего маршрута, только вес и локальное предпочтение имеют более высокий приоритет, чем префиксная местность.

Более того, по умолчанию локальные маршруты получают атрибут веса со значением 32768. По всем правилам получается, что 8.8.8.8/32 от OSPF должен с большим отрывом побеждать маршрут от R2. В чем дело?

R1#sho bgp vpnv4 unicast all 8.8.8.8/32 BGP routing table entry for 1:1:8.8.8.8/32, version 13 Paths: (2 available, best #1, table A, RIB-failure(17) - next-hop mismatch) Not advertised to any peer Refresh Epoch 1 Local 2.2.2.2 (metric 2) from 2.2.2.2 (2.2.2.2) Origin incomplete, metric 103040, localpref 100, valid, internal, best Extended Community: RT:1:1 Cost:pre-bestpath:128:103040 0x8800:32768:0 0x8801:1:2560 0x8802:65281:25600 0x8803:65281:1500 0x8806:0:134744072 mpls labels in/out nolabel/22 Refresh Epoch 1 Local 192.168.14.4 from 0.0.0.0 (1.1.1.1) Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced Extended Community: RT:1:1 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:192.168.14.1:0

Зубрить сухие цифры — крайне неблагодарное занятие, поэтому неплохо иметь под рукой шпаргалку с цифрами и контентом сообщества для ОСПФ И EIGRP .

Однако у самого виновника торжества довольно выразительное имя – Стоимость:pre-bestpath:128:103040 .

Роль стоимости сообщества в топологиях L3VPN с EIGRP довольно прозаична.

Давайте представим себе два сайта, A и B, которые соединены друг с другом через быстрый L3VPN в качестве основного пути и через выделенную линию в качестве резервного маршрута.

В произвольный момент времени в недрах Зоны-А появляется Префикс-А, обновление о котором распространяется по обоим маршрутам.

В такой ситуации возникает состояние гонки:

Обновление о Prefix-A сначала достигает Site-B через магистраль MPLS. PE устанавливает новый префикс в BGP RIB, передает его в EIGRP (заодно восстанавливая метрику из

Теги: #cisco #cisco #Сетевые технологии #it-инфраструктура #mpls #ospf #bgp #l3vpn #community #MPLS L3VPN #EIGRP #cost Community