BGP helicopter view

If you ask someone some simple BGP questions, like why do iBGP peers need to be fully meshed, and does this have anything to do with Synchronization, and do we need to run BGP on all the network routers, and so on, you can get him into the confusion area, or to unorganized statements, so lets discuss all these aspects in brief in order not to find your self in this position :)

We must first draft out our keywords; Split-horizon, Synchronization, loop prevention, black-hole, full mesh, Route reflectors, Confederation, scalability and BGP free core.

Well, BGP like any other routing protocol needs a loop prevention mechanism in order to prevent routing loops. eBGP differs than iBGP in how it implements the loop prevention, eBGP uses the AS_Path attribute in order to do loop prevention - any prefix received with the local AS in its AS-Path attribute is dropped. While with iBGP it uses a split-horizon mechanism (can't use the AS_PATH, since it is not changed with an AS), stating that a prefix received from an iBGP neighbor is never advertised to another iBGP neighbor, this mechanism obligated the need of full mesh between all the iBGP neighbors in order for each of them to learn all the prefixes.

Doing iBGP in full mesh is not a scalable solution, since it implies a huge number of sessions to be configured and maintained (n(n-1)) plus prefixes replications overhead and waste of resources (impact on CPU, memory and network bandwidth), and thus here came the Route reflectors and Confederation part. They work around the need of iBGP sessions full mesh, and thus provides a scalable network design - We will have an in depth look into them in later posts.

On the other hand, as a method of circumventing black-holes in transit networks, Synchronization was introduced. This rule simply states that inside a transit AS, an IBGP learned prefix is never sent to an EBGP neighbor unless it is validated via the IGP, this prevents a transit router to claim that it knows how to reach a network via BGP while it can't actually reach this network (creating a black-hole). This rule formerly required the redistribution of the BGP routes into the IGP, in order for the BGP routes to be always validated via the IGP, but this approach has gone very limited and non scalable, since the internet routing table has exceed 250,000 prefix nowadays (August 2008) and this is a problem for IGPs, thus this approach can't be implemented anymore, and thus in modern IOS codes the synchronization is disabled by default (since 12.2(8)T). In order to still prevent black-holes in transit networks, we are obligated to run BGP on all the network routers instead, since BGP is the only routing protocol that can handle this amount of prefixes, and thus each and every router in the transit network will be capable to reach each and every destination learned via BGP, and thus preventing back-holes while circumventing the need for enabling synchronization.

As illustrated in the previous paragraph, the need for running BGP on all the network routers came to prevent black-holes in transit networks by making sure that all the destinations are known by all the routers in the transit network, while being able to safely turning synchronization off. This required all the Service providers world wide to enable BGP on all their routers, even the very fast high capacity core routers. This need was circumvented by the introduction of MPLS, with MPLS the core routers no longer need to learn the destination prefixes since they won't be doing normal IP lookups, this would be replaced by label switching. Thus, the core routers in the service provider network no longer need to run BGP, only the edge routers do, and this is what is called BGP free core.

I hope that I've been informative, and that I've cleared things out in brief, we shall be handling all these items in details later.

BR,
Mohammed Mahmoud.