RIB and FIB – Understanding the terminology

      7 Comments on RIB and FIB – Understanding the terminology

I had a VERY interesting twitter conversation with Chris Jones (@IPv6Freely) about a post I did earlier that had been titled “OSPF – Becoming one with the RIB…”.  He noted that the term ‘OSPF RIB’ wasn’t really the best way to describe what I was talking about in my post.  Rather, it should really be referred to as the OSPF LSDB (Link State DataBase).  Here’s the important part of the conversation…


So let me start by explaining what I understood the RIB and the FIB to be (before this morning). 

My understanding was that each routing protocol would generate a list of routes that it deems to be valid and usable.  How it does this is what makes each and every routing protocol different.  OSPF uses the link state database, EIGRP uses it’s topology table, etc.   These routes ,that each separate routing protocol generates, would be stored in that routing protocols RIB and offered up to the router as possible ways to route packets.  It’s very likely that the router would get information from multiple RIBs in this case.  For instance, if you had EIGRP and OSPF, or OSPF and BGP running at the same time.  Both routing protocols would have their own RIBs which they would submit to the router to be part of the IP routing table.  It would then be the job of the router to decide which routes would be preferred.  The main way this is handled is through the administrative distance of the routing protocol.  The lower the admin distance, the better the route’s chance of being picked if there are matching prefixes from multiple routing sources. 

At that point, the router inserts the ‘winning’ routes from the each of the RIBs into the forwarding table of the router.  I referred to this as the FIB.  In my world, things looked like this…


The orange lines here represent both BGP and OSPF sending their best prefixes to the router to be inserted into the IP routing table.  The router compares admin distance of duplicate prefixes and then forwards the winning routes to the IP routing table. 

Here is where , I believe, I went wrong.  My assumption was to consider both the IP routing table as well as the CEF table as the ‘FIB’.  I’d use the term interchangeably in most scenarios but the bottom line was that I considered the FIB to be ‘best routes from all of the IP routing table’.  Note that I’m only referring to layer 3 data here (routes).  In reality, the FIB not only includes the layer 3 information for forwarding packets, but also the layer 2 data required to forward the frame. 

So after the twitter conversation with Chris, I did a little more research.  It appears that ,as Chris said, the FIB is really just the CEF table in terms of Cisco technology.  I believe now, that a more accurate portrayal of the RIB/FIB would look something like this…


This difference between the two diagrams is rather clear.  However, one could see how this can be over generalized in terms of Cisco IOS.  For instance, we really only get to look at the data structures for each routing protocol in Cisco IOS.  We can view the BGP table using the ‘show ip bgp’ command, or look at the OSPF link state database by using the ‘show ip ospf database’ command. 

I would argue in some cases that looking at the protocol data structures would give you a good idea of what you can expect to see in the routing table (RIB).  However, the routing table is not necessarily a full representation of all the prefixes a routing protocol has available to it since some might not win the admin distance battle.  Learning to read the protocol data structures is the best way to get a full representation of all of the routes a IP routing protocol has available to it. 

So now we know what the RIB is, what’s the true distinction between the RIB and FIB?  That’s easy, the FIB contains all of the information required to actually forward a packet.  That includes layer 3 and layer 2 information.  For instance, we can look at a CEF entry and see both…


The CEF FIB table knows that to get to the prefix it must go out of fa0/0.60 towards the IP address of  The adjacency for that interface shows the MAC address of the destination.  The next 12 characters are the destination of the source (the local router). 

So it appears that I was just over-generalizing the terminology.  There are separate routing protocol data structures that are used by the routing protocol to make the best path determination.  The best prefixes are fed into the IP routing table or RIB.  From there, the router builds the FIB with the information in needs to forward the packets including layer 2 and layer 3 information.  I have updated my OSPF post to include the more accurate title of ‘OSPF – Becoming one with the LSDB…’

I’d love to hear your feedback! 

7 thoughts on “RIB and FIB – Understanding the terminology

  1. wildsubnet

    Chris is definitely correct but don’t feel too bad. I’ve seen BGP Tables referred to as RIBs before in training materials. It is a common mistake.

    1. Jon Langemak Post author

      Yeah, I totally agree with Chris once I reviewed it in more detail. A quick Google makes it seem like Im not the only one that had the confusion.

  2. Josh

    I was part of this conversation on Twitter too, have to say after I thought about it, I agree with Chris too, but while the terminology might not have been correct, we both had the same like mindedness about what we were talking about.
    Leads me to believe this is probably a common “problem” in the industry. Also leads me to another question. If the majority of people refer to something as “X” but the official term is “Y” does it eventually just become “X?” An analogy would be the term Kleenex. Its TECHNICALLY a brand name, not the official name of the product type, however since everyone knows what you are talking about when you say it, does calling it “Kleenex” still mean you are doing it wrong?

    One could argue for both sides rather effectively I think.

    1. Jon Langemak Post author

      Hi Josh! Yeah, I’m with you. I recall years ago making up my mind that the OSPF database and the EIGRP topology table were the RIBs for those respective protocols. I’ve been using that terminology ever since and have not had a single person tell me otherwise. I talked with the other engineers at work about it. Some had the same opinion that I had initially did while others seemed to be leaning towards Chris’s point of view. I think a big part of the problem is how Cisco teaches RIB/FIB along with what you can actually see when you are in IOS.
      I guess now that I’ve fully digested the concept, Chris’s point makes even more sense. The point that drove it home for me was thinking more about the BGP RIB failure issue. A RIB failure is when BGP has a route that it would like to insert into the routing table but there is a better prefix (smaller admin distance) from another routing protocol that wins. On this topic, Chris’ point makes perfect sense. If BGP can’t insert a route from it’s table into the IP routing table (the RIB) then it’s a RIB failure.
      At this point, I think that Chris’s point is valid and makes the most sense (to me), but I probably won’t start correcting other engineers that refer to the OSPF LSDB as the RIB 🙂 (I’m glad Chris did though!)

    1. Giuseppe Amendolara

      totally agree with you!
      each routing protocol has its own RIB ! those are not “protocol data stuctures”.
      you can inspect the RIB of each routing protocol, with these commands:
      RIP: show ip rip database
      OSPF: show ip ospf rib detail
      EIGRP: show ip eigrp topology all-links
      BGP: show ip bgp
      ISIS: show isis database detail

      you can inspect the global routing table (this is obtained through the AD process, where multiple RIBs are compared together and only the best is selected and installed into the global routing table) with this command: show ip route (its called global because you can have multiple subset routing tables my means VRFs, indeed they are called specific routing tables)

      FIB: show ip cef x.x.x.x detail + show adjacency fax/x enca (and you discover the outgoing L2 header)

  3. Pingback: 1.1.b Identify Cisco Express forwarding concepts (part 2) | routing peer

Leave a Reply

Your email address will not be published. Required fields are marked *