By definition, the BGP synchronization rule requires that when a BGP router receives information about a network from an I-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:
Route Rt1 (owned and advertised by R1) is learned in BGP Loc-RIB in R4 BGP routing table;
Route Rt1 is installed in RIB router default routing table in R4;
BGP synchronization is disabled on R4;
Route Rt1 is advertised by R4 to R5;
Route Rt5 is installed in R4.
We enable synchronization (causes an automatic reset of peerings) and check that route Rt1 is marked as “not synchronized” in Loc-RIB, not installed in RIB and consequently, not advertised to R5.
Route Rt5 that is learnt on E-BGP peering to R5, is not impacted by the change… we confirm that this synchronisation rule does apply only to I-BGP neighborships with big I.
First case using static routes…
In this section, we try to fix this synchronisation issue by configuring a static route.
We get route Rt1 synchronized by configuring a static route with an exact match of the destination (same subnet mask) and any valid nexthop or resolvable intermediate address to a valid nexthop.
Changing the number of intermediate addresses does not affect the result.
We get a “RIB-failure(17) – next-hop mismatch” information.
Using a different subnet mask is not working…
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:
BUT, two BGP routes are still installed in the routing table!
Rt1 paths marked as “not synchronized” in Loc-RIB;
Rt1 is not advertised to R5 from R4;
As a conclusion, onfiguring synchronization allows BGP to track the presence of a matching IGP route in RIB. If it is not the case, the route is marked as not synchronized. Because it is not synchronized, any valid route could not be installed in RIB nor advertised to any neighbor.
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)…
We’ve got a chance to have both router-id the same. The next figure shows that Rt1 is synchronized
In case R1 BGP router-id is different from R1 OSPF router-id, Rt1 gets not synchronized in R4.
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…
