BGP RIB-failure

So, you’re following along in a lab configuring BGP and your “show ip bgp” reveals a RIB-failure…

Topology

R1 and R2 have an established BGP peering in AS 100; for now, let’s focus on R1 and R3. I’ve done the following configs on the two routers (notice that I’m using a local loopback on each router as an update-source):

R1:

R2:

In order to use the loopback of the neighboring router in the neighbor statements, and since the the loopbacks are not connected by a common subnet (physical connection – just logical), R1 needs a route to R3’s loopback and vice-versa. For this I chose to use static routes (and here you may start to see the problem):

R1:

R2:

As of right now, neither R1 nor R3 are advertising any routes (the BGP tables are empty). But, since we have static routes, R1’s Lo1 can ping R3’s Lo3 and vice-versa:

R1:

R3:

Now I want to advertise R1’s and R3’s loopback via bgp:

R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# router bgp 100
R1(config-router)# network 1.1.1.1 mask 255.255.255.255
R1(config-router)# end
R1#

R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# router bgp 200
R3(config-router)# network 3.3.3.3 mask 255.255.255.255
R3(config-router)# end
R3#

Now, let’s see that rib-failure:

R1:

R3:

On R1 & R3, the reason for the failure is due to administrative distance. Let’s look at the RIB for R1:

(R3 picture omitted since the issue is the same)

The issue is there is another entry for the 3.3.3.3 route with a lower administrative distance – the static route we configured earlier. The static route has a lower AD (1) than the BGP route (20) and so the static route is selected over the BGP route to be placed in the RIB.

The RIB-failure (show ip bgp) is because BGP is complaining that its route for 3.3.3.3 isn’t being selected as the entry in the RIB (the routing table). BGP lost the election to a static route and it’s letting you know that though the route is in the BGP Table, it’s not being used in the RIB.

Let’s do one more thing; let’s advertise another route in BGP from R3, the 33.33.33.33/32 network (which I’ve configured on R3 Lo33) and then look at R1’s BGP table and then the routing table just to see if we get a RIB-failure with that route...

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#router bgp 200
R3(config-router)#network 33.33.33.33 mask 255.255.255.255
R3(config-router)#end
R3#

And there it is, the route is valid, best and shows up in the RIB as a BGP route; no RIB-failures for the 33.33.33.33./32 network. Now this example is just one common cause in a lab environment (that I know of) so I’m sure there could be other reasons why a RIB-failure might ‘cry out’.

-Cheers!