BGP synchronization can be a little confusing when you first learn about it. It is commonly defined as the following:
BGP synchronization states that a router should not advertise an iBGP-learned route
to an eBGP peer, unless it is known via the IGP.
The reasoning behind this I believe comes from RFC1771 which states:
To characterize the set of policy decisions that can be enforced
using BGP, one must focus on the rule that a BGP speaker advertise to
its peers (other BGP speakers which it communicates with) in
neighboring ASs only those routes that it itself uses.
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.
Lab
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.
R1#conf t
R1(config)#router bgp 65000
R1(config-router)#end
R1#show run all | sec router bgp
router bgp 65000
no synchronization
Below is the startup config for each router:
#R1
interface GigabitEthernet1
ip address 10.1.2.1 255.255.255.0
ip ospf network point-to-point
ip ospf 1 area 0
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 0
!
router bgp 65000
neighbor 2.2.2.2 remote-as 65000
neighbor 2.2.2.2 update-source Loopback0
#R2
interface GigabitEthernet1
ip address 10.1.2.2 255.255.255.0
ip ospf network point-to-point
ip ospf 1 area 0
!
interface GigabitEthernet2
ip address 10.2.3.2 255.255.255.0
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
!
router bgp 65000
synchronization
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source Loopback0
neighbor 10.2.3.3 remote-as 65003
#R3
interface GigabitEthernet1
ip address 10.2.3.3 255.255.255.0
!
router bgp 65003
neighbor 10.2.3.2 remote-as 65000
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:
int lo100
ip address 100.100.100.100 255.255.255.255
!
router bgp 65000
network 100.100.100.100 mask 255.255.255.255
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.
R2#debug bgp ipv4 unicast updates in
BGP updates debugging is on (inbound) for address family: IPv4 Unicast
R2#
*Nov 28 22:53:27.983: BGP(0): 1.1.1.1 rcvd UPDATE w/ attr: nexthop 1.1.1.1, origin i, localpref 100, metric 0
*Nov 28 22:53:27.983: BGP(0): 1.1.1.1 rcvd 100.100.100.100/32
*Nov 28 22:53:27.983: BGP(0):
! Below, the prefix is known in the BGP RIB, but it is not best (no > indicator)
R2#show ip bgp
BGP table version is 1, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
* i 100.100.100.100/32
1.1.1.1 0 100 0 i
As a consequence, R2 does not advertise the route to R3.
R3#show ip bgp
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.
#R1
int lo100
ip ospf 1 area 0
#R2
*Nov 28 22:55:51.767: BGP(0): redist event (1) request for 100.100.100.100/32
*Nov 28 22:55:51.767: BGP(0): route 100.100.100.100/32 up but not redist, deleting
*Nov 28 22:55:51.768: BGP(0):
*Nov 28 22:55:51.768: BGP(0): Revise route installing 1 of 1 routes for 100.100.100.100/32 -> 1.1.1.1(global) to main IP table
*Nov 28 22:55:51.769: BGP(0): (base) 10.2.3.3 send UPDATE (format) 100.100.100.100/32, next 10.2.3.2, metric 0, path Local
! The prefix is now valid, although it fails to install into the RIB
R2#show ip bgp | be Network
Network Next Hop Metric LocPrf Weight Path
r>i 100.100.100.100/32
1.1.1.1 0 100 0 i
! Nevertheless, even if the prefix fails to install into the RIB, it is still advertised to eBGP peers
R3#show ip bgp | be Network
Network Next Hop Metric LocPrf Weight Path
*> 100.100.100.100/32
10.2.3.2 0 65000 i
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.
#R1
int lo100
no ip ospf 1 area 0
#R2
*Nov 28 22:58:34.514: BGP(0): redist event (2) request for 100.100.100.100/32
*Nov 28 22:58:34.514: BGP(0): route 100.100.100.100/32 down
*Nov 28 22:58:34.514: BGP(0): no valid path for 100.100.100.100/32
*Nov 28 22:58:34.514: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 100.100.100.100/32
*Nov 28 22:58:34.515: BGP(0): (base) 10.2.3.3 send unreachable (format) 100.100.100.100/32
R2(config)#ip route 100.100.100.100 255.255.255.255 null0
R2(config)#
*Nov 28 22:58:54.360: BGP(0): redist event (1) request for 100.100.100.100/32
*Nov 28 22:58:54.360: BGP(0): route 100.100.100.100/32 up but not redist, deleting
*Nov 28 22:58:54.360: BGP(0): route 100.100.100.100/32 synced
*Nov 28 22:58:54.361: BGP(0): Revise route installing 1 of 1 routes for 100.100.100.100/32 -> 1.1.1.1(global) to main IP table
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.
#R2
no ip route 100.100.100.100 255.255.255.255
!
router bgp 65000
distance bgp 20 100 100
#R1
int lo100
ip ospf 1 area 0
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.
*Nov 28 23:03:01.964: BGP(0): redist event (1) request for 100.100.100.100/32
*Nov 28 23:03:01.964: BGP(0): route 100.100.100.100/32 up but not redist, deleting
*Nov 28 23:03:01.964: BGP(0): route 100.100.100.100/32 synced
*Nov 28 23:03:01.964: BGP(0): Revise route installing 1 of 1 routes for 100.100.100.100/32 -> 1.1.1.1(global) to main IP table
*Nov 28 23:03:01.964: BGP(0): no valid path for 100.100.100.100/32
*Nov 28 23:03:01.966: BGP(0): redist event (2) request for 100.100.100.100/32
*Nov 28 23:03:01.966: BGP(0): route 100.100.100.100/32 down
*Nov 28 23:03:01.966: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 100.100.100.100/32
*Nov 28 23:03:01.969: BGP(0): redist event (1) request for 100.100.100.100/32
*Nov 28 23:03:01.970: BGP(0): route 100.100.100.100/32 up but not redist, deleting
*Nov 28 23:03:01.970: BGP(0): route 100.100.100.100/32 synced
*Nov 28 23:03:01.970: BGP(0): Revise route installing 1 of 1 routes for 100.100.100.100/32 -> 1.1.1.1(global) to main IP table
*Nov 28 23:03:01.970: BGP(0): no valid path for 100.100.100.100/32
*Nov 28 23:03:01.972: BGP(0): redist event (2) request for 100.100.100.100/32
*Nov 28 23:03:01.972: BGP(0): route 100.100.100.100/32 down
*Nov 28 23:03:01.972: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 100.100.100.100/32
*Nov 28 23:03:01.976: BGP(0): redist event (1) request for 100.100.100.100/32
*Nov 28 23:03:01.976: BGP(0): route 100.100.100.100/32 up but not redist, deleting
*Nov 28 23:03:01.976: BGP(0): route 100.100.100.100/32 synced
*Nov 28 23:03:01.976: BGP(0): Revise route installing 1 of 1 routes for 100.100.100.100/32 -> 1.1.1.1(global) to main IP table
*Nov 28 23:03:01.976: BGP(0): no valid path for 100.100.100.100/32
*Nov 28 23:03:01.978: BGP(0): redist event (2) request for 100.100.100.100/32
*Nov 28 23:03:01.978: BGP(0): route 100.100.100.100/32 down
