Cisco Support Community
VIP Purple

BGP and IGP redistribution


I am getting a little confused on the concept of redistributing BGP into an IGP such as OSPF or EIGRP.

If BGP has synchronization enabled, does it automatically check whatever routes the IGP has in its routing tables ? How does BGP 'know' about the IGP ? And is mutually redistributing the IGP and BGP a substitute for synchronization ?



Community Member

Re: BGP and IGP redistribution

BGP sync is enabled for default.(you can disable it)

BGP learned routes will not be writted into routing table or transited to other ibgp peers except the routes have existed

in the routing table(Whatever routes appears as IGP,static or even ibgp) The perpose of it is to avoid traffic blackhole. If full meshed or use RR or confederation ,you can disable sync to IGP.

And your last question,I feel that if BGP can not write routes to routing table, these routes cannot be redistributed

into IGP. So redistribute cannot replace sync.


Re: BGP and IGP redistribution

Sortof.... Synch checks to make certain a route is in the routing table from some other source than BGP before advertising it. It's designed to prevent routing black holes in a network where there is BGP only on the edges, and not in the center of the network.

In fact, the point of synch was to force everyone to redistribute eBGP learned routes into their IGP, so all the routing tables matched. We don't do this any longer, since we run BGP on all the routers in the network which might touch a transit packet, or we run MPLS, where label distribution solves this problem.

So.... Redistribution into the IGPs can replace configuring no synch. In either case, if you are transiting traffic, you muct make certain the routers in the middle know how to handle the transit traffic. If you're not, you don't care abot synch, turn it off.

Synch is off by default in newer IOS images.


Community Member

Re: BGP and IGP redistribution

Just some further information. Sync only occurs when a route is learned by IBGP. If sync is on, and the route is not learned by an IGP, the route won't be forwarded by EBGP. If sync is on, and the route is learned by the IGP, it is advertised onwards by EBGP. It has nothing to do with taking a route learned by EBGP and advertising it into IBGP.




Re: BGP and IGP redistribution

Okay, suppose you have three routers:


A is learning some eBGP routes, and has an iBGP session to C, so it sends these routes to C. B doesn't know about them. Any traffic C sends to A along these routes will be dropped by B, since it has no knowledge of the destinations. In the "old world," when the Internet routing table was small, and people only ran BGP at the edges of their networks, you would redistribute your eBGP learned routes into your IGP, so B would know about them. C would learn the same routes via iBGP and an IGP.

Some people didn't configure things this way, and caused black holes in the Internet. So, synchronization was invented--the route had to be in the IGP table before it could be advertised to an eBGP peer. Synch _is_ related to redistributing eBGP into the IGP. How else are the eBGP learned routes on A going to get into the IGP table for B and C to learn them? The only other way would be for the route to originate within the AS, in which case they are not transit, and synch doesn't apply.

Note another artifact from this: If you redistribute from BGP into an IGP, which routes ar redistributed? Always eBGP, never iBGP. Why is that? Because to get your IGP table to synch with your BGP table, you only redistribute eBGP into the IGP at every edge....

Now, what people do today is to run BGP on B, so B now knows what routes exist at both edges. Either this is done through route reflection, or a full iBGP mesh, or confederations. So, now we don't need the IGP table and BGP tables to synch. There are no routing black holes, because all the transit routers in the network (B) have full routing tables.

So, now, since this is the most common network design, we turn synch off by default.


CreatePlease to create content