Sometimes you'll see a weird route status (RIB-failure) in your BGP table, for example:
GW#show ip bgp ¦ include r>A more thorough investigation of the BGP entry does not give you a lot of additional information:
r> 10.2.0.0/16 10.0.1.2 0 0 65001 i
GW#show ip bgp 10.2.0.0The “mistery” is solved when you inspect the entry in the IP routing table:
BGP routing table entry for 10.2.0.0/16, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Advertised to update-groups:
10.0.1.2 from 10.0.1.2 (10.0.1.2)
Origin IGP, metric 0, localpref 100, valid, external, best
GW#show ip route 10.2.0.0The GW router has a static route that collides with the EBGP route and thus the BGP route cannot be inserted in the IP routing table (as the static route has administrative distance 1).
Routing entry for 10.2.0.0/16
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 0, traffic share count is 1
Let's conclude with a few interesting facts about the RIB failures:
- The RIB failure feature was introduced in IOS release 12.2T; prior to that, the BGP routes with higher administrative distance than other route sources were silently ignored (similar to all other routing protocols).
- You can display BGP routes that are not inserted in the IP routing table with the show ip bgp rib-failure command, which also explains why the BGP route was not inserted in the IP routing table.
- The BGP routes that are not used due to higher administrative distance are still advertised to all BGP peers (contrary to what most other distance-vector routing protocols do), unless you configure bgp suppress-inactive (introducted in 12.2T and 12.0(26)S).