BGP Synchronization

BGP synchronization is something that can easily be misunderstood.  This is particularly the case since it is now disabled by default on Cisco devices.  Let’s start with a basic configuration and build on it to see how synchronization can affect BGP route propagation…

Right off the bat, you should be looking at this and asking why router5 isn’t part of AS 200.  You should be thinking that because we are used to dealing with BGP that has synchronization disabled by default.  Ensuring that all of your routers within an AS are part of the iBGP mesh is one way to solve the synchronization problem.  Before I get too far ahead of myself, let’s see the problem in action.

Let’s assume that router1 has an eBGP peering with router2.  Router2 and router3 are iBGP peered and router3 and router4 are once again eBGP peered.  In addition, we are running an IGP (OSPF) between router2, 3, and 5.  At this point, I’m also going to enable synchronization on all four BGP routers.  Recall, the default is to have synchronization disabled.  Finally, I’m going to originate the prefix 175.100.0.0 /16 from router1 towards router2 over the eBGP session.  At this point, our routing configuration looks like this on all 5 routers…

Now, let’s take a look at the BGP tables on routers 2, 3, and 4…

Above, we can see that router2 is receiving the prefix from router1.

On router3, we can see that it is receiving the prefix over the iBGP session.  Note that the next hop still shows as 10.0.0.14.  iBGP speakers do NOT change the next hop when they advertise the prefix.

However, as we see above, router4 is not receiving the prefix over the eBGP peering.  This is a perfect example of the rule of synchronization.  The rule states…

If your AS passes traffic from another AS to a third AS, BGP should not advertise a route before all routers in your AS learn about the route via IGP. BGP waits until IGP propagates the route within the AS and then advertises it to external peers. A BGP router with synchronization enabled does not install iBGP learned routes into its routing table if it is not able to validate those routes in its IGP. Issue the no synchronization command under router bgp in order to disable synchronization. This prevents BGP from validating iBGP routes in IGP.

So let’s check out router3…

Since the route isn’t being learned by the IGP, the rule of synchronization is kicking in.  Note that above we did the see the route in the BGP table, however as the rule states, the iBGP learned route will not be inserted into the IP routing table nor will it be advertised to eBGP peers.

Let’s disable synchronization on router3 and see what happens…

Looking at router4, we see we now have reachability to the 175.100.0.0 network…

Note: to get the pings to work I created a loopback on router1 for 175.100.0.1 and added a static default route pointing to 10.0.0.13.

However, let’s try something.  Let’s break the link between router2 and router3.

Luckily I had the sense to iBGP peer router2 and router3 using their loopbacks.  The IGP (OSPF) will converge and the two routers will maintain their BGP session.  As far as the 175.100.0.0 /16 prefix is concerned, it is still being advertised through the network and reaching router4.  However, router4 can no longer actually reach that IP space…

This is exactly the scenario that synchronization was designed to protect us from.  Let’s look closer at what’s occurring…

Router3 still has the prefix in it’s BGP table and claims the next hop is 10.0.0.14.  As we discussed, this makes sense since the last eBGP speaker to advertise the prefix was router1.  Router3 also knows that the best way to get to 10.0.0.14 is up through router5 since the path between router2 and router3 has been broken.

However, since router5 is not participating in the iBGP mesh, it has no idea how or where to forward traffic for 175.100.0.0 /16.

There are two ways to fix this solution.  One is to maintain a full iBGP mesh between all routes in an AS.  As I eluded to earlier, this is the most common scenario and what immediately comes to mind when you look at the lab diagram.

The second option is to redistribute BGP routes in the IGP.  This works, but would be a really big pain when you start talking about large BGP tables.  BGP was built to handle hundreds of thousands of prefixes.  OSPF was not.  Nonetheless, let’s re-enable synchronization on router3, fix the link between router2 and router3, and then redistribute the BGP prefixes into OSPF to prove that it works.

After fixing the link and re-enabling synchronization we can see that once again, router4 is not receiving the prefix…

Now let’s redistribute the prefix on router2 from BGP into OSPF…

We can see that router5 now has the external prefix as a OSPF E2 route as it should…

Now let’s look at router3 to see what it thinks…

In the first output you can see that it now knows about 175.100.0.0/16 from OSPF and has inserted that into the main IP routing table.  However, as seen in the second output, it is also learning it from the iBGP session.  Finally, the third output shows that it is now advertising the route to router4.

Looking at router4 we now see that it is once again able to ping the loopback on router1…

Like I said, we’re used to dealing with BGP when synchronization is disabled since that’s the default setting.  Keep in mind that when it’s off you should have a full iBGP mesh within an AS.  When it’s on, you need to redistribute the routes into the underlying IGP.