This lesson explains the BGP synchronization rule. To understand what this is all about, make sure you understand why we need IBGP first. If you are a little fuzzy about IBGP, BGP split horizon and why we need IBGP full mesh adjacencies then please read my IBGP lesson first. Having said that, let’s look at the synchronization rule.
BGP synchronization is an old rule from the days where we didn’t run IBGP on all routers within a transit AS. In short, BGP will not advertise something that it learns from an IBGP neighbor to an EBGP neighbor if the prefix can’t be validated in its IGP.
It’s best explained with an example, take a look below:
Above we see 5 routers and 3 autonomous systems. When we want to get from R1 to R5 we’ll have to cross AS2, this makes AS2 our transit AS.
EBGP has been configured between R1/R2 and also between R4/R5. IBGP is configured between R2/R4 and R3 on top doesn’t run BGP at all.
The routers within AS2 are configured with OSPF, this is required since R2/R4 have to be able to reach each other to establish the IBGP session.
R1 will advertise a prefix in BGP, AS2 and AS3 will learn about this prefix…
Let me show you the configurations. We’ll use the topology from above but I added some IP addresses to it:
The OSPF configuration is really straight-forward. R2 and R4 have a loopback interface that is used for the IBGP peering which is advertised in OSPF:
R2# router ospf 1 network 126.96.36.199 0.0.0.255 area 0 network 192.168.23.0 0.0.0.255 area 0
R3# router ospf 1 network 188.8.131.52 0.0.0.255 area 0 network 192.168.23.0 0.0.0.255 area 0 network 192.168.34.0 0.0.0.255 area 0
R4# router ospf 1 network 184.108.40.206 0.0.0.255 area 0 network 192.168.34.0 0.0.0.255 area 0
Let me also show you the BGP configuration…
The configuration of R1 is simple, it’s configured to run EBGP with R2 and it advertises network 220.127.116.11 /24 into BGP:
R1# router bgp 1 no synchronization bgp log-neighbor-changes network 18.104.22.168 mask 255.255.255.0 neighbor 192.168.12.2 remote-as 2 no auto-summary
R2 runs EBGP with R1 and IBGP with R4:
R2# router bgp 2 no synchronization bgp log-neighbor-changes neighbor 22.214.171.124 remote-as 2 neighbor 126.96.36.199 update-source Loopback0 neighbor 188.8.131.52 next-hop-self neighbor 192.168.12.1 remote-as 1 no auto-summary
R4 is similar to R2:
R4# router bgp 2 no synchronization bgp log-neighbor-changes neighbor 184.108.40.206 remote-as 2 neighbor 220.127.116.11 update-source Loopback0 neighbor 18.104.22.168 next-hop-self neighbor 192.168.45.5 remote-as 3 no auto-summary
And finally R5, it only runs EBGP with R4:
R5#show run | b router bgp router bgp 3 no synchronization bgp log-neighbor-changes neighbor 192.168.45.4 remote-as 2 no auto-summary
By default, BGP synchronization is disabled. You can see the no synchronization command in the configurations of the routers above. Let’s take a “before” and “after” look..
BGP synchronization disabled
We’ll take a look at R4 and R5, see if they learned about the 22.214.171.124 /24 network which is advertised on R1 and forwarded by R2 through IBGP:
R4#show ip bgp BGP table version is 10, local router ID is 126.96.36.199 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i188.8.131.52/24 184.108.40.206 0 100 0 1 i
R4 knows about this prefix and installed it…what about R5?
R5#show ip bgp BGP table version is 6, local router ID is 220.127.116.11 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 18.104.22.168/24 192.168.45.4 0 2 1 i
Great, R5 also knows about this network. The problem in this scenario however is that we will never get any IP packets from AS3 to AS1 since R3 doesn’t run BGP…it will never learn about network 22.214.171.124 /24 so whenever R4 forwards something, it will be dropped. Take a look at R3 here:
R3#show ip route 126.96.36.199 % Network not in table
To synchronization rule was created to prevent this problem. Let’s find out how it works…
BGP synchronization enabled
Let me show you what happens when we enable it, you have to do this on the border routers (R2 and R4):
R2(config)#router bgp 2 R2(config-router)#synchronization
R4(config)#router bgp 2 R4(config-router)#synchronization
Take a look again at R4:
R4#show ip bgp BGP table version is 11, local router ID is 188.8.131.52 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i184.108.40.206/24 220.127.116.11 0 100 0 1 i
R4 sees the network in its BGP table but refuses to install it.
Very nice explanation as usual. Please let me know once you have uploaded VRF-lite, Inter VRF-Routing, EVN, NAT64, etc… on your web. I can’t wait to see those on your web coz I know you will make us understand clearly for sure.
That was a very detailed explanation. very straight forward. Thanks
Hi Rene, i am confused to understanding this concept. please help.
So what I could figure-out so far is :-
"In a transit AS scenario, Enabling BGP sync made sense. because otherwise our ASBR router will advertise EBGP routes (learned from EBGP neighbor) to other internal routers as well and ultimately may become a transit AS for both EBGP neighbors which we don’t want.
So the rule said if we learn a route from IGP then only we should advertise it to other EBGP neighbor. that means we are only advertising network that we own.... Continue reading in our forum
But now this rule is not needed in t
BGP synchronization is an old rule in a time where not all routers within the AS were running IBGP. The problem here is not that we don’t want to become a transit AS, but that R5 is learning a route that it can’t reach (because R3 will drop the traffic).
By enabling synchronization, we will not advertise this network to R5 anymore which might be a better idea compared to advertising something that is unreachable. Only once the route is known in the IGP, we know that R3 will be able to forward the traffic and only then we will advertise the route to... Continue reading in our forum