BGP redistribute-internal: ещё один рецепт петли маршрутизации

Иногда можно наткнуться на такое поведение по умолчанию, обнаружение и понимание которого требует определённой медитации. Для меня одной из таких особенностей была команда “bgp redistribute-internal”. Первоначально назначение этой функции не вызывало у меня каких-либо вопросов, как и то, что её использование может привести к петлям маршрутизации; раз знающие люди написали, что может, значит, так оно и есть. Однако спустя неопределённое время в голове начало скрестись желание получить наглядный пример такой петли. Беглый поиск, впрочем, не дал ничего конкретного, только упоминание в документации:

“Note: By default, only eBGP-learned information is candidate to be redistributed into IGP when the redistribute bgp command is issued. The iBGP routes is not redistributed into IGP until the bgp redistribute-internal command is configured under the router bgp command. But precautions must be taken in order to avoid loops within the Autonomous System when iBGP routes are redistributed into IGP.”

(Вольный перевод: по умолчанию только внешние BGP маршруты можно рассматривать как кандидаты для импорта в IGP при использовании команды redistribute bgp. Внутренние BGP маршруты не являются такими кандидатами, пока не выполнена команда bgp redistribute-internal в режиме router bgp. Однако стоит соблюдать осторожность при использовании последней команды, чтобы избежать возникновения петель маршрутизации внутри автономной системы, когда внутренние BGP маршруты могут быть импортированы в IGP)

Попробуем изобрести нужный нам пример петли. Рассмотрим следующую схему:

R1 объявляет 1.1.1.1/32 как внутренний маршрут; в то же время R2 суммаризует его до 1.1.1.0/24 и добавляет 1.1.1.1/32 в BGP:

R2#sho ip ro 1.1.1.1 longer-prefixes
<output omitted>
      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/2] via 192.168.12.1, 00:03:09, FastEthernet0/0

R2(config)#router ospf 1
R2(config-router)#area 0 range 1.1.1.0 255.255.255.0
R2(config-router)#router bgp 1
R2(config-router)#network 1.1.1.1 mask 255.255.255.255

Импортируем 1.1.1.1/32 из BGP в OSPF в зоне 1:

R4(config)#router ospf 1
R4(config-router)#redistribute bgp 1 subnets

Впрочем, ничего плохого не происходит:

R4#ping 1.1.1.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
!!!!!

1.1.1.1/32 есть в таблице маршрутизации R4, однако OSPF не импортирует маршрут из BGP, несмотря на настройки. Изменим это поведение и понаблюдаем за происходящим:

R4(config-router)#router bgp 1                  
R4(config-router)#bgp redistribute-internal  

R4#ping 1.1.1.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
.....
Success rate is 0 percent (0/5)

Связность между R4 и R1 пропала. R3 теперь считает, что маршрут до 1.1.1.1/32 лежит через R4, который в свою очередь шлёт пакеты обратно – в сторону R2, что приводит к петле:

R4#traceroute 1.1.1.1 source lo0
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.34.3 28 msec 36 msec 16 msec
  2 192.168.34.4 24 msec 20 msec 16 msec
  3 192.168.34.3 32 msec 40 msec 44 msec
  4 192.168.34.4 44 msec 36 msec 40 msec
<output omitted>

Несмотря на то что такой пример является искусственным, нужно внимательно относиться к функциональности, которая помечена вендором как «не рекомендуемая». Подобные грабли могут быть достаточно неочевидны в большой сети, однако негативный эффект не заставит себя ждать. В общем случае имеет смысл пересмотреть дизайн решения и использовать рекомендованные (другими словами, протестированные) способы использования той или иной технологии.

Спасибо за рецензию: Анастасии Куралёвой