BGP Synchronization
Last updated
Last updated
BGP synchronization can be a little confusing when you first learn about it. It is commonly defined as the following:
The reasoning behind this I believe comes from RFC1771 which states:
The idea is that an AS should not advertise a route that the AS as a whole cannot route to. Because of the full-mesh requirement for iBGP, it is possible that edge routers in an AS run a multihop iBGP session and learn routes from each other, but transit routers in the AS do not know these routes, and drop the traffic. This would happen if the transit routers are not in a full iBGP mesh. In this case, it would be better if the AS simply doesn’t advertise the routes to the eBGP peer in this case, so that the eBGP peer can possibly use a less preferred but “working” alternate path to the same prefixes.
Years ago, a valid design was to have routers on the edge run multihop iBGP sessions between themselves. They would learn eBGP routes and advertise them to other edge routers via iBGP. Transit routers in the AS would not run iBGP because the operators wanted to avoid needing a full iBGP mesh. Instead the edge routers would redistribute BGP into the IGP. Back then there weren’t as many prefixes in the internet routing table (as you can imagine), so this was a valid design. While BGP routes were redistributed into the IGP, IGP routes were not redistributed back into BGP, to prevent any local prefixes from being injected into BGP. Instead the edge routers learn iBGP routes and advertise these to the eBGP peers.
ASN 100 edge routers run a multihop iBGP session, but the transit routers do not run iBGP. ASN 100 might redistribute BGP into the IGP. The edge routers should use BGP sync to ensure that any routes they advertise to an eBGP peer won’t get dropped at a transit router.
So you might think that when you enable BGP sync, an iBGP-learned route that is not “synchronized” (known via the IGP) can be used locally by the router, but not advertised to an eBGP peer. This is not the case, which can be the source of some confusion. The BGP sync rule in practice is a little more simplistic: if an iBGP-learned route is not synchronized, it is simply not eligible for use. This is similar to if the next-hop on a prefix is not reachable - the route is seen in the BGP RIB but it is not installed into the RIB.
It is important to realize that modern hardware disables BGP synchronization by default. This is usually a feature which you do not have to worry about. However, it is useful to understand how it works.
Of course, in an MPLS network, VPNv4 routes are not IP routed by the transit routers anywas. MPLS allows traffic to essentially be tunneled from PE to PE. This is how a “BGP free” core works. For this reason you would be hard pressed to see BGP sync in use in a network today.
To demonstrate BGP sync, we will use a simple topology. R1 and R2 run iBGP, and R2 and R3 are eBGP peers.
First, notice that when you enable BGP on modern equipment, no synchronization is set by default.
Below is the startup config for each router:
Only R2 needs to enable BGP sync for us to examine the feature. It is a local feature; it is not signaled between routers.
We’ll configure a prefix on R1 and advertise it via iBGP to R2:
On R2 we enable debuging for BGP updates, and we see that 100.100.100.100/32 is not valid, because an IGP path for the prefix doesn’t exist in the RIB.
As a consequence, R2 does not advertise the route to R3.
R3 has no known BGP routes
Simply advertising the loopback into the IGP on R1 will allow R2 to consider the prefix in the BGP RIB valid.
Interestingly, even a static route works for considering an iBGP-learned prefix “synchronized.” We’ll remove the IGP advertisement of the loopback, and configure a null0 static route on R2.
You also have to make sure that the iBGP route doesn't get installed into the RIB. Strange, right? In order for the iBGP route to be considered “synchronized” the IGP/static prefix needs to be present in the RIB. If the iBGP route “beats” it, the iBGP route is no longer synchronized, and the route flaps in and out of the RIB. By default, the AD of iBGP (200) should always beat an IGP/static route though. You would have to deliberatly change the AD values to run into this issue.
To demonstrate this, we can make the iBGP administrative distance less than OSPF’s AD.
Once lo100 is advertised via OSPF again, we see a flood of debug messages on R2. The iBGP continually flaps in and out of the RIB, because when the OSPF route is lost from the RIB, the route is no longer synchronized.
https://www.ccexpert.us/ccie-2/ibgp-advanced-configuration-synchronization-rule.html
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#synch
https://www.youtube.com/watch?v=ttPDy4w0EfM&ab_channel=PacketPushers
Excellent presentation from Russ White on iBGP peering. BGP Sync is mentioned around 3 minutes in.
