Demystifying BGP Synchronization

BGP synchronization is not commonly used today, however still part of the Cisco CCIE certification and must be understood by all candidates trying to obtain the certification. Further there may be some rare cases where this feature is still needed. Reading through literature, I found different definitions of how BGP synchronization works, especially when it comes to the details. All sources commonly describe the purpose of BGP synchronization. Avoid blackholing traffic by adding an additional constraint before advertising a route to an eBGP peer, which is: “Only advertise a route learned from an IBGP peer to an eBGP peer when there is an exact match of that route learned from an IGP in the routing table“. Look at the following graphic why this would be an issue:

Let’s look at the 1.1.1.0/24 prefix which is originated by R1 in AS50. R2 and R4 are the border routers of AS100 and form a iBGP relationship to each other. Let’s look at the configuration in AS100, without sync enabled. The IP address numbering scheme is easy: 10.10.<link>.<router>, where the link between R2 and R4 is 24. Hence, R4s address between R3 and R4 is 10.10.34.4. The configuration looks as follows:

Pretty basic, huh? R5 learns about the 1.1.1.0/24 prefix from R4, but is not able to ping to the destination. R1 advertises the prefix to R2. R2 forwards it to R4, and has next-hop-self configured. This means the Next Hop field in the BGP update is set to 10.10.23.2, which is R2s outgoing interface towards R4. R4 then forwards the prefix to R5, so everything should work?

The problem is at R3, however. As R3 does not participate in the BGP process and hence does not learn about the BGP routes. In fact, it only learns about the internal networks from EIGPR:

Hence AS100 advertises a path to other eBGP peers, but is not able to forward it, as R3 will throw the traffic away. There are two possible solutions to this problem:

• Configure R3 to be part of the BGP process, hence it learns the BGP routes and knows how to forward them. Depending of the network size, this can be a considerable amount of iBGP peerings or requires scaling techniques such as Route Reflectors or Confederations.
• Redistribute BGP routes into EIGRP and enable synchronization

Redistributing is required to provide R3 with reachability information. Synchronization is used to avoid traffic black holing. Let’s enable synchronization on R4:

Now, the network is not advertised to R5 anymore, as R4 does not have a matching route from an IGP in its routing table.

We can see that the only available path is not synchronized and hence cannot be selected as best path. Since there is no best path, no path can be advertised to any peer. As soon as we redistribute the BGP paths coming from AS50 into EIGRP on R2, this should change:

Now, R4 has a route to 1.1.1.0/24 and hence advertises it again to R5. Now, R5 is also able to ping the destination, as R3 now has reachability information

In particular, note the line which is showing RIB-failure(17) at R4 for the route 1.1.1.0/24. As R4 is learning that route from EIGRP (AD 170) and iBGP (AD 200) the EIGRP route is preferred and BGP cannot put the selected best path into the routing table. This however is not a necessary condition to advertise it further.

BGP Synchronization an Route Reflector

Most sources however source that this is only relevant to external peers. And this is where some confusion comes in. One required condition for BGP to advertise a path to a neighbor (whether it is iBGP or eBGP) is to have a valid best path for that prefix, otherwise it cannot be selected. One general rule is that a route which is being learned from an iBGP peer is not forwarded to another iBGP rule, hence the synchronization rule does not apply in this case. But what about route reflectors? Consider the following topology:

Similar topology, but R2 and R4 no longer have a peering directly to each other, but use R3 as a route reflector. Intuitively thinking, synchronization would not make any sense in that case, as R3 is part of the BGP routing domain, and hence knows the path to 1.1.1.0/24. But what happens if it is enabled nonetheless? We can be sure that R4 would not advertise the prefix to R5, as shown in the previous example. But would it get to R4 in the first place?

According to what we’ve seen above, synchronization would prevent R3 to select the route learned from R2 as best path, and hence should not advertise it further. Here are the relevant running configurations for this example, synchronization already enabled on all routers, but redistribution disabled again.

Recall that the synchronization rule is only valid if the route is learned from an external peer. We can verify that on R2, which advertises the rule to R3

The route is tagged “external“, and note that there is no entry whether the path is synchronized or not. As R2 is learning it from an eBGP peer, that is fine. No let’s take a look at R3:

R3 learns the route from R2 and installed it in his BGP table. As route-reflector, it should advertise the route to its route-reflector clients, being R4 in this case. But note that the path is not synchronized and hence can never be selected as best path. It is hence not advertised to any neighbor, including it’s iBGP neighbors.

Prove with another Prefix

Now, let us add another prefix originated by R1 (AS50), being 5.5.5.0/24. Further, redistribute this network, but not 2.2.2.0/24 into EIGRP at R2.

Now let us look at R3 again:

Now we can see that 1.1.1.0/24 is not synchronized and hence not advertised any further, but 5.5.5.0/24 is synchronized and hence reflected to the other iBGP route-reflector clients. On R5 we can see that only 5.5.5.0/24 is advertised from AS100, but not 1.1.1.0/24

Summary

TL;DR and Summary: Many books and sources state that synchronization is used to prevent advertising routes to eBGP neighbors to prevent traffic black holing, but does not affect internal advertisements. While this was the original intention, this statement is not precise and even wrong. More precisely, the BGP synchronization rule should be stated:

During the BGP decision process, a route learned from an iBGP peer can only be considered as best path, when there is an exact match of the prefix in the routing table, learned by any IGP.

When there is no best path, the prefix is simply not advertised any further, regardless if the neighbors are iBGP or eBGP peers.