BGP synchronization assumed an older approach of BGP deployment for a transit autonomous system. In this approach, BGP would be configured only on ASBRs, not on internal routers. The ASBRs would have eBGP peerings with outside autonomous systems, and they would also have iBGP peerings to each other. Internal routers, however, would not be running BGP.
Naturally, this constellation would result in blackholing traffic because while the ASBRs know all routes thanks to their eBGP and iBGP peerings, any internal router would have no idea about external networks. So as an additional step, the BGP routes were redistributed into the internal routing protocol. The full reachability would be therefore gained by combining the BGP on and between the ASBRs, and the redistribution of BGP routes into IGP within an AS. The internal routers are therefore spared the need to run full BGP.
Now, an ASBR can know about an external network from another iBGP peer via iBGP and theoretically, it can immediately install it into its routing table and advertise it to further eBGP neighbors. However, if the internal protocol, say, EIGRP, does not yet have that route fully advertised to all internal routers, advertising the route to eBGP neighbors would be futile: the traffic would be still misrouted or blackholed inside our AS until the EIGRP has truly advertised the network.
This is where BGP Synchronization comes in. An ASBR can know about a route via iBGP peering with another ASBR. However, it will not consider that route as valid until the same route comes through an IGP, say, EIGRP, and gets installed in the routing table. Seeing the route learned via iBGP installed as an IGP route means that the neighboring ASBR has redistributed the route correctly into EIGRP and that it is already known to all internal routers between that ASBR and your ASBR, and that means that the path is truly valid - each router on the path between you and the neighboring ASBR knows how to route packets to that destination.
So the state of seeing an iBGP-learned route as IGP-learned in your routing table means that the route itself is synchronized. Only now, you can consider the route as valid, subject it to BGP bestpath algorithm and advertise it to eBGP peers - not sooner.
"I already understand that Sync. must be disabled in case if i have a full meshed IBGP in order for IBGP routes to be entered in the IGP routing table."
iBGP peers must always be fully meshed (let us ignore route reflectors and confederations for now). However, the BGP synchronization should be deactivated if all your routers within an AS are BGP speakers and are supposed to learn the external routes via BGP. In such case, you would never redistribute BGP-learned routes into an IGP (there would be no sense in doing that as all routers speak BGP already) but the activated synchronization would prevent these routers from treating these iBGP-learned routes as valid.
In other words, the BGP Synchronization must be deactivated in all iBGP scenarios where BGP routes are not redistributed into IGP protocol. Otherwise, an iBGP speaker will wait for an iBGP-learned route to be also learned via IGP - which will never happen.
Please feel welcome to ask further!
Best regards,
Peter
https://supportforums.cisco.com/thread/2107257
:)
[ view entry ] ( 1920 views ) | print article
<<First <Back | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | Next> Last>>