Redistribution between IGP and BGP

A BGP router separately maintains the BGP table and the IP routing table. The router can be configured to share information between the BGP table and the IP routing table via redistribution. Ships in the night (SIN) routing is the approach in which the IGPs and BGP are not communicating with each other via redistribution; both the IGPs and BGP routing updates share the same routers and network bandwidth resources, performing different and unrelated functions.

The IGP routing information can be advertised into BGP through one of the following ways:
 Using the network BGP router subcommand.
 Redistribute discard route (static route to the Null0) into BGP upon route summarization.
 Redistribute dynamically learned IGP routes into BGP. This approach is not recommended as it can cause instability and even routing loops if implemented inappropriately. Note that any change upon the IGP routes (eg: route flapping) will originate a BGP Update and results in high rate of BGP exchanges throughout an internetwork.
Note: Redistribute only local routes upon route redistribution; redistributing IGP routes that were actually learned through BGP redistribution earlier back into the BGP itself can results in routing loops. Implementing route filtering for such setups can be complex.
The redistribute BGP router subcommand results in an incomplete Origin attribute for the redistributed route, as indicated by the ? in the show ip bgp command output.

Note: OSPF does not inject external OSPF routes into BGP by default as a measurement to prevent routing loop in case the external OSPF routes were actually originated from BGP. The match external 1 external 2 keywords must be specified for the redistribute router subcommand under the BGP routing process in order to achieve the mentioned objective.

The BGP routing information may be sent into an AS by redistributing the BGP routes into IGP. Redistributing BGP routes into IGP may overwhelm the IP routing tables on routers with limited resources. Implement route filtering to control the prefixes to be redistributed into the IGP.
Note: RFC 1364 – BGP OSPF Interaction specified that the BGP Identifier must be the same as the OSPF Router ID when redistributing routes between BGP and OSPF.

Redistribution from BGP into IGP normally is not required for ISP ASes, which typically have all routers, or at least the routers in the transit path within the AS running BGP, with full-meshed IBGP and exchanging EBGP routes across the AS. Synchronization would be disabled on all the BGP routers as synchronization between IGP and BGP it not required. The BGP routes are not need to be redistributed into the IGP. The IGP would need to route only information local to the AS and routes to the next-hop addresses of the EBGP routes.

Redistributing BGP routing information into an AS may be necessary when an AS is running BGP only on its border routers and has other routers in the AS that do not run BGP but require knowledge of external routes.

IBGP routes are not redistributed into IGP by default. The bgp redistribute-internal BGP router subcommand enables the redistribution of IBGP routes into IGPs, eg: OSPF and IS-IS. Issue the clear ip bgp command to reset BGP connections after this command is configured. Implement route filtering to control the prefixes to be redistributed into the IGP.
Note: The redistribute bgp {as-num} [subnets] router subcommand is still required under the IGP process. The subnets keyword is applicable only for OSPF.

IBGP-IGP Redistribution

Below shows the routing table on RT3:

RT3#sh ip route

Gateway of last resort is not set

     3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback0
     23.0.0.0/24 is subnetted, 1 subnets
C       23.23.23.0 is directly connected, FastEthernet0/0
     172.16.0.0/24 is subnetted, 1 subnets
O E2    172.16.1.0 [110/1] via 23.23.23.2, 00:00:20, FastEthernet0/0
RT3#

Note: Redistributing IBGP routes into IGP can be dangerous – it can lead to routing loops as BGP cannot detect routing loops within an AS – it can only detect loops in EBGP routes; and the IGP metrics will be inconsistent from router to router.