By definition, the BGP synchronization rule requires that when a BGP router receives information about a network from an I(nternal)-BGP neighbor, it does not use this information until a matching route : static or dynamic : learned via an IGP (Interior Routing Protocol like OSPF, that uses the default routing table (vrf0 or GRT, Global routing table), exists in the default routing table.

Why is this helpful? to get control of the effective forwarding of packets based on the routing information received by BGP, for example, to prevent loops or blackholes: we make sure that routing information received by BGP is resolvable using the routing information in the local (default) routing and forwarding router tables to the next destination that is directly connected or multihop from the source…

Deep in… and network setup

Let’s deep into it and ask ourselves, what does it mean a “matching route” in this statement? Same prefix? Next-hop? Etc. What do you mean exactly by “does not use that information”? In global routing table? Advertising the route (information) to peers?

Let’s work on the setup, shown in fig. 1. We run this IOS version: 7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.3(3)XB12, RELEASE SOFTWARE (fc2). Our test network is a 3 domains BGP network (100, 200 and 500) : R2 belongs to AS 200; R5 to AS 500; R1 and R4 to AS 100. R1 and R2 are E-BGP neighbors (belonging to different (by IDes) ASes or autonomous systems), same for R4 and R5. R1 and R4 have established two I-BGP sessions over two logical links: one passing by tunnel0, and the other on the directly connected interface.

In this network, we check that:

First case using static routes…

In this section, we try to fix this synchronisation issue by configuring a static route.

Static routes by default have an administrative distance of 1. By changing the administrative distance to any greater value than 200 (iBGP admin distance), we get:

In the opposite direction, we would expect that any synchronized route is deleted from RIB as soon as it is marked as “not synchronized” in Loc-RIB. In our example, we tried to change the static route administrative distance. Rt1 paths are marked as “not synchronized” in Loc-RIB and best path is not advertised to R5. But why BGP routes are still present in RIB? the global routing table? Please note that the age timer is frozen to 00:00:00!

RIPv2…

Instead of using static routes, we advertise route Rt1 in RIP.

Changing the administrative distance of RIP routes in R4 is more coherent (makes sense) than the precedent case (using static route), in fact:

• Router R4 would prefer RIP-synchronized BGP routes if they have a better administrative distance;
• but deleting RIP route would cause BGP routes to get non synchronized in Loc-RIB;
• what is beautiful is that the corresponding paths get deleted also from RIB… forever!

let’s check with an OSPF route

In a normal situation, how a routing information bloc, included in the description of an OSPF route installed in RIB, would differ from the corresponding route information in Loc-RIB? a part from the prefix, subnet, mask, via interface, information, the router-id is shared between both RIB and Loc-RIB route descriptions but in the first case it corresponds the the advertising peer (R1) OSPF router-id and in the second case to the BGP router-id of the same router (R1)…

Let’s test the administrative distance…

We check that:

• similiarily to static route case, the BGP routes are not deleted from the routing table!
• the routes are not synchronized in Loc-RIB nor advertised to peers (R5).
• Using a different subnet mask prevents the route from getting synchronized, installed in RIB and advertised to peers.

what about EIGRP?

Testing administrative distance and subnet match results are the same as RIP but we observe in EIGRP topolgy that the corresponding route is marked as Active and the router is actively querying the neighbors for an alternative successor.

A debug on ip routing shows that:

• the process add the EIGRP route first,
• the route in the Loc-RIB get marked as synchronized,
• having a better administrative distance, BGP route is installed in RIB,
• the process deletes the EIGRP route and EIGRP put the corresponding route in topology into active state,
• but BGP detects that EIGRP route has disappeared and put Rt1 into a non synchronized state,
• BGP paths get deleted from the RIB,
• the loop starts again from the beginning…

This is not resource efficient…

Conclusion

BGP IGP synchronization concerns only I-BGP peerings.

A matching route from an IGP or static sources should have the same prefix and subnet as the BGP route. The nexthop does not match necessarily and might be any resolvable address (direct or intermediate address).

In the specific case of OSPF, the peer OSPF and BGP router-ids must match. Both router-ids are including in the routing information the peer sends.

In the description of the synchronization feature, the “…does not use that information…” refers to installing the BGP route in the default routing table and advertising it or not to the neighboring peers.

This statement is not consistent especially in the case of OSPF and static routing with higher than BGP administrative distances: the routes are not deleted from the routing table evenif they’re marked as “not synchronized” in Loc-RIB…

In EIGRP the statement is effective but not efficient due to the process loop it creates by adding and deleting the corresponding routes infinitely…