BGP redistribute-internal: one more recipe to create a loop

Iaroslav Bondarenko

After a certain amount of lab practice, one usually bumps into some peculiar default that takes significant amount of time to detect and resolve. In my case one of such quirks was “bgp redistribute-internal” command. The effect of this command was obvious for me at that time; however, after a while I began asking myself why a certain feature might be “not recommended”. Google search yielded somewhat weak results; I’ve managed to find only a mention that such a command might cause a loop but no examples:

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.

Cisco.com, “Redistributing Routing Protocols”

Let’s consider the following topology for this discussion:

R1 announces 1.1.1.1/32 as an internal prefix and R2 summarizes this prefix into 1.1.1.0/24 as well as injects 1.1.1.1/32 into iBGP:

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

Let’s make R4 reintroduce 1.1.1.1/32 into area 1:

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

This would not introduce any problems though:

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
!!!!!

R4 has the necessary prefix in RIB, however, it does not redistribute it into OSPF despite configuration due to a fail-safe mechanism: prefixes received via iBGP are not redistributed back to IGP by default. Let’s change it and see if anything happens:

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)

The connectivity has faded away. R3 is now misguided towards R4 to reach 1.1.1.1/32; the latter forwards the packets back trying to reach R2, thus creating a permanent loop:

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>

Although the above example is definitely a bad design, one needs to be extra careful when implementing something “not recommended” by a vendor. In a common case, a better approach might be to redesign the solution to comply with “recommended” aka “tested” configuration.

Kudos for review: Anastasiia Kuraleva

Follow on Telegram, LinkedIn

Leave a comment