Проблема с двумя точками редистрибьюции маршрутов

Допустим, мы имеем в сети подобную схему:

Имеем 2 части сети, одна пусть будет BGP Backbone, вторая - конечные пользователи с EIGRP. Маршруты из BGP редистрибьютируются в EIGRP и наоборот. Для обеспечения необходимой избыточности существуют две точнки подключения конечного пользователя к backbone через R2 и R3, которые еще и соеденены между собой.
Основная проблема в таких сетях - петли маршрутов (routing loops), которые происходят из-за прозрачной двунаправленной редистрибьюции одного протокола в другой. Как это происходит?
Пусть на роутерах R0-PE и R1-PE редистрибьюция из EIGRP в BGP сконфигурирована с метрикой 1800 а роутер R7 шлет апдейт для сети 10.170.0.0/24 с метрикой 1900. Этот маршрут далее редистрибьютится в EIGRP и отправляется на R2 в составе апдейта. Который в свою очередь рассылает апдейты всем своим соседям (непосредственно нас интересует R3). R3 в свою очередь рассылает апдейты для R1-PE, который редистрибьютит маршрут в BGP но с метрикой 1800.

Затем все соседи получают от R1-PE маршрут с метрикой 1800 вместо правильной 1900. Теперь R0-PE будет редистрибьютировать маршрут к 10.170.0.0/24 через R1-PE вместо R7. Пеля замыкается, пакеты будут ходить по кругу пока не закончится TTL. Плюс к этому, если в сети подобных схем подключения несколько, это может привести к тому, что трафик будет ходить петлями через другие регионы, а не по кратчайшему маршруту.
Картину очень легко наблюдать с R4, например.

R4# traceroute 10.170.0.1

Type escape sequence to abort.
Tracing the route to 10.170.0.1

1 10.20.0.2 104 msec 100 msec 16 msec
2 10.50.0.1 112 msec 272 msec 160 msec
3 10.1.0.1 636 msec 404 msec 548 msec
4 10.50.1.2 340 msec 212 msec 124 msec
5 10.30.0.0 100 msec 100 msec 116 msec
6 10.50.0.1 180 msec 196 msec 176 msec
7 10.1.0.1 212 msec 196 msec 140 msec
8 10.50.1.2 208 msec 404 msec 320 msec
9 10.30.0.0 396 msec 356 msec 364 msec
...
26 10.50.0.1 1092 msec 636 msec 668 msec
27 10.1.0.1 672 msec 504 msec 624 msec
28 10.50.1.2 520 msec 548 msec 488 msec
29 10.30.0.0 588 msec 536 msec 568 msec
30 10.50.0.1 508 msec 460 msec 700 msec

Как бороться? Необходимо метить маршрут при редистрибьюции из BGP в EIGRP, а при обратной редистрибьюции этот маршрут вырезать.

В устройствах CISCO для этого используют route-map и параметр set tag.
При редистрибьюции из BGP в EIGRP:

route-map REDIST_BGP permit 10
set metric 10000 100 255 1 1500
set tag 210

router eigrp 100
redistribute bgp 65000 route-map REDIST_BGP

А при обратном процессе:

route-map EIGRP-BGP deny 10
match tag 210
route-map EIGRP-BGP permit 20
set metric 1800

router bgp 65000
redistribute eigrp 100 route-map EIGRP-BGP

Теперь трейсы с R4 проходят на ура.

R4# traceroute 10.170.0.1

Type escape sequence to abort.
Tracing the route to 10.170.0.1

1 10.20.0.2 24 msec 72 msec 20 msec
2 10.50.0.1 220 msec 144 msec 88 msec
3 10.150.0.1 156 msec 288 msec *
R4#                

Следует упомянуть, что даже в случае, если метрики будут в норме (т.е. при редистрибьюции будет задаваться метрика заведомо больше, чем получаемая от R7), каждый из роутеров R0-PE и R1-PE будет "видеть" внешнюю сеть через соседа по EIGRP, т.к. будет получать маршруты с administrative distance 170 от него, что больше чем AD для BGP - 200. Соответственно маршрут через EIGRP будет более предпочтителен, хотя это не так.
Таким образом, при двух и более точках редистрибьюции, никогда нельзя делать ее просто прозрачной, необходимо следить за петлями маршрутов, благо инструментов для этого предостаточно.