Troubleshooting IPv4 Routing for CCNA 200-301
Why IPv4 Routing Troubleshooting Matters
IPv4 routing troubleshooting is a core CCNA 200-301 skill because it sits right at the boundary between theory and real outages. When a user can ping the default gateway but still can’t reach a remote subnet, that’s not some abstract exam clue. Honestly, that’s the beginning of a real fault-isolation process, and it’s where good troubleshooting habits start to matter. Now here’s the thing: routing problems get impersonated all the time. A bad host mask, the wrong VLAN, a trunk issue, an ACL, NAT weirdness, or a broken return path can all make it look like routing’s at fault when it really isn’t. That is why method matters more than memorization.
For CCNA, the goal is not just to know commands like show ip route. You’ve really got to know what each command actually proves, what it doesn’t prove, and what your next move should be. That’s the line between guessing and actually troubleshooting. The engineers who move fastest, and honestly the CCNA candidates who usually do best, all seem to follow the same rhythm: check the interface first, then check the route, then confirm the next hop, and only after that start looking at policy and the return path. That sequence saves a lot of time because you’re proving things instead of guessing.
How Cisco Routers Actually Forward IPv4 Packets
A router forwards based on the destination IP address.
First, it does a longest-prefix match. In plain English, it looks for the most specific route that matches the destination.
Basically, the router asks, “What’s the most specific route I know that matches this destination?”’ The route with the longest mask wins.
If more than one route matches, the router then chooses the best source of that route using administrative distance. After that, it uses the metric to pick the best path within that routing source. So yeah, there are layers to the decision, and that’s exactly why you don’t want to jump straight to conclusions. So yes, the order absolutely matters.
So yeah, the order really does matter.
That order matters: longest prefix beats administrative distance.
Also keep three different views separate:
Configured route means the route exists in show running-config. Installed route means it appears in the routing table, or RIB, with show ip route. Forwarding entry means the route is resolved in the forwarding table, or FIB, which you can inspect with show ip cef. A route in configuration is not automatically installed, and a route in the RIB is not always enough to guarantee forwarding if Layer 2 resolution is broken.
Example:
Root cause: the next hop can’t be resolved, so the recursive static route is configured but not installed.Routing entry for 172.16.20.0/24 Known via "static", distance 1, metric 0 * 10.10.10.216.20.0/24 Known via "static", distance 1, metric 0 * 10.10.10.2
That tells you the route is installed in the RIB, so the control plane knows about it. To see how the router will actually forward, you can check CEF:
R1# show ip cef 172.16.20.0 172.16.20.0/24 nexthop 10.10.10.2 GigabitEthernet0/1
If Layer 2 resolution fails, CEF may show an incomplete adjacency. On Ethernet, that usually means ARP for the next hop failed. In other words, the router knows the route, but it cannot build the frame needed to send the packet.
One more CCNA detail: local routes marked with L are /32 host routes for the router’s own interface IP addresses. They are used for traffic destined to the router itself, while connected routes marked with C represent the attached subnet.
A Fast, Repeatable Troubleshooting Workflow
Use this order every time:
- Define the symptom precisely.
- Check host IP, mask, and default gateway.
- Verify local interface state with
show ip interface brief. - Validate the connected network and mask.
- Check the routing table with
show ip route. - Test next-hop reachability.
- Use ping or extended ping, then traceroute if needed.
- Check VLANs, trunks, ACLs, NAT, and dynamic routing.
- Validate the return path from the far end.
- Verify full restoration.
A simple memory aid is: Interface, Route, Next Hop, Policy, Return Path.
Exam fast triage order:
1) show ip interface brief
2) show ip route
3) ping the next hop
4) verify VLAN/trunk/ACL/NAT
5) validate the return path
Core IOS Commands and What They Really Prove
The following commands are commonly used to isolate IPv4 routing issues and identify the next area to investigate:
show ip interface briefconfirms interface IP addressing and whether interfaces are up or down. If the output looks wrong, check cabling, shutdown state, and VLAN or SVI dependencies.show ip routeconfirms which best routes are installed in the RIB. If the expected route is missing, check static configuration, dynamic routing, or the default route.show ip cefconfirms forwarding-plane resolution in the FIB. If forwarding looks incomplete, check ARP, adjacency issues, or next-hop resolution.show arpconfirms Layer 2 resolution on Ethernet. If entries are missing, verify next-hop reachability and the VLAN or trunk path.show interfacesreveals errors, duplex, speed, and line protocol details. Problems here usually point to physical or Layer 2 faults.show ip protocolsconfirms routing process participation and passive interfaces. If behavior is unexpected, review OSPF network statements, timers, and interface matching.show ip ospf neighborconfirms whether OSPF adjacency is formed. If not, check for area, subnet, timer, or passive-interface mismatches.show vlan briefconfirms access-port VLAN membership on switches. If the host is in the wrong VLAN, fix that first.show interfaces trunkconfirms trunk status and allowed VLANs. If a VLAN is missing, traffic for that VLAN will not cross the trunk.show access-listsshows ACL entries and hit counters. If traffic is blocked, verify where the ACL is applied and in which direction.show ip interface <int>shows ACL application and interface IP details. This helps confirm whether the correct ACL is attached in the correct direction.show ip nat translationsconfirms whether NAT or PAT translations exist. If none appear, check inside and outside roles, ACL matching, and overload configuration.show ip nat statisticsshows NAT hits, misses, and active translations. This helps distinguish translation failure from routing failure.
show cdp neighbors is useful for Cisco-to-Cisco topology checks, but CDP is Cisco-proprietary and may be disabled. In mixed environments, LLDP may be the better option if supported.
Troubleshooting Connected Routes and Interface States
If a connected route is missing, fix that first. No static or dynamic routing analysis matters until the local interface is healthy.
R1# show ip interface brief Interface IP-Address OK? Method Status Protocol GigabitEthernet0/0 192.168.10.1 YES manual administratively down down GigabitEthernet0/1 10.10.10.1 YES manual up up
Because G0/0 is shut down, the router will not install the connected route for 192.168.10.0/24.
Interface-state interpretation matters:
administratively down/down = interface is shut down.
down/down = usually no physical link or major Layer 1 issue.
up/down on Ethernet = physical layer is usually good, but line protocol is failing due to Layer 2, keepalive, or platform-specific issues.
up/up = interface is operational.
A wrong subnet mask does not usually prevent connected-route installation if the interface is up/up and addressed, but it can install the wrong connected prefix and create forwarding problems.
For SVIs on multilayer switches, behavior is platform-dependent, but an SVI generally comes up only when the VLAN exists and at least one Layer 2 port in that VLAN is in a forwarding state. Also verify ip routing is enabled where required for SVI-based inter-VLAN routing.
Static Routes, Recursive Lookup, and Default Routes
Static routes are easy to configure and easy to misread. Three forms matter at CCNA level:
Next-hop only
ip route 172.16.20.0 255.255.255.0 10.10.10.2
Exit-interface only
ip route 172.16.20.0 255.255.255.0 Serial0/0/0
Fully specified
ip route 172.16.20.0 255.255.255.0 GigabitEthernet0/1 10.10.10.2
On point-to-point links, exit-interface-only routes are fine. On multiaccess Ethernet, next-hop or fully specified routes are preferred because an exit-interface-only static route can cause the router to ARP for each destination host instead of just the next hop.
Important correction: a recursive static route using a next-hop IP must be resolvable through another active route before it is installed in the RIB. So the route may exist in show running-config but not appear in show ip route if the next hop cannot be resolved.
R1# show running-config | include ip route iip route 172.16.20.0 255.255.255.0 192.168.1.2
Root cause: the next hop can’t be resolved, so the recursive static route is configured but not installed.% Network not in table
Root cause: the next hop can’t be resolved, so the recursive static route is configured but not installed.% Network not in table
That output means the static route is configured but not installed.
Default routes are route-of-last-resort entries:
R1# show ip route Gateway of last resort is 10.10.10.2 to network 0.0.0.0S* 0.0.0.0/0 [1/0] via 10.10.10.2S* 0.0.0.0/0 [1/0] via 10.10.10.2
If the default route is missing, internet or remote-site access often fails.
If it’s there but users still can’t get out, I’d check four things right away: next-hop reachability, NAT, DNS, and the return path.
DNS failure can look like internet failure even when routing is fine.
Interpreting show ip route Correctly
Read show ip route in this order: destination prefix, route code, next hop, and prefix length. Common CCNA codes are C, L, S, S*, and O.
C 10.0.0.0/8 is directly connected, GigabitEthernet0/0 S 10.1.1.0/24 [1/0] via 192.168.1.2 S 10.1.1.128/25 [1/0] via 192.168.1.3
A packet to 10.1.1.130 uses the /25.
A packet to 10.1.1.50 uses the /24.
This is a classic exam trap.
Another one:
O 192.168.50.0/24 [110/2] via 10.1.1.2 S 192.168.50.0/24 [1/0] via 10.1.1.3
Both routes are to the same prefix, so longest-prefix match ties. The static route wins because administrative distance 1 is better than 110.
Inter-VLAN Routing Troubleshooting
Inter-VLAN routing mixes Layer 2 and Layer 3, so it creates a lot of false routing alarms.
In router-on-a-stick setups, I’d check the trunk first and then the router subinterfaces.
In multilayer switching, verify the SVI, VLAN presence, and ip routing.
Router-on-a-stick example:
interface GigabitEthernet0/0.10 encapsulation dot1Q 10 encapsulation dot1Q 10
If incoming frames are tagged for a VLAN that doesn’t match any configured subinterface, the router will drop them.
Switch-side verification:SW1# show interfaces trunk168.10.1 255.255.255.0! interface GigabitEthernet0/0.20 encapsulation dot1Q 20
If incoming frames are tagged for a VLAN that doesn’t match any configured subinterface, the router will drop them.
Switch-side verification:SW1# show interfaces trunk168.20.1 255.255.255.010.1 255.255.255.0 ! interface GigabitEthernet0/0.20 encapsulation dot1Q 20 encapsulation dot1Q 10
If incoming frames are tagged for a VLAN that doesn’t match any configured subinterface, the router will drop them.
Switch-side verification:SW1# show interfaces trunk168.10.1 255.255.255.0! interface GigabitEthernet0/0.20 encapsulation dot1Q 20
If incoming frames are tagged for a VLAN that doesn’t match any configured subinterface, the router will drop them.
Switch-side verification:SW1# show interfaces trunk168.20.1 255.255.255.020.1 255.255.255.0
If incoming frames are tagged for a VLAN that does not match any configured subinterface, the router drops them.
Switch-side verification:
SW1# show interfaces trunk Port Mode Encapsulation Status Native vlan Gi0/1 on 802.1q trunking 1 Port Vlans allowed on trunk Gi0/1 10
If VLAN 20 is missing from the allowed list, VLAN 20 traffic never reaches the router. That looks like a routing failure, but it is really a trunk problem.
Quick decision tree: host VLAN correct? access port correct? trunk carrying VLAN? subinterface or SVI up? gateway IP correct? If any answer is no, fix that before blaming routing.
OSPF Troubleshooting at CCNA Level
For CCNA, keep OSPF troubleshooting practical. The first question I’d ask is simple: is the route missing, or is the neighbor missing? If the route is missing, check whether adjacency exists and whether the local interface is participating in OSPF.
R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/- 00:00:33 192.168.12.2 GigabitEthernet0/1
If there is no neighbor, common CCNA causes include area mismatch, subnet mismatch on the link, passive interface, hello/dead timer mismatch, authentication mismatch, duplicate router ID, or the interface simply being down.
show ip protocols helps confirm which local interfaces are running OSPF. More specifically, the OSPF network statement tells you which local interfaces are part of OSPF and which area they belong to.
ACL and NAT as Routing Impostors
A valid route does not prove traffic is permitted. ACLs and NAT commonly mimic routing failure.
For ACLs, do not stop at show access-lists. An ACL entry affects traffic only if it is applied somewhere. Verify attachment and direction:
CCNA Exam Traps and Rapid Review
Here’s the part I’d really want you to remember under exam pressure: a route existing in the configuration doesn’t mean it’s installed, and a route being installed doesn’t always mean traffic will succeed. Inbound access list is 10 R1# show access-lists Standard IP access list 10 deny 10.10.10.0, wildcard bits 0.0.0.255 permit any
That tells you both the rule and where it is active.
For NAT, verify inside/outside roles, the match ACL or route-map, overload configuration, and whether translations are actually forming:
R1# show ip nat translations R1# show ip nat statistics
If the default route is correct but no translations appear for inside clients, the problem may be NAT rather than routing.
Return Path, Extended Ping, and Traceroute
Return-path failure is one of the most common reasons traffic works one way but not the other. Validate it from the far end: check the remote router’s routing table, confirm the remote host’s default gateway, and review far-side ACL or NAT behavior.
Extended ping is especially useful on routers with multiple interfaces because source selection matters. A normal ping may use a different source IP than you expect.
Traceroute is helpful, but not absolute.
Cisco IOS traceroute typically uses UDP probes by default, and ACLs, firewalls, ICMP handling, or load balancing can change the path or the response you see.
So traceroute is evidence, not final proof.
Compact Practical Scenarios
1. Static route in config but not installed
R1# show running-config | include ip route iip route 172.16.20.0 255.255.255.0 192.168.1.2
Root cause: the next hop can’t be resolved, so the recursive static route is configured but not installed.% Network not in table
Root cause: the next hop can’t be resolved, so the recursive static route is configured but not installed.% Network not in table
Root cause: next hop is unresolved, so the recursive static route is configured but not installed.
2. Inter-VLAN failure caused by trunking
SW1# show interfaces trunk Port Vlans allowed on trunk Gi0/1 10
Root cause: VLAN 20 missing from the trunk allowed list.
3. Route exists but ACL blocks it
R1# show ip route 10.20.20.0
Scenario 5: OSPF route missing because the neighbor never formedR1# show ip ospf neighbor % No neighbors found R1# show ip protocols Routing Protocol is "ospf 1" Routing for Networks: 192.168.12.0 0.0.0.255 area 0
Root cause: the interface is down, the subnet is wrong, or the neighbor never came up due to an OSPF mismatch. * 192.168.1.2
CCNA Exam Traps and Rapid Review
Here’s the part I’d really want you to remember under exam pressure: a route existing in the configuration doesn’t mean it’s installed, and a route being installed doesn’t always mean traffic will succeed. Inbound access list is 10
Root cause: this is a policy problem, not a routing problem.
4. Internet failure with default route present
R1# show ip route S* 0.0.0.0/0 [1/0] via 10.10.10.2
Route-code memory box:
C connected subnetL local /32 for the router’s own interface IPS static routeS* static default routeO OSPF-learned route..... Success rate is 0 percent
Root cause: default route points to an unreachable next hop, or the connected uplink path is broken.
CCNA Exam Traps and Rapid Review
Watch for these exam traps:
Configured is not installed. Check show running-config versus show ip route.
Installed is not always forwarded. Check show ip cef and ARP.
Forwarded is not always returned. Check the far-end route and gateway.
Longest prefix beats administrative distance.
Wrong VLAN or trunk issue can look like routing failure.
ACL denial can look like a bad route.
Route-code memory box:
C connected subnetL local /32 for the router’s own interface IPS static routeS* static default routeO OSPF-learned route
Final checklist:
Is the interface up?
Is the addressing correct?
Is the route installed?
Is the next hop reachable?
Is Layer 2 carrying the VLAN?
Is ACL or NAT blocking traffic?
Is the return path valid?
That workflow is exactly what Cisco expects at CCNA level: verify the local interface, verify the route source, verify next-hop reachability, and then check the common impostors around routing.