8.3 Configuring BGP 
8.3.8 Synchronization within an AS
When an IBGP router receives an update about a destination from an IBGP peer, it tries to verify reachability to that destination via an IGP route, such as RIP or OSPF. If the IBGP router can not find the destination network in its IGP routing table, it will not advertise the destination to other BGP peers. If the route is not reachable through the IGP running within the AS, non-BGP routers will not be capable of routing traffic passing through the AS toward this destination. It is pointless to advertise destinations to external peers if traffic sent through this AS is going to be dropped by some non-BGP router within the AS.

If the IBGP router has an IGP route to this destination, the route is considered synchronized, and the router will announce it to other BGP peers. Otherwise, the router will treat the route as not being synchronized with the IGP and will not advertise it.

Consider the situation illustrated in the figure. ISP1 and ISP2 are using ISP3 as a transit AS. ISP3 has multiple routers in its AS and is running BGP only on the border routers. (Even though RTB and RTD are carrying transit traffic, ISP3 has not configured BGP on these routers.) ISP3 is using an IGP inside the AS for internal connectivity.

Assume that ISP1 is advertising route 192.213.1.0/24 to ISP3. Because RTA and RTC are running IBGP, RTA will propagate the route to RTC. Note that other routers besides RTA and RTC are not running BGP and have no knowledge of the existence of route 192.213.1.0/24.

In the situation illustrated in the Figure, if RTC advertises the route to ISP2, traffic toward the destination 192.213.1.0/24 will start flowing toward RTC. RTC will do a recursive lookup in its IP routing table and will direct the traffic toward the next hop, RTB. RTB, having no knowledge of the BGP routes, will drop the traffic because it has no route of the destination. This has happened because there is no synchronization between BGP and the IGP.

The BGP synchronization rule states that a BGP router should not advertise to external neighbors the destinations learned from inside BGP neighbors, unless those destinations are also known via an IGP. If a router knows about these destinations via an IGP, it assumes that the route has already been propagated inside the AS, and internal reachability is guaranteed.

The consequence of injecting BGP routes inside an AS is costly. Redistributing routes from BGP into the IGP will result in major overhead on the internal routers, which might not be equipped to handle that many routes. Besides, carrying all external routes inside an AS is not really necessary. Unless traffic is transiting the AS, internal non-BGP routers can simply default to one of the BGP routers. Of course, this may result in suboptimal routing because there is no guarantee for a shortest path for each route. Because the alternative is maintaining thousands of routes inside the AS, giving up optimal routing is well worth it.

The Cisco IOS offers an optional command called no synchronization. This command enables BGP to override the synchronization requirement, allowing the router to advertise routes learned via IBGP regardless of an existence of an IGP route.

In practice, two situations exist in which synchronization can be safely turned off on border routers:

  • When all transit routers inside the AS are running fully meshed IBGP. Internal reachability is guaranteed because a route that is learned via EBGP on any of the border routers will automatically be passed on via IBGP to all other transit routers.
  • When the AS is not a transit AS.