The route is in show ip route, but traffic to that prefix is still dropped. How do you troubleshoot it?
Show the answer
Say this first
Move from the RIB down to the forwarding plane. Check the FIB entry with show ip cef <destination> detail
and compare it with the RIB. Check the adjacency for that next hop is complete (ARP resolved). Then look at
what sits on top of routing: ACLs, PBR, uRPF, NAT, VRF membership, MTU. On hardware platforms confirm the
route is programmed and the TCAM is not full. Finally check the return path, because the reply can be what
is lost.
Go deeper
1. RIB against FIB
R1# show ip route 10.5.1.1
R1# show ip cef 10.5.1.1 detailThe FIB should have the same prefix and next hop. A missing entry, a different next hop or a drop entry points at a CEF or programming problem.
2. The adjacency
R1# show ip arp 10.0.12.2
R1# show adjacency GigabitEthernet0/0/1 detailAn Incomplete ARP entry means the next hop does not answer ARP: wrong address, wrong VLAN, layer 2
problem or a down neighbor. In show ip traffic, a rising encapsulation failed drop counter tells the
same story.
3. Things that override routing
show ip interface GigabitEthernet0/0/1 shows inbound and outbound ACLs, policy routing and uRPF on the
interface. Check:
- An ACL that denies the traffic.
- PBR sending it somewhere else.
- uRPF dropping it because the source fails the reverse path check.
- The interface sits in a VRF, so the global table you checked is not the one being used
(
show ip route vrf <name>). - MTU: large packets with DF set are dropped while pings with default size work.
4. Hardware
On switches and hardware routers, use the platform's hardware FIB and TCAM utilization commands. A full TCAM means some routes are not in hardware and are forwarded in software or dropped.
5. The return path
Ping and traceroute from the other side. Asymmetric routing through a stateful firewall drops the reply even when the forward path is perfect.
They will ask next
What would make the RIB and FIB disagree?
A software bug, a failed hardware programming update, a full TCAM, or a route that just changed and has not finished programming. IOS has CEF consistency checkers, and a
clear ip routefor the prefix forces it to be reinstalled, but find the cause before clearing in production.
Traps
- Stopping at show ip route. The RIB says what the router wants to do, not what the forwarding plane does.
- Forgetting the return path. Half of "cannot reach" problems are replies that never come back.