WB1 7.12 iBGP Synchronization

Per Cisco’s BGP Bestpath Selection, “if BGP synchronization is enabled, there must be a match for the prefix in the IP routing table in order for an internal BGP (iBGP) path to be considered a valid path.” In other words, for every iBGP route learned, there must be a matching IGP route already before the BGP route can be used. This rule was designed to prevent traffic black holes in legacy network designs where not all devices in the BGP transit path actually ran BGP.

With synchronization enabled, the assumption was that all routers in a transit network already ran IGP. If these devices had IGP routes to all BGP destinations, then it was safe to assume that traffic coming from other BGP ASes would not be black holed, even if some of the internal routers were not running BGP. To implement this design it was also assumed that some sort of BGP to
IGP redistribution would occur. The problem with this model however, is that IGP simply cannot scale to the size of the current Internet BGP table. Instead, current best practices dictate that if a
network is used for Internet transit, the routing table should be default free (i.e. no 0.0.0.0/0 routes), and all devices should run BGP. Another common design is that other tunneling mechanisms can be used, such as MPLS, to limit the amount of devices that BGP needs to be run on.

BGP synchronization is disabled by default as of IOS 12.2(8)T, and is rarely, if ever, needed in a real implementation anymore. However it is still important to understand the problem that synchronization was designed to prevent, and what the different resolutions for this problem are.

Once BGP is redistributed into IGP, the synchronization rule is met, and the routes are installed as best paths, but the “r” in the status code denotes that RIBfailure now occurs.

Per the above output on R1 222.22.2.0 is now “synchronized”, because there is a matching IGP route in the routing table. This means that the route can be used for Bestpath selection, and can be advertised to other BGP neighbors.
The RIB-failure output is an informational message to let us know that although the BGP route is valid, it is not being installed in the routing table. This usually occurs when there is an identical match to a BGP route via an IGP route with a lower administrative distance. In the below output we can see that the external EIGRP route with a distance of 170 prevents the iBGP route from being installed, which would normally have a distance of 200.

RIB-failure by itself is not necessarily bad, but there are certain cases where this disconnect between the BGP table and the routing table can cause traffic loops. By default BGP routes that have RIB-failure can be advertised to other neighbors, since the command no bgp suppress-inactive is the default option under the routing process. To stop RIB-failure routes from being advertised, issue the bgp suppress-inactive command under the process.