У нас есть VPN-туннели на основе маршрутов, идущие от пары маршрутизаторов Cisco на каждом из двух сайтов (всего 4 маршрутизатора) к двум различным VPN-шлюзам в одном общем VPC (XPN). Совместное использование маршрутов через BGP на один облачный маршрутизатор. Каждый из двух сайтов на нашей стороне имеет разные AS, каждая пара взаимодействует с одной и той же AS в паре, но пиринг между парами осуществляется по EIGRP. Я перераспределяю eigrp обратно в BGP (и наоборот) с картой маршрутов и определенной метрикой. На одном сайте я также перераспределяю вход-выход в OSPF, а другой - в статический. «Локальные» маршруты к каждому сайту для каждого сайта исходят от ospf / static, а «удаленные» маршруты - от eigrp.
Итак, в качестве примера ...
AS 65001 объявляет 10.1.1.0/24 с метрикой 50 (это локальный маршрут rdis от OSPF) и 172.16.1.1/24 с метрикой 100 (это удаленный маршрут, полученный из EIGRP).
AS 65002 объявляет 172.16.1.1/24 с метрикой 50 (это локальный маршрут, rdis от static) и 10.1.1.0/24 с метрикой 100 (это удаленный маршрут, полученный из EIGRP).
На самом деле объявлено 62 маршрута, но вы понимаете. Список из 62 маршрутов различается только метрикой.
Теперь моя проблема ... Облачный маршрутизатор берет все маршруты из 65001 и делает их основными / активными независимо от метрики и игнорирует маршруты с более низкой метрикой из 65002, если я не отключу туннели / пиринг до 65001.
Так что мой трафик всегда попадает туда, куда нужно, но по неоптимальным маршрутам.
Около двух недель назад это работало нормально, с тех пор оно перестало работать, как ожидалось.
Я изменил один из маршрутизаторов AS 65002 на 65001 (просто с помощью оператора Neighbor local-as и обновления стороны GCP, так как я также использую AS 65002 для однорангового подключения к Azure с этих маршрутизаторов), но этого не произошло. похоже, изменить это поведение.
Я обошел эту проблему с помощью простой AS, добавленной к "удаленным" маршрутам на карте исходящих маршрутов, примерно так:
router bgp 65001
neighbor 169.254.x.y route-map DISTtoBGP out
!
route-map DISTtoBGP permit 10
match ip address prefix-list LOCtoBGP
!
route-map DISTtoBGP permit 20
match ip address prefix-list REMtoBGP
set as-path prepend 65001
!
ip prefix-list LOCtoBGP seq 10 permit 10.1.0.0/16 le 24
!ip prefix-list LOCtoBGP ...
!
ip prefix-list REMtoBGP seq 10 permit 172.16.0.0/16 le 24
!ip prefix-list REMtoBGP ...
Это непросто, и его нужно будет поддерживать вручную, но это работает.
Спасибо, Нави, ваш вопрос о длине пути AS указал на простую работу.