I-BGP synchronization with IGP

The BGP synchronization rule requires that when a BGP router receives information about a network from an IBGP neighbor, it does not use that information until a matching route is learned via an IGP or static route.

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?

fig. 1. Network setup

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).

In this network, we check that:

  • Rt1 is learned in BGP Loc-RIB;
  • Rt1 is installed in RIB router default routing table;
  • BGP synchronization is disabled on R4;
  • Rt1 is advertised by R4 to R5;
  • Rt5 is installed in R4.

We enable synchronization (automatic reset of peerings) and check that Rt1 is marked as “not synchronized” in Loc-RIB, not installed in RIB and not advertised to R5. Rt5 that is learnt on E-BGP peering to R5, is not impacted by the change…

Static routes…

We get Rt1 synchronized by configuring a static route to 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 does not work…

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:

  • Rt1 paths marked as “not synchronized” in Loc-RIB;
  • Rt1 is not advertised to R5 from R4;
  • BUT, two BGP routes are still installed in the routing table!

Configuring 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 the present case, we 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 the age timer that is stack at 00:00:00!

RIPv2…

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

Changing the administrative distance of RIP routes R4 is more coherent than the precedent case.

In fact:

  • R4 would prefer synchronized BGP routes of the RIP ones as 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…
  • for ever!

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…

atlink'admin

Learn More →

Leave a Reply

Translate »