FIB vs. RIB for CCNP ENCOR: How Cisco Actually Decides, Programs, and Forwards Traffic

1. Why FIB vs. RIB Matters

For CCNP 350-401 ENCOR, this topic’s a lot more than just memorizing a couple of definitions. Honestly, that’s the difference between what the router believes is true and what it’s actually doing with live packets on the wire. In Cisco terms, the RIB is the IP routing table used by the control plane, the FIB is the forwarding table used by Cisco Express Forwarding (CEF), and the adjacency table provides the Layer 2 rewrite or special forwarding disposition needed to send the packet.

The practical lesson is simple: a route in the RIB does not automatically guarantee successful forwarding. Forwarding also depends on recursive next-hop resolution, adjacency health, policy features, the correct VRF, and — on a lot of platforms — whether the hardware forwarding resources got programmed properly. That is why show ip route alone is never the full story.

2. How the Control Plane and Data Plane Work Together

The control plane picks up routes from a few different places — connected interfaces, static routes, and routing protocols like OSPF, EIGRP, IS-IS, and BGP. And each protocol has its own separate database too — OSPF has the LSDB, EIGRP keeps a topology table, and BGP maintains its own BGP table. Those are not the same as the IP RIB. The IP RIB is where selected route candidates are installed for a given routing context such as the global table or a VRF.

The data plane forwards packets using precomputed forwarding information. On Cisco devices, that usually means CEF using the FIB plus adjacency information. Some platforms forward mainly in hardware through ASICs, TCAM, NPUs, or forwarding engines. Others, especially branch-oriented platforms, may rely more on software CEF or platform-specific acceleration. ENCOR does not require platform internals at ASIC design level, but you should understand that the logical FIB and the hardware-programmed forwarding table are related yet not always identical during convergence or failure conditions.

A more accurate route-installation pipeline looks like this:

1. A route is learned in a source or protocol database.
2. The source protocol selects an eligible or best path according to its own rules.
3. The next hop is recursively resolved if needed.
4. The IP RIB installs the selected route or routes if they are usable; equal-cost paths may also be installed where supported.
5. CEF builds or updates the FIB.
6. The adjacency table provides resolved rewrite information or a special disposition such as glean, punt, receive, or drop.
7. The platform programs hardware forwarding state where applicable.

That sequence explains why a prefix can look healthy in one table but still fail operationally farther down the chain.

3. What the RIB Really Does

The Routing Information Base is a control-plane structure that stores the route or routes selected for installation. It is not always a single path only. With ECMP, the RIB may contain multiple equal-cost installed paths for the same prefix. It is also VRF-aware, so the global table and each VRF maintain separate routing information.

Route selection is not a single universal “AD then metric” formula across all cases. Protocols first determine their own best or eligible paths. Then the IP RIB compares competing candidates from different sources using administrative distance and other install rules. Within one protocol, the metric and protocol-specific logic matter. During forwarding, longest prefix match is a separate concept applied against the forwarding table, not the route-source selection process.

Two exam points matter here:

• Protocol database does not equal IP RIB.
• Route learned does not equal route installed.

A floating static route is a good reminder. If you set up a backup static route with a higher administrative distance, it’ll be sitting in the config just fine, but it won’t make it into the RIB unless the better route disappears:

ip route 10.10.10.0 255.255.255.0 192.0.2.1 200

The syntax is perfectly valid, sure, but the route only becomes useful if the next hop can actually be reached and there isn’t a better, lower-distance route already winning.

4. What the FIB, CEF, and Adjacency Table Do

The FIB is the forwarding structure CEF uses for destination lookup. Conceptually, it contains prefixes plus forwarding-ready information derived from the RIB and recursive resolution. On real platforms, a FIB entry may point to next-hop objects, adjacency chains, labels, tunnel information, or hardware-specific rewrite structures rather than just a flat “prefix, next hop, interface” tuple. For ENCOR, the safe mental model is that the FIB is an optimized forwarding map built from the routing decision.

The adjacency table is equally important. It provides the information needed to actually transmit the packet, including MAC rewrite information for IPv4 ARP, IPv6 Neighbor Discovery, or special CEF behaviors. Common adjacency concepts include:

• Resolved adjacency: normal forwarding can occur.
• Incomplete adjacency: next-hop rewrite is not yet known.
• Glean adjacency: the router knows the destination is directly connected but must resolve the host first.
• Punt adjacency: traffic is sent to the CPU for exception handling.
• Receive adjacency: the packet is destined to the router itself.
• Drop/discard adjacency: traffic is intentionally dropped.

Null0 fits here carefully: it is not simply “an adjacency type” in every implementation. Rather, a route to Null0 results in discard forwarding behavior. That distinction is small but technically important.

The operational takeaway is this: without a resolved adjacency, you do not have normal line-rate forwarding for that path. Some traffic may still be punted or handled as an exception, but that is not the same thing as healthy CEF forwarding.

5. RIB vs. FIB: Side-by-Side

6. Recursive Lookup, Longest Prefix Match, and the BGP Story

Recursive lookup happens when a route points to a next hop that is not directly connected. The device must resolve that next hop through another route before installing usable forwarding state. This matters constantly with BGP.

The accurate BGP story is:

• When a prefix shows up through BGP, it lands in the BGP table first.
• Then BGP applies its own best-path logic and picks the winner.
• After that, the best path’s next hop still has to be reachable through the IP routing table.
• If that next hop resolves cleanly, the route can be installed in the IP RIB and then turned into a usable FIB entry.
• If the next hop goes missing, the route can still sit in the BGP table, but it usually won’t get installed into the IP RIB or the FIB.

Here’s a simple example that shows the whole chain working the way it should:

show ip bgp 203.0.113.0
*> 203.0.113.0/24 10.1.1.1 0 65002 i

show ip route 10.1.1.1
O 10.1.1.1/32 [110/20] via 192.0.2.1, Gi0/0

show ip route 203.0.113.0
B 203.0.113.0/24 [20/0] via 10.1.1.1, Gi0/0

If the OSPF route to 10.1.1.1 disappears, the BGP entry may still exist in show ip bgp, but the prefix is typically no longer installed in the IP RIB. That is a classic exam trap.

Longest prefix match comes into play later, right when the device is making the actual forwarding decision. If the FIB has both 10.10.0.0/16 and 10.10.10.0/24, traffic to 10.10.10.5 is going to hit the /24 every single time — no argument, no guessing. That is forwarding logic, not route-source preference.

7. IPv4, IPv6, and VRF Details That Catch People Off Guard

The RIB/FIB model is basically the same for IPv4 and IPv6, but the neighbor-resolution part works a little differently. IPv4 uses ARP. IPv6 uses Neighbor Discovery. With IPv6, link-local next hops in the routing table are totally normal, but forwarding still depends on valid ND resolution and a working outgoing interface.

The commands you’ll actually want to check are:

show ipv6 route
show ipv6 cef
show ipv6 neighbors

With VRFs, keep in mind that routing and forwarding are handled per VRF, not in one big global table. If you check the wrong context, it’s really easy to reach the wrong conclusion fast:

show ip route vrf BLUE 10.10.10.0
show ip cef vrf BLUE 10.10.10.0/24
show ip arp vrf BLUE

One of the most common operational mistakes I’ve seen is proving the route in the global table while the traffic is actually living inside a VRF.

8. Why a Route in the RIB Can Still Fail to Forward

The highest-value failure cases are these:

• Recursive resolution failure: common with BGP or statics pointing to remote next hops.
• Adjacency failure: ARP or ND is incomplete, stale, or broken by a Layer 2 issue.
• Policy override: PBR, NAT, tunnel forwarding, ACLs, QoS, or security features change what happens after the route lookup.
• Hardware programming issue: the logical forwarding state exists, but the platform has not successfully programmed the hardware path yet.
• Intentional discard behavior: summary-to-Null0, default-route fallback, or other discard logic causes a black hole by design.

A classic summarization example is a route to Null0 used to prevent loops:

ip route 10.10.0.0 255.255.0.0 Null0

If a more specific route like 10.10.20.0/24 disappears, traffic can fall back to the /16 summary and get dropped. From the router’s point of view, that forwarding result is correct — even if users absolutely hate it.

9. The Verification Commands That Really Matter

Hardware verification is platform-specific. On Catalyst 9000, hardware forwarding inspection commands can verify whether entries are programmed into the forwarding engine. On ISR and ASR platforms using QFP-style forwarding, platform hardware commands can help confirm whether the packet path is correctly installed. On NX-OS, forwarding verification uses a different command structure. ENCOR expects you to understand the concept, even if the exact command syntax changes from platform to platform.

10. A Practical Troubleshooting Playbook

When traffic fails, use a strict order:

1. Confirm the VRF and destination. Wrong context means wrong answer.
2. Check the RIB. Is the route installed? Is it the expected route?
3. Check recursive reachability. Can the next hop itself be reached through the routing table?
4. Check the FIB. Does CEF have a usable forwarding entry?
5. Check ARP or ND. Is the adjacency resolved?
6. Check the interface and Layer 2 path. VLAN, trunk, encapsulation, and line protocol issues often explain incomplete adjacency.
7. Check policy exceptions. PBR, NAT, tunnels, ACLs, uRPF, or security features may alter the path.
8. Check hardware programming if the platform supports it.

That command order is useful both on the exam and in production because it prevents you from staring at one healthy output while the failure lives somewhere else.

11. Scenario Snapshots

Scenario 1: Route present, traffic dead. show ip route looks fine. show ip cef shows the prefix, but show ip arp or show adjacency detail shows incomplete resolution. Most of the time, the culprit is an ARP problem, a VLAN mismatch, or some break somewhere in the Layer 2 path.

Scenario 2: BGP prefix visible but unreachable. show ip bgp contains the route, but the BGP next hop is no longer reachable in the IP routing table. So the route never gets installed into the IP RIB or the FIB.

Scenario 3: Correct route, unexpected path. ECMP exists and CEF hashes flows across multiple next hops. Modern platforms typically use per-destination or per-flow hashing by default. Per-packet load sharing is uncommon and generally avoided because it can reorder packets.

Scenario 4: Software view healthy, hardware path not. The route and CEF entry look correct, but platform-specific hardware commands show the entry is not programmed or resources are exhausted. On hardware-based platforms, route scale, ACL and QoS consumption, and forwarding resource limits can matter.

12. Security, Scale, and Policy Awareness

Forwarding health is also a security topic. ARP spoofing or ND abuse can corrupt adjacency resolution. Control-plane overload during route churn can affect stability, which is why CoPP or CPPr matters. Features like uRPF, ACLs, QoS classification, NAT, PBR, tunnel encapsulation, and first-hop redundancy can all affect what really happens to a packet after the initial route lookup.

And don’t forget: the logical FIB isn’t necessarily the same thing as the hardware forwarding table. On Catalyst platforms, TCAM and ASIC resources matter. On ISR and ASR families, forwarding resource behavior may matter more than TCAM exhaustion specifically. Do not assume every Cisco platform fails the same way.

13. ENCOR Exam Traps and Rapid Review

Must memorize:

• RIB = installed routing information in the control plane
• FIB = forwarding table used by CEF
• Adjacency = rewrite or forwarding disposition information
• Longest prefix match = forwarding lookup rule
• Administrative distance and metric = route selection concepts, not forwarding lookup

Must understand:

• Protocol database is not the same as the IP RIB
• Route learned is not the same as route installed
• Route installed is not the same as packet successfully forwarded
• BGP table presence does not guarantee IP RIB installation
• RIB presence does not guarantee resolved adjacency
• VRF, PBR, and hardware programming can all change the outcome

Typical exam-style question: A prefix appears in show ip route, but traffic fails. What do you check next? Usually the best answer is a forwarding or adjacency verification command such as show ip cef, show adjacency, show ip arp, or the IPv6 equivalent, not another routing-protocol command.

14. Conclusion

The clean model is still the right one: the control plane learns and selects routes, the RIB stores installed route information, CEF builds the FIB, the adjacency table provides rewrite details, and the data plane forwards packets. But for ENCOR — and for real-world troubleshooting — you’ve also got to keep the nuance in mind: recursion has to succeed, adjacency has to resolve, policy can override the path, the VRF has to be correct, and on many platforms the hardware programming has to complete too.

If you remember one line, make it this: RIB chooses, FIB forwards, and adjacency plus platform state determine whether forwarding really works.