Redistributing iBGP into IGP via bgp redistribute-internal command and the probable consequences

By default, The redistribution of iBGP into IGP isn’t allowed on Cisco IOS. The reason is redistribution of BGP into IGP can introduce several problems, some of them are:

• If an internet router redistributes all 500,000 internet prefix into the IGP will for sure crash those routers, as the IGPs aren’t designed to carry that amount of routes
• Redistributing BGP routes into IGP in a router in the middle of the network can cause a blackhole since the routes loses the info of the route originator and the reditributing router becomes the advertizing router for the route

In service provider networks, BGP is running everywhere, there’s no need to reditribute BGP into the IGP. ( we can excluse MPLS  L3VPNs since that’s a different story)

In some network, BGP is running only on the edge of the network and the rest of the network is running IGP only inside it, even though reditributing bgp into the IGP so that the internal network can reach outside the AS seems like a good solution, but it’s not, you can just generate a default route from the edge routers using the IGP and that can handle the  outbound traffic of the internal AS networks easily and without a hassle.

For the sake of the argument, I’ll discuss how to enable the redistribution of iBGP into IGP and how can that introduce a routing loop in the AS

Let’s check this simple topology

AS2 is running OSPF as an IGP, R1 and R2 is eBGP neighbors. R2 is iBGP neighbor to both R3 and R4

Now let’s check R3 and R4 BGP table for the network 1.1.1.1/32

R3#show ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  1
    2.2.2.2 (metric 21) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

R4#show ip bgp 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 17
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  1
    2.2.2.2 (metric 11) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

Both R3 and R4 are pointing to R2 as the next-hop for the prefix 1.1.1.1/32 as expected. Now let’s try to redistribute the iBGP routes on R3

    R3(config)#router ospf 1

R3(config-router)#redistribute bgp 2 subnets

Checking the OSPF database

R3#show ip ospf database

            OSPF Router with ID (3.3.3.3) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count

2.2.2.2         2.2.2.2         136         0x80000008 0x00E723 4

3.3.3.3         3.3.3.3         42          0x80000009 0x0046B4 4

4.4.4.4         4.4.4.4         1996        0x80000006 0x0087F3 3

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum

10.2.4.2        2.2.2.2         136         0x80000003 0x009174

10.3.4.3        3.3.3.3         8           0x80000003 0x007F7C

It seems that the route isn’t redistributed even though you can clearly see it under the router ospf configuration

router ospf 1

 log-adjacency-changes

 redistribute bgp 2 subnets

now let’s enable the iBGP reditribution for IGPs

R3(config)#router bgp 2

R3(config-router)#bgp redistribute-internal

Checking the ospf database again

R3#show ip ospf database 

            OSPF Router with ID (3.3.3.3) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         332         0x80000008 0x00E723 4
3.3.3.3         3.3.3.3         238         0x80000009 0x0046B4 4
4.4.4.4         4.4.4.4         176         0x80000007 0x0085F4 3

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.2.4.2        2.2.2.2         332         0x80000003 0x009174
10.3.4.3        3.3.3.3         204         0x80000003 0x007F7C

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
1.1.1.1         3.3.3.3         41          0x80000001 0x00B2EF 1

That’s more like it, the prefix 1.1.1.1/32 is now in the ospf database and the advertising router is R3 (3.3.3.3)

Uptill now everything seems fine, but infact it isn’t, if we try to ping /traceroute from R3 or R4, it will fail

R3#ping 1.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

R3#traceroute 1.1.1.1

Type escape sequence to abort.

Tracing the route to 1.1.1.1

  1 10.3.4.4 64 msec 52 msec 20 msec

  2 10.3.4.3 24 msec 44 msec 20 msec

  3  *  *

    10.3.4.4 84 msec

  4  *  *  *

  5  *  116 msec *

  6  *  *  *

  7  *  124 msec *

  8  *  *

    10.3.4.3 124 msec

  9  *  *  *

 10  *  *  *

 11  *  *

    10.3.4.4 144 msec

 12  *

R4#ping 1.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

R4#traceroute 1.1.1.1 timeout 1

Type escape sequence to abort.

Tracing the route to 1.1.1.1

  1 10.3.4.3 44 msec 36 msec 20 msec

  2 10.3.4.4 40 msec 40 msec 24 msec

  3  *  *

    10.3.4.3 60 msec

  4  *

    10.3.4.4 84 msec *

  5  *  *  *

  6  *  72 msec *

  7  *  *  *

  8  *  *  124 msec

  9  *  *  *

 10  *  *  *

 11  *  *  *

 12 10.3.4.4 168 msec *  *

Well, it seems that we have a routing loop at our hands here, the packet destined to 1.1.1.1 keeps bouncing between R3 and R4. The reason is that R3 is advertizing this network to all routers in the OSPF domain, which has an AD of 110, which by turn is more preferable than iBGP AD of 170., whilst the the shortest path to R2 ( next-hop) is through R4 as metric of 21  compared to 61 . So when R3 is trying to send the packet to R2, it will first send it to R4, when the packet reaches R4, it will find a better path through R2. That’s when the routing loop occures.

Here’s how to confirm it

R3#show ip route 1.1.1.1

Routing entry for 1.1.1.1/32

  Known via "bgp 2", distance 200, metric 0

  Tag 1, type internal

  Redistributing via ospf 1

  Advertised by ospf 1 subnets

  Last update from 2.2.2.2 00:14:25 ago

  Routing Descriptor Blocks:

  * 2.2.2.2, from 2.2.2.2, 00:14:25 ago

      Route metric is 0, traffic share count is 1

      AS Hops 1

      Route tag 1

R3#show ip route 2.2.2.2

Routing entry for 2.2.2.2/32

  Known via "ospf 1", distance 110, metric 21, type intra area

  Last update from 10.3.4.4 on FastEthernet0/0, 01:23:23 ago

  Routing Descriptor Blocks:

  * 10.3.4.4, from 2.2.2.2, 01:23:23 ago, via FastEthernet0/0

      Route metric is 21, traffic share count is 1

R4#show ip route 1.1.1.1

Routing entry for 1.1.1.1/32

  Known via "ospf 1", distance 110, metric 1

  Tag 1, type extern 2, forward metric 10

  Last update from 10.3.4.3 on FastEthernet0/0, 00:16:49 ago

  Routing Descriptor Blocks:

  * 10.3.4.3, from 3.3.3.3, 00:16:49 ago, via FastEthernet0/0

      Route metric is 1, traffic share count is 1

      Route tag 1

In order to fix that, you have several options, some of them are

•     Redistribute iBGP into BGP on R2 , ie the border router
•   Reduce the cost between the R3 the redistributing router and the border router, but most probably that might affect all of your IGP domain routers since this will propagate ( you should be extremely careful)

Hopefuly this cleared up the usage of bgp redistribute-internal command and probable consequences of using it