Route in Routing Table But Traffic Not Using It — CEF Issue
Presenting Symptom
A route for a destination network exists in the routing table, but traffic to that network is not being forwarded using that route.
Network Context
A small branch office with a Cisco 4321 ISR running IOS XE 16.9 connects to an ISP via a GigabitEthernet WAN link. The router has a static default route pointing to the ISP next-hop, and also learns a more specific route via OSPF from a remote site. The routing table shows both routes, but traffic to the remote site is not using the OSPF route.
Diagnostic Steps
Check the routing table for the destination
show ip route <destination-network>Routing entry for 10.10.10.0/24
Known via "ospf 1", distance 110, metric 20, type inter area
Last update from 192.168.1.2 on GigabitEthernet0/0/0, 00:00:15 ago
Routing Descriptor Blocks:
* 192.168.1.2, via GigabitEthernet0/0/0
Route metric is 20, traffic share count is 1The route is present in the routing table. If the route were missing, the issue would be routing protocol or static route configuration. Since it's present, the problem lies in the forwarding plane.
Verify CEF forwarding state for the prefix
show ip cef <destination-network>10.10.10.0/24 nexthop 192.168.1.2 GigabitEthernet0/0/0
If CEF shows the correct next-hop and interface, CEF is working. If CEF shows 'no route' or a different next-hop, CEF may be corrupted or not updated. If CEF shows 'attached' or 'receive', it indicates a local interface or special handling.
Check for CEF inconsistencies or errors
show ip cef summaryIPv4 CEF is enabled CEF table version: 1234 Prefixes: 1500 Routes: 1500 Adjacency updates: 10 FIB updates: 5 CEF errors: 0
Look for non-zero CEF errors. If errors are present, CEF may be corrupt. Also check if CEF is enabled globally (it should be by default). If disabled, enable it.
Check adjacency table for the next-hop
show adjacency <interface> <next-hop-ip> detailInterface: GigabitEthernet0/0/0 Next-hop: 192.168.1.2 MAC header: 00:1a:2b:3c:4d:5e Encapsulation: ARPA Adjacency: complete
If adjacency is 'incomplete' or 'glean', the router cannot resolve the next-hop MAC address. This can cause CEF to punt packets to the CPU, leading to dropped traffic. A 'complete' adjacency is required for hardware forwarding.
Root Cause
CEF (Cisco Express Forwarding) is disabled or corrupt on the router. Although the routing table has the correct route, CEF is not populating the Forwarding Information Base (FIB) correctly, causing packets to be process-switched or dropped. This can happen after a software upgrade, configuration change, or due to a bug.
Resolution
Verification
Run 'show ip cef <destination-network>' again to confirm the correct next-hop and interface. Then perform a traceroute from a device behind the router to the destination network to verify traffic is now using the correct path.
Prevention
1. Always verify CEF is enabled after any configuration changes or upgrades. 2. Monitor CEF errors using 'show ip cef summary' as part of routine maintenance. 3. Use consistent IOS versions across the network to avoid known CEF bugs.
CCNA Exam Relevance
On the CCNA 200-301 exam, this scenario tests understanding of the difference between the routing table (RIB) and the forwarding table (FIB). Candidates may be asked to troubleshoot why a route is in the routing table but not being used. The exam may present a multiple-choice question or a drag-and-drop troubleshooting scenario where CEF is the root cause.
Exam Tips
Remember that the routing table (RIB) is for control plane; CEF (FIB) is for data plane. A route in RIB does not guarantee it is in FIB.
Know the command 'show ip cef' to verify the forwarding entry. If the output shows 'no route', CEF is not updated.
Be aware that 'debug ip cef' can be used but is resource-intensive; use 'show' commands first.
Commands Used in This Scenario
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions