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

Если вы хоть раз настраивали MPLS L3VPN, то у вас не возникнет сомнения в том, что весь подход вертится вокруг BGP. Будучи протоколом маршрутизации с развитым чувством собственного достоинства (в конце концов, он является основой для интернета), BGP использует внушительный список атрибутов префикса, который лежит в основе алгоритма выбора лучшего маршрута. Несмотря на неприличную длину этого списка, большинство параметров предназначены для обеспечения детерминированности результата алгоритма, а не для управления трафиком руками инженера. Впрочем, иногда даже самые популярные параметры не подходят для решения определённой задачи. Если вы видите EIGRP в связке с 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

На CE-маршрутизаторах всё ещё аскетичнее:

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 именно такой? Согласно алгоритму выбора лучшего маршрута, только weight и local preference имеют больший приоритет, чем локальность префикса. Более того, по умолчанию локальные маршруты получают атрибут weight со значением 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

Зубрить сухие цифры – крайне неблагодарное занятие, поэтому весьма неплохо иметь под рукой шпаргалку с номерами и содержанием community для OSPF и EIGRP. Впрочем, виновник торжества сам по себе имеет довольно выразительное название – Cost:pre-bestpath:128:103040.

Роль cost community в топологиях L3VPN с EIGRP вполне прозаична. Представим две площадки, A и B, которые соединены между собой посредством быстрого L3VPN как основного пути и через выделенную линию в качестве запасного маршрута. В произвольный момент времени в недрах Площадки-А возникает Префикс-А, обновление о котором распространяется по обоим маршрутам. В такой ситуации возникает race condition:

Обновление о Префиксе-А достигает Площадки-В вначале через MPLS backbone. PE устанавливает новый префикс в BGP RIB, передает его в EIGRP (попутно восстанавливая метрику из community) и анонсирует новый маршрут на Площадке-В. Выделенная линия имеет худшую метрику, поэтому основной путь до Префикса-А лежит через ядро MPLS, что и требовалось реализовать.
Обновление о Префиксе-А достигает Площадки-В вначале через выделенную линию. При таком раскладе Префикс-А попадает в BGP RIB через EIGRP локально, поэтому когда соответствующее обновление приходит со стороны MPLS, оно не может стать лучшим с точки зрения BGP. Как следствие, Площадка-В начинает использовать выделенную линию в качестве основного пути, что не соответствует требуемому поведению.

Cost community является одним из решений описанной проблемы. Этот инструмент позволяет BGP рассматривать специальную метрику в определённом месте алгоритма выбора лучшего пути (в нашем случае – в самом начале). Значение метрики EIGRP становится значением cost community, что позволяет однозначно выбирать кратчайший маршрут.

Несмотря на то, что описанный подход неплохо работает с EIGRP в рамках L3VPN, у него есть очевидный побочный эффект – он изменяет стандартный и всем привычный алгоритм выбора лучшего пути. Как вы уже догадались, OSPF совершенно не в курсе про cost community, поэтому для его префиксов cуществует значение по умолчанию, 0x7FFFFFFF (214748347), которое значительно больше типовой метрики EIGRP.

На первый взгляд, можно было бы попробовать изменить метрику EIGRP таким образом, чтобы она была больше 0x7FFFFFFF. Однако это привело бы лишь к изменению «направления» проблемы, так как в этом случае уже R2 сравнивал бы значение по умолчанию для префиксов OSPF с огромной метрикой маршрутов EIGRP.

Самым простым решением, безусловно, было бы отключить добавление cost community в принципе, но увы, такой команды пока не существует. То, что доступно простым смертным – это игнорировать cost community в процессе выбора лучшего маршрута:

R1(config)#router bgp 123
R1(config-router)#bgp bestpath cost-community ignore

R3#sho bgp vpnv4 unicast all 
BGP table version is 26, 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       1.1.1.1                  2    100      0 ?
 *>i                  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 ?

Хоть нам и удалось отвлечь R1 от cost community, R3 страдает тем же самым недугом: методично выбирает лучший маршрут от EIGRP, несмотря на все остальные атрибуты.

R3#sho bgp vpnv4 unicast all 
BGP table version is 29, 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       1.1.1.1                  2    100      0 ?
 * i                  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 ?

Наконец, выбор лучшего маршрута соответствует привычным всем правилам: меньший MED решает исход гонки. В качестве альтернативы можно было бы вручную удалить противный cost community из исходящих обновлений:

R2(config)#ip extcommunity-list 100 permit pre-bestpath
R2(config)#route-map COSTCOMM
R2(config-route-map)#set extcomm-list 100 delete
R2(config)#router bgp 123
R2(config-router)#address-family vpnv4
R2(config-router-af)#neighbor L3VPN route-map COSTCOMM out

R2#sho bgp vpnv4 unicast all extcommunity-list 100
BGP table version is 23, local router ID is 2.2.2.2
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)
 *>  5.5.5.5/32       192.168.25.5        103040         32768 ?
 *>  8.8.8.8/32       192.168.25.5        103040         32768 ?
 *>  192.168.25.0     0.0.0.0                  0         32768 ?

R3#sho bgp vpnv4 unicast all 8.8.8.8/32
BGP routing table entry for 1:1:8.8.8.8/32, version 46
Paths: (2 available, best #1, table A)
  Advertised to update-groups:
     1         
  Refresh Epoch 5
  Local
    1.1.1.1 (metric 2) from 1.1.1.1 (1.1.1.1)
      Origin incomplete, metric 2, localpref 100, valid, internal, best
      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
      mpls labels in/out nolabel/23
  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
      Extended Community: RT:1:1 0x8800:32768:0 0x8801:1:2560 
        0x8802:65281:25600 0x8803:65281:1500 0x8806:0:134744072
      mpls labels in/out nolabel/23

Цели этой статьи – обсудить cost community и немного попрактиковаться в отладке. Не забывайте: в технике и технологии нет другого волшебства, кроме значений по умолчанию.

Большая печенька за рецензию: Анастасии Куралёвой.

Источник: https://habr.com/ru/post/671288/

Вернуться к списку

Интересные статьи

Про роботов для обучения, конструкторы и Arduino, и, как выяснилось, не только….муки выбора и мой опыт

Работая программистом и будучи отцом двух мальчиков неминуемо задумываешься над тем, как будут твои дети жить в технологическом мире и как будут им пользоваться. И, как любой айтишник, я конечно же хо...

Четыре шага на пути к Скайнет

В канун Нового года принято подводить итоги и строить планы на будущее. Вот и мы решили не нарушать традицию и внести свой вклад в общий тренд. Все мы сейчас часто слышим словосочетание «...

Что важно знать при выборе дезинфицирующих средств?

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

Персональные скидки и цены в интернет-магазине на 1С-Битрикс

Ваш сайт работает на 1С-Битрикс? Каждому клиенту вы даёте собственную скидку или назначаете персональную цену на товар? Со временем в вашей 1С сложилась непростая логика ценообразования и формирования...

Коммерческие факторы ранжирования в 1С-Битрикс

Компании переполнили рынок товаров и услуг предложениями. Разнообразие наблюдается не только в офлайне, но и в интернете. Достаточно вбить в поисковик любой запрос, чтобы получить подтверждение насыще...