BGP Synchronization

The BGP synchronization rule states that a BGP router cannot use an IBGP-learned transit route nor advertise it to an EBGP peer; unless it is synchronized in both BGP and IGP routing tables – IGP has redistributed and propagated it across the AS and installed it in the local IP routing table. BGP running in a transit AS that is passing traffic between ASes should not advertise a route before all routers in the AS have learned about the route via IGP. The BGP synchronization rule ensures consistency information throughout an AS to avoid routing black holes within the AS, eg: advertising a destination to an EBGP neighbor when not all routers within the AS can route to the destination.

BGP synchronization should only be used when there are routers in the AS that do not run BGP. It is safe to disable BGP synchronization only if all routers in the transit path in the AS – the path between the BGP border routers, are running BGP; or when the AS is not a transit AS. BGP synchronization is enabled by default in earlier version of Cisco IOS releases. Most current Cisco IOS releases (Cisco IOS Release 12.2(8)T and later) has disabled BGP synchronization by default, as most ISPs run BGP on all routers within their ASes.

BGP Synchronization

RT1, RT2, RT3, and RT4 are running BGP with each other – full-mesh IBGP. There are no matching IGP route entries for the BGP route – 172.16.0.0/16. RT3 and RT4 are not redistributing the BGP route into the IGP. RT1, RT2, RT3, and RT4 have IGP routes to the internal networks of AS 65001 but do not have routes to external networks, eg: 172.16.0.0/16.

The following happens if synchronization is on in AS 65001:
 RT4 advertises the route to 172.16.0.0/16 to the other routers in AS 65001 via IBGP.
 RT4 uses the route to 172.16.0.0/16 and installs it in its IP routing table.
 RT1, RT2, and RT3 do not use or advertise the route to 172.16.0.0/24 until they receive the matching route via an IGP. Since RT4 does not redistribute BGP routes into the IGP, these routers never use and advertise the route.
 RT5 does not hear about 172.16.0.0/24. RT5 does not have a route to 172.16.0.0/16 and therefore unable to send traffic destined to the network.
The solutions are i) redistribute the BGP routes into the IGP; ii) disable BGP synchronization.

The following happens if synchronization is turned off in AS 65001:
 RT4 advertises the route to 172.16.0.0/16 to the other routers in AS 65001 via IBGP.
 RT1, RT2, and RT3 use and advertise the route to 172.16.0.0/16 that they receive via IBGP and install it in their IP routing tables. RT1, RT2, and RT3 must be able to reach the next-hop address for 172.16.0.0/16, via static or IGP routes.
 RT5 hears about 172.16.0.0/16 from RT3. RT5 has a route to 172.16.0.0/16 and therefore able send traffic destined to the network.
 When RT5 sends traffic for 172.16.0.0/16, RT1, RT2, and RT3 route the packets to RT4. The traffic flow is RT5 > RT3 > RT1 > RT2 > RT4 > RT6.

Redistributing BGP into IGP is not scalable due to the large size of the Internet routing table. Therefore, most modern transit ASes run full-mesh IBGP and disable synchronization. Some advanced BGP configuration methods, eg: route reflection and confederation, redefine the IBGP full-mesh requirements and implementations.