Introduction

Throughout this BGP series, I’ve covered attributes, policies, and mechanisms that control BGP behavior within the BGP domain – how routes are selected, advertised, and propagated through BGP. But what happens when you need to move routes out of BGP and into an IGP like OSPF or EIGRP?

Redistribution from BGP to IGP is common in enterprise networks:

• BGP handles external connectivity (Internet, MPLS, partners)
• IGP handles internal routing (OSPF, EIGRP within the AS)
• Redistribution bridges the two domains

But there’s a critical default behavior most engineers discover the hard way:

By default, iBGP routes CANNOT be redistributed into an IGP.

This is a safety mechanism to prevent routing loops. But sometimes you need to override it. That’s where bgp redistribute-internal comes in.

Understanding the Default Behavior

iBGP Routes and Redistribution

When you configure redistribution from BGP to an IGP:

router ospf 1
 redistribute bgp 1000 subnets

What actually gets redistributed?

Default behavior:

• ✓ eBGP routes: Redistributed into OSPF
• ✗ iBGP routes: NOT redistributed into OSPF
• ✓ Locally originated BGP routes: Redistributed into OSPF

Only routes learned via eBGP or locally originated are redistributed. Routes learned via iBGP are silently skipped.

Why This Restriction Exists

The iBGP redistribution block is a loop prevention mechanism.

Consider this scenario without the block:

AS 1000 Topology:
  R3 ←iBGP→ R4
  R3 runs OSPF with R5, R6
  R4 runs OSPF with R5, R6

Routing loop scenario:
1. R3 learns route X via iBGP from R4
2. R3 redistributes X into OSPF (if allowed)
3. R5 and R6 learn X via OSPF from R3
4. R4 learns X via OSPF from R5/R6
5. R4 redistributes X into BGP (if configured)
6. R3 learns X via iBGP from R4 again
   → Loop! Route ping-pongs between BGP and OSPF

The root cause: iBGP does not change next-hop by default. When R3 redistributes an iBGP route into OSPF, other routers see R3 as the source, even though R3 learned it from R4. This creates a potential loop.

Cisco’s solution: Block iBGP routes from redistribution entirely, forcing you to think carefully before overriding.

Lab Topology

Same topology from previous BGP posts:

• AS 1000: R3, R4, R5, R6 (iBGP full mesh)
  • R3: Runs BGP and OSPF, redistributes BGP into OSPF
  • R4: Runs BGP and OSPF
  • R5: Runs OSPF only
  • R6: Runs OSPF only (where we verify routes)
  • R3 ←iBGP→ R4
  • R3-R4-R5-R6 all in OSPF

R3 is the redistribution point:

• Receives routes via eBGP from external ASes (AS 12, AS 100)
• Receives routes via iBGP from R4 (who learns from AS 2000)
• Redistributes BGP into OSPF for R5 and R6 to reach external networks

Example: Missing iBGP Routes

Requirement

R6 is not receiving some of the BGP redistributed routes. Upon further investigation, you find that the routes that are missing are iBGP routes. Allow the iBGP routes to be redistributed into an IGP.

Translation:

• R3 is redistributing BGP into OSPF
• R6 (OSPF-only router) should see all BGP routes
• But iBGP-learned routes are missing from R6
• Need to enable redistribution of iBGP routes

Initial Configuration (R3)

R3 has standard BGP-to-OSPF redistribution:

router ospf 1
 redistribute bgp 1000 subnets
 
router bgp 1000
 ! No bgp redistribute-internal (default)

This redistributes BGP routes into OSPF, but with the default restriction: iBGP routes are excluded.

Initial State (Before redistribute-internal)

R6’s OSPF routing table:

R6#sh ip route ospf
O*E2  0.0.0.0/0 [110/1] via 192.168.36.3, 00:39:16, GigabitEthernet0/0
O E2  1.0.0.0/8 [110/1] via 192.168.36.3, 00:39:16, GigabitEthernet0/0
O E2  2.0.0.0/8 [110/1] via 192.168.36.3, 00:39:16, GigabitEthernet0/0
O E2  3.0.0.0/8 [110/1] via 192.168.36.3, 00:39:16, GigabitEthernet0/0
O E2  11.1.1.0/24 [110/1] via 192.168.36.3, 00:39:16, GigabitEthernet0/0
O E2  22.2.2.0/24 [110/1] via 192.168.36.3, 00:39:16, GigabitEthernet0/0
O E2  33.3.3.0/24 [110/1] via 192.168.36.3, 00:39:16, GigabitEthernet0/0
O E2  100.0.0.0/8 [110/1] via 192.168.36.3, 00:38:18, GigabitEthernet0/0
O E2  101.101.101.0/24 [110/1] via 192.168.36.3, 00:38:18, GigabitEthernet0/0

R6 sees several OSPF External Type-2 (E2) routes redistributed from BGP. These are all eBGP routes that R3 learned from external neighbors.

Missing routes: Notice that routes from AS 2000 are absent:

• 4.0.0.0/8, 5.0.0.0/8 (R4’s networks)
• 7.0.0.0/8, 8.0.0.0/8, 9.0.0.0/8 (AS 2000 networks)
• 44.4.4.0/24, 55.5.5.0/24, 77.7.7.0/24, 88.8.8.0/24, 99.9.9.0/24
• 111.0.0.0/8, 112.112.112.0/24 (AS 110 networks learned via AS 2000)

These missing routes are learned by R3 via iBGP from R4, so they’re blocked from redistribution by default.

Analysis: Which Routes Are Missing?

Let’s trace the path for a missing route (e.g., 7.0.0.0/8):

Origin: AS 2000 (R7)
  ↓
R7 → R4 (iBGP within AS 2000, R4 is in AS 1000 at the edge)
  ↓
R4 → R3 (iBGP within AS 1000)
  ↓
R3 tries to redistribute into OSPF
  ↓
BLOCKED! (learned via iBGP from R4)
  ↓
R6 never sees it

The route arrives at R3 via iBGP, so R3 refuses to redistribute it.

Configuration: Enable redistribute-internal

On R3 (the redistribution point):

router bgp 1000
 bgp redistribute-internal

That’s it! One command overrides the default iBGP redistribution block.

Syntax:

bgp redistribute-internal

Effect: Allows iBGP-learned routes to be redistributed into IGPs
Scope: Applies to all redistribution from this BGP process
No parameters: It's a boolean toggle (on/off)

Results After Configuration

R6’s OSPF routing table:

R6#sh ip route ospf
O*E2  0.0.0.0/0 [110/1] via 192.168.36.3, 00:45:30, GigabitEthernet0/0
O E2  1.0.0.0/8 [110/1] via 192.168.36.3, 00:45:30, GigabitEthernet0/0
O E2  2.0.0.0/8 [110/1] via 192.168.36.3, 00:45:30, GigabitEthernet0/0
O E2  3.0.0.0/8 [110/1] via 192.168.36.3, 00:45:30, GigabitEthernet0/0
O E2  4.0.0.0/8 [110/1] via 192.168.36.3, 00:00:12, GigabitEthernet0/0
O E2  5.0.0.0/8 [110/1] via 192.168.36.3, 00:00:12, GigabitEthernet0/0
O E2  7.0.0.0/8 [110/1] via 192.168.36.3, 00:00:12, GigabitEthernet0/0
O E2  8.0.0.0/8 [110/1] via 192.168.36.3, 00:00:12, GigabitEthernet0/0
O E2  9.0.0.0/8 [110/1] via 192.168.36.3, 00:00:12, GigabitEthernet0/0
O E2  11.1.1.0/24 [110/1] via 192.168.36.3, 00:45:30, GigabitEthernet0/0
O E2  22.2.2.0/24 [110/1] via 192.168.36.3, 00:45:30, GigabitEthernet0/0
O E2  33.3.3.0/24 [110/1] via 192.168.36.3, 00:45:30, GigabitEthernet0/0
O E2  44.4.4.0/24 [110/1] via 192.168.36.3, 00:00:12, GigabitEthernet0/0
O E2  55.5.5.0/24 [110/1] via 192.168.36.3, 00:00:12, GigabitEthernet0/0
O E2  77.7.7.0/24 [110/1] via 192.168.36.3, 00:00:12, GigabitEthernet0/0
O E2  88.8.8.0/24 [110/1] via 192.168.36.3, 00:00:12, GigabitEthernet0/0
O E2  99.9.9.0/24 [110/1] via 192.168.36.3, 00:00:12, GigabitEthernet0/0
O E2  100.0.0.0/8 [110/1] via 192.168.36.3, 00:44:32, GigabitEthernet0/0
O E2  101.101.101.0/24 [110/1] via 192.168.36.3, 00:44:32, GigabitEthernet0/0
O E2  111.0.0.0/8 [110/1] via 192.168.36.3, 00:00:12, GigabitEthernet0/0
O E2  112.112.112.0/24 [110/1] via 192.168.36.3, 00:00:12, GigabitEthernet0/0

Excellent! All the previously missing routes now appear:

Newly visible routes (timestamp 00:00:12 shows they just appeared):

• 4.0.0.0/8, 5.0.0.0/8
• 7.0.0.0/8, 8.0.0.0/8, 9.0.0.0/8
• 44.4.4.0/24, 55.5.5.0/24
• 77.7.7.0/24, 88.8.8.0/24, 99.9.9.0/24
• 111.0.0.0/8, 112.112.112.0/24

All appear as O E2 (OSPF External Type-2), learned via R3 (192.168.36.3).

R6 now has full reachability to all BGP routes, including those R3 learned via iBGP from R4.

What Changed?

The flow for iBGP routes after enabling redistribute-internal:

Origin: AS 2000 (R7)
  ↓
R7 → R4 (iBGP)
  ↓
R4 → R3 (iBGP)
  ↓
R3 redistributes into OSPF ✓ (allowed with bgp redistribute-internal)
  ↓
R5, R6 receive via OSPF
  ↓
Success!

The redistribution block is lifted, and iBGP routes flow into OSPF.