RIB vs FIB: Routing Table vs Forwarding Table
Every router maintains two distinct routing databases that serve completely different purposes. The Routing Information Base (RIB) is the control plane's view of the network — a complete record of every route learned from every protocol, before any selection or hardware programming has occurred. The Forwarding Information Base (FIB) is what actually forwards packets, a stripped-down, hardware-optimized structure containing only the single winning next-hop for each destination. Confusing the two leads to mistakes in operations, troubleshooting, and capacity planning.
The Control Plane and Data Plane
Network devices separate their work into two planes. The control plane runs routing protocols, exchanges reachability information with neighbors, computes best paths, and manages the router's understanding of network topology. The data plane (or forwarding plane) receives packets on interfaces and switches them toward the correct next-hop at line rate. These planes often run on different hardware: control plane processing happens on the router's CPU or a dedicated route processor; data plane forwarding happens in ASICs and TCAM.
The RIB lives in the control plane. The FIB lives in the data plane. The route selection process bridges them: the control plane selects the best route from the RIB and installs it into the FIB. This installation is sometimes called RIB-to-FIB download or route programming.
The RIB: A Multi-Protocol Database
The RIB aggregates routes from every source the router knows about. For a typical internet router, this includes:
- BGP — hundreds of thousands to over a million prefixes from eBGP peers and iBGP peers
- OSPF — internal network topology, link-state derived routes
- IS-IS — alternative IGP, common in service provider networks
- Static routes — manually configured entries, including default routes
- Connected routes — directly attached subnets, automatically derived from interface configuration
- Locally originated routes — addresses configured on the router's own interfaces
For any given prefix, the RIB may contain multiple entries from different protocols. OSPF might know about 10.1.0.0/24 via two paths. eBGP might have 200.10.0.0/16 from three different peers. Static configuration might add a default route. All of these coexist in the RIB simultaneously. This is the raw, unfiltered view of routing knowledge.
On Cisco IOS, show ip route shows the RIB (with the winning route per prefix marked). On Juniper, show route shows the routing table; show route table inet.0 shows the RIB for the IPv4 unicast table. The BGP-specific portion of the RIB — all routes learned via BGP before best-path selection — is sometimes called the BGP Loc-RIB or the BGP table, and is accessible via show ip bgp on Cisco or show route protocol bgp on Juniper.
Administrative Distance: Resolving Cross-Protocol Conflicts
When two protocols both have a route for the same prefix, the router must decide which one wins. This is where administrative distance (AD) — also called routing protocol preference — comes in. AD is a simple numeric trustworthiness ranking: lower is better. Typical Cisco IOS values:
| Source | AD |
|---|---|
| Connected interface | 0 |
| Static route | 1 |
| eBGP | 20 |
| OSPF | 110 |
| IS-IS | 115 |
| iBGP | 200 |
If OSPF and iBGP both offer a route to 192.0.2.0/24, the OSPF route wins (AD 110 vs 200) and the iBGP route sits in the RIB as a candidate but does not get installed into the FIB. This is why iBGP routes are often not seen in the FIB on routers where an IGP also covers the same prefix. If the OSPF route disappears, the iBGP route promotes itself — the RIB retains it as a backup.
Within a single protocol, a separate best-path algorithm applies. BGP's best-path selection is a multi-attribute process described in RFC 4271's decision process: weight, local preference, origin type, AS path length, MED, eBGP vs iBGP, IGP metric to next-hop, and router-ID tiebreaking. The BGP RIB holds all candidate routes; only the winner gets proposed to the main RIB for AD comparison, and only the AD winner gets installed in the FIB.
The FIB: Hardware-Optimized Forwarding
Once the control plane selects a best route, it programs the FIB. In software-based routers and low-end devices, the FIB is a kernel data structure — on Linux, it is the kernel routing table visible via ip route show or ip route show table all. On hardware routers, the FIB is programmed into TCAM (Ternary Content-Addressable Memory).
TCAM is a specialized memory architecture that can match a packet's destination IP address against all FIB entries simultaneously in a single clock cycle. Regular RAM requires sequential comparisons (O(n) in theory, O(log n) with tree structures). TCAM performs a massively parallel lookup — every entry is compared at once — making it O(1) regardless of table size. This is why hardware routers can forward packets at hundreds of gigabits per second while the lookup itself takes nanoseconds.
The FIB contains, for each prefix, the resolved next-hop: the outgoing interface and the Layer-2 address (MAC address for Ethernet) to use when forwarding. This is important — the FIB does not store a next-hop IP address alone; it stores the full resolution of that IP address to a physical interface and MAC.
Recursive Next-Hop Resolution
BGP routes typically carry a next-hop IP address that is not directly connected to the router. For example, a route learned via eBGP might have next-hop 203.0.113.1, which is on the peer's interface. The router must recursively look up 203.0.113.1 in the RIB to find how to actually reach it — this is called recursive next-hop resolution.
If the IGP route to the eBGP next-hop disappears, the FIB entry for that BGP prefix is withdrawn even though the BGP RIB still holds the route. The prefix becomes unreachable until the IGP route is restored. This is why next-hop reachability is a prerequisite for BGP route installation, and why iBGP next-hop tracking is operationally important.
What a Looking Glass Shows
A BGP looking glass queries the BGP RIB on route collector or router nodes, not the FIB. This is an important distinction. The RIB shows:
- All received BGP prefixes, including those not selected as best path
- The full set of BGP attributes: AS path, communities, MED, local preference
- Multiple paths to the same prefix from different peers
The FIB contains only the best-path winner and its fully resolved next-hop. A prefix visible in the RIB may not be in the FIB if it lost best-path selection, if its next-hop is unresolvable, or if FIB capacity has been exceeded. This difference matters when diagnosing reachability: a prefix present in the BGP RIB but absent from the FIB will not forward packets.
FIB Capacity Exhaustion: The 512K Problem
TCAM is expensive in terms of power, die area, and cost. Router vendors allocate a fixed TCAM capacity at design time — a capacity that must serve the device for years after deployment. When the global internet routing table grows beyond that capacity, older routers fail in dramatic ways.
In August 2014, the internet's BGP table crossed approximately 512,000 routes. Routers using Cisco's 6500 series with certain supervisor modules hit their TCAM limits. Some stopped forwarding traffic entirely; others began punting packets to the CPU. Punting means the data plane cannot resolve the destination in TCAM, so it sends the packet to the slow-path CPU for a software FIB lookup. The CPU can handle perhaps 10,000–100,000 packets per second; at full line rate, hardware ASICs handle billions. The result was severe packet loss and latency spikes for networks depending on those routers.
When the FIB is full, the router must make a difficult choice: which routes to install in hardware? Common strategies include installing only more-specific routes (longer prefixes, which are more likely to be actually used), installing only routes covering the most traffic, or using a combination of default routes and selective specifics. Many modern routers separate IPv4 and IPv6 TCAM partitions and have configurable allocation between them.
ECMP and Multiple Next-Hops in the FIB
The FIB can hold multiple equal-cost next-hops for a single prefix, supporting Equal-Cost Multi-Path (ECMP) forwarding. When BGP selects multiple paths (with the maximum-paths configuration) or OSPF finds two equal-cost paths, all are installed in the FIB. Hardware ASICs use a hash of the packet's flow (source IP, destination IP, ports, protocol) to deterministically assign each flow to one of the available next-hops. This distributes load across multiple links without reordering packets within a flow.
The RIB holds all candidate routes; the FIB holds the programmed set. ECMP is one case where the FIB can contain multiple entries per prefix — but only the equal-cost winners from the RIB selection process, not all candidates.
Linux: RIB and FIB in Software
On Linux, the distinction between RIB and FIB is visible but less sharply drawn than on hardware routers. The kernel routing table (ip route show or ip route show table all) is effectively the FIB — the actively used forwarding data. Tools like FRR (Free Range Routing) and BIRD maintain their own RIBs in userspace, selecting best paths and installing them into the kernel via Netlink. The BGP RIB in FRR is accessible via vtysh; it contains all received BGP updates and the full path selection output, while the kernel sees only the installed winner.
Linux also supports multiple routing tables (via ip rule and policy routing), which complicates the RIB/FIB analogy — there is effectively one FIB per table. The main table (table 254) is the default. Separate tables are used for source-address-based routing, VPN separation, and other policy scenarios. Each table has its own entries populated independently.
For a looking-glass perspective: route collector software like OpenBGPd, GoBGP, or BIRD acting as a route reflector receives full BGP feeds and stores them in a RIB, making all paths visible. This is exactly what BGP looking glasses query — the full multi-path RIB, not the single-winner FIB that actually forwards traffic on any production router.
RIB Size and the Global Routing Table
The global IPv4 BGP RIB passed one million prefixes in 2022. This milestone matters for hardware capacity planning — routers deployed years before had TCAM sized for fewer entries. The IPv6 RIB is smaller in prefix count but growing rapidly, currently around 200,000 to 250,000 prefixes depending on the vantage point and de-aggregation practices of the networks being observed.
The difference between the number of routes a router receives into its BGP RIB versus what it installs in the FIB can be large. A router connected to a full-table eBGP peer might receive 900,000+ prefixes but, due to best-path selection and TCAM constraints, may install a smaller set. Operators use techniques like default route injection (installing a catch-all 0.0.0.0/0 pointing at a full-table peer, reducing the TCAM requirement to only the most-specific routes needed for local policy) to manage FIB capacity on memory-constrained devices. This is sometimes called "partial table" or "default plus selected specifics" — a common configuration at smaller ISPs and enterprises.
Troubleshooting with RIB/FIB Awareness
Many network troubleshooting failures stem from not distinguishing RIB from FIB. A common scenario: an operator sees a route in show ip bgp (BGP RIB) but traffic is not flowing. The route may have lost best-path selection to a different source, the next-hop may be unresolvable, or the route may have been rejected from the FIB due to a policy. The diagnostic sequence is:
- Check the BGP RIB:
show ip bgp X.X.X.X/N— is the prefix present? Is the desired path marked as best (>)? - Check the main RIB:
show ip route X.X.X.X— is the BGP route winning against other sources (check AD)? - Check the FIB:
show ip cef X.X.X.X— is the prefix in CEF (Cisco's FIB implementation)? What next-hop is programmed? - Check next-hop reachability:
show ip route NEXT-HOP-IP— can the router reach the BGP next-hop via its IGP?
Working through these four steps in order isolates whether the problem is BGP policy, route selection, FIB programming, or next-hop resolution. Skipping directly to step 4 (pinging the next-hop) without checking the earlier steps often leads to incorrect conclusions. The RIB and FIB are separate databases; a problem in either produces different symptoms.
Another common confusion: a route visible in the RIB but marked with * (valid) rather than > (best) is not installed in the FIB. On Junos, inactive routes appear in the routing table with [BGP/170] or similar but without the * active marker. On IOS, non-best paths in the BGP table are listed without the > prefix. In both cases, the route exists for policy analysis and backup purposes but has no effect on forwarding until it becomes best-path. Looking glasses that show the full BGP RIB (not just best paths) may display routes that no production router is currently using to forward traffic.
The route reflector topology adds another dimension: a route reflector stores and propagates BGP paths but may itself forward no customer traffic. Its RIB is a superset of what any individual edge router's RIB contains, because the reflector sees all paths from all clients. This makes route reflectors valuable for looking-glass purposes — they have visibility into the full BGP diversity of the network — but care must be taken not to assume the reflector's view of best paths matches what edge routers actually install in their FIBs, since each edge router runs its own best-path selection with local preferences and policies.
Summary: Key Distinctions
To consolidate the key differences before moving on: the RIB is the complete routing knowledge base — all sources, all candidates, full attributes, used for policy, debugging, and backup. The FIB is the minimized, hardware-programmed forwarding table — one winner per prefix, fully resolved next-hops, optimized for lookup speed at line rate. A route can be in the RIB but not the FIB. A healthy network has the two in sync; divergence between them (due to TCAM exhaustion, next-hop failures, or software bugs) causes forwarding anomalies that appear as mysterious blackholes or asymmetric reachability.
Explore It Live
The looking glass on this site queries BGP RIB data from route collectors. Look up any prefix to see the full set of BGP paths — the data plane FIB on any given router will contain only one of them: