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!
