iBGP redistribution into IGP

[Mukarram Jah Raheel]

Earlier, iBGP could not be redistributed into IGP until the emergence of the following command :

"bgp redistribute-internal"

but it is still not recommended to redistributed iBGP into IGP...

Kindly comment on why is the redistribution not allowed by default

[Giuseppe Larosa]

Hello Mukarram,

the reason is to protect the IGP:

BGP can support hundreds of thousands of routes but an IGP can support only a few thousands so the risk is to cause an IGP crash because of too many routes that potentially can be injected into it.

Hope to help

Giuseppe

[Mukarram Jah Raheel]

hello guislar,

thanks for the reply...

routes learned through eBGP are far more in number than iBGP routes....

iBGP routes simply are routes within the service provider network ..

and the eBGP redistribution is by default allowed....

prevention of iBGP redistribution to IGP is understandable on core(internal) routers where eBGP routes are recieved as iBGP from edge routers...

but if redistribution is enable on edge routers from eBGP to IGP ... IGP would still received all routes ....

[Giuseppe Larosa]

Hello Mukarram,

>> iBGP routes simply are routes within the service provider network ..

all BGP routes can be seen as iBGP if received from an iBGP peer not only the routes originated within the AS.

when you see an initial i on a sh ip bgp this means that the eBGP route is received on an iBGP peer.

>> but if redistribution is enable on edge routers from eBGP to IGP ...

This is not done anymore specially after the introduction of MPLS there is no need for this.

Hope to help

Giuseppe

[Mukarram Jah Raheel]

hello..

consider the following scenario...

R1-R2-R3

R1 & R2 are running eBGP neighbors

R2 & R3 are ospf neighbors

R2 is receiving all internet routes from R1..and is redistributing into OSPF...

therez no iBGP involved here...

therefore learning more than one hundred thousand routes is not just the case when using iBGP...

I guess the only reason iBGP redistribution is disabled by default is to protect routing loops within as AS and it has nothing to do with disability of IGP of handling so many routes... since redistribution of eBGP into IGP still causes the same issue

[Giuseppe Larosa]

Hello Mukarram,

let's take a real world example

sh ip bgp | inc 85.22.0.0

*>i85.22.0.0/16 212.31.226.77 0 160 0 8220 702 15763 i

sh ip bgp 85.22.220.0

BGP routing table entry for 85.22.0.0/16, version 170066047

Paths: (1 available, best #1, table default)

Multipath: eBGP iBGP

Not advertised to any peer

8220 702 15763

212.31.226.77 (metric 100) from x.x.x.x (x.x.x.x)

Origin IGP, metric 0, localpref 160, valid, internal, best

the network is learned from an iBGP peer and is treated as an iBGP route on this node.

real world full table is now in the range of 300,000 routes try to redistribute all these on OSPF and then tell me what will happen

Hope to help

Giuseppe

[Mukarram Jah Raheel]

that is ok....

my point is that we can also have redistribution from eBGP to IGP on edge routers... which is by default allowed...

[Steven-Williams-83]

What is the process for this on NXOS? I cannot find the "bgp redistribute-internal" command within the BGP process on NXOS. 

[Harold Ritter]

Hi @Steven-Williams-83 ,

In NXOS, you need to configure a route-map and "match route-type internal" to allow iBGP prefixes to be redistributed into an IGP, as follow:

router ospf 109

redistribute bgp 109 route-map bgp2ospf

!

route-map bgp2ospf permit 10

match route-type internal

Regards,

[Joseph W. Doherty]

Possibly because:

If we're dealing with Internet routes, volume of routes would crush an IGP.

When using BGP and an IGP, network design, generally, wouldn't benefit from BGP routes redistributed into IGP.