What is a BGP RIB failure

Sometimes you'll see a weird route status (RIB-failure) in your BGP table, for example:

GW#show ip bgp ¦ include r>
r> 10.2.0.0/16 10.0.1.2 0 0 65001 i

A more thorough investigation of the BGP entry does not give you a lot of additional information:

GW#show ip bgp 10.2.0.0
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))
Flag: 0x820
  Advertised to update-groups:
        1 2
  65001
    10.0.1.2 from 10.0.1.2 (10.0.1.2)
      Origin IGP, metric 0, localpref 100, valid, external, best

The “mistery” is solved when you inspect the entry in the IP routing table:

GW#show ip route 10.2.0.0
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

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

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

26 comments:

  1. I have seen this before in some dual-homed sites where the customer also wanted the MPLS to backup his LAN to LAN traffic from within that site. We saw rib failures as well as the needs to tweak bgp weight on the CE routers in order to get the proper routing and failover scenarios the ways the customer wanted. However, the addition of rib failues definitely helped pinpointed the issues visually. W/o that feature one might need to dig deeper to find out what was going on.

    Thanks for the clarifications on this feature.

    ReplyDelete
  2. For the sake of completeness, Cisco IOS documentation lists two more cases when you might get a RIB failure:

    * the router is so low on memory that the BGP route cannot be inserted into the IP routing table (I am not sure you'd be able to execute the show commands in this scenario anyway :)

    * a VRF has exceeded the maximum-prefix limit and cannot accept additional imported VPNv4 routes.

    ReplyDelete
  3. Gud Info guys!!!

    Thanx

    YasH

    ReplyDelete
  4. I got this in one CCNP book lab.
    the failure happend as i used to install some additional floating routes to the redundant paths between two router (in a dual homed full mesh scenario).
    The routes were still reachable (using the statics) and the bgp routes were not installed, as you wrote in the post.

    Thanks for answering my question before i actually had it :D

    Luca

    ReplyDelete
  5. Thanks, cleared up that little query I had :-D

    ReplyDelete
  6. Thanks for the heads up. Wondering why RIB failure was showing up on a static redistribute into BGP.

    ReplyDelete
  7. thanks a lot
    even in the cisco online documentation this feature is not as smoothly explained

    ReplyDelete
  8. i have this problem and i increased the metric of static route and problem is removed.....

    ReplyDelete
  9. Ivan Pepelnjak09 July, 2010 21:29

    More precisely, you probably increased the administrative distance of the static route; you can’t change their metric.

    ReplyDelete
  10. William

    I work for sprint and got a scenerio where customer was running only BGP and static routing . had 2 default routes ..one he was getting from BGP [ which was running on serail interface ,connection to sprint mpls ] and other was static which was pointing towards his lan [ fa0/0]...In the RT the static default route was getting installed becoz of better AD and the default route in BGP table was showing with RIB failure. ..I was checking the BGP configs and found while configuring neighborship with sprint mpls weight was also defined [ 2 ] with the neighbor statement ..My question is why there was weight statement in BGP configs when there was only 1 BGP neighbor in that router ...IS there any significance for this ?????? O:-)

    ReplyDelete
  11. hi all

    I am from sprint .was working with vandana on the issue stated..i could see that the loopack was advertised to pe router via bgp ..but i logged into the connected pe router where i could see that the update was not advertised to any peer...does that mean that the update was not advertised further into the mpls clous to our managemnt servers..

    ReplyDelete
  12. Ivan Pepelnjak10 August, 2010 14:01

    Weight with a single BGP neighbor makes no sense. It might have been a leftover from previous config, cut-and-paste job or some weird belief.

    ReplyDelete
  13. Thanks a lot Ivan for clearing my doubt :)

    ReplyDelete
  14. Hi Ivan,

    I've strange behavior on RIB-Failure, BGP update is sent ONLY to EBGP peer. Is it correct behavior or just another IOS bugs?

    ReplyDelete
  15. Could be:

    (A) New default behavior (which IOS are you using?)
    (B) Yet another bug
    (C) unrelated IBGP issue (you sure it's not an IBGP route that would have to be reflected?)

    ReplyDelete
  16. Hi Ivan. Which behavior is compliant with the recent BGP related RFC(s): advertising or suppressing those routes what are not installed to the local RIB? Thanks.

    ReplyDelete
  17. has any one used sami module in cisco 7609 to implement vpn services

    ReplyDelete
  18. Brad lead me to here (http://bradhedlund.com/notes/bgp/) regarding the "bgp suppress-inactive" command. It is not as straight forward as documented in the Cisco DocCD. I have done some POC regarding it document it into a blog post. Thanks. 8-)
    http://www.itcertnotes.com/2011/02/suppressing-inactive-bgp-route.html

    ReplyDelete
  19. Good evening Mr Ivan, i am having the exact same issue in a simple topology that i configured BGP. After i redistribute OSPF into BGP then the eBGP peer has a rib-failure about the connected interface , and the iBGP peers have rib-failures about the networks they allready knew through OSPF. This is normal because the routing table for both iBGP anf eBGP has allready these routes with better AD. Pings are doing fine and everything looks correct. My question is the fact that the routes are marked as rib-failure is a problem ? should or should not try to eliminate this entry from the bgp table? thank you

    ReplyDelete
    Replies
    1. If you need to propagate the iBGP routes (that are also in OSPF) to eBGP peers, then they have to be in the BGP table; RIB failure is normal under those assumptions.

      Delete
    2. Thank you very much sir for your answer. Best regards.

      Delete
  20. i was messing around with GNS3 and could NOT get my routes suppressed with "bgp suppress-inactive". i tried it on some 4948s too, but got the same result.
    what have i done wrong?

    ReplyDelete
  21. I discovered the errors of my ways. just setting "bgp suppress-inactive" is not the answer - the next-hop needs to be different too. and no you can't trick it with recursive routing.

    ReplyDelete
    Replies
    1. "the next hop needs to be different" ... with a perfect hindsight (thank you!) it makes perfect sense. Without this check, BGP routes redistributed into OSPF would kick out those same BGP routes.

      Delete
  22. Hi Ivan, I came across a scenario in which the next hop entries for BGP and IGP (EIGRP) were different. Still, the RIB failed routes got advertised to Service Provider PE, even after introducing the command "bgp suppress-inactive". IOS version would be 15.2(3). This created a loop for our spoke site subnets behind CE routers.

    Does it mean that the cmd is not working as per expectation?

    ReplyDelete
    Replies
    1. Did you clear the BGP session? BGP updates are triggered by change in route info, and sometimes the programmers forget to trigger them after a configuration change.

      Delete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.