Exam ScenariosCCNA 200-301

Reading show ip route Output Correctly on CCNA Exam

Presenting Symptom

A network engineer notices that a remote network is not reachable, but the show ip route output shows a route with a next-hop IP that is not directly connected.

Network Context

The network is a small branch office with two routers (R1 and R2) connected via a serial link. R1 is connected to the LAN (192.168.1.0/24) and R2 is connected to the WAN (10.0.0.0/8). The engineer is troubleshooting connectivity from a host on the LAN to a server at 10.1.1.1. Both routers run IOS 15.x and use static routing. The engineer suspects a routing issue after pinging the server fails.

Diagnostic Steps

Check the routing table on R1

show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
S       10.0.0.0/8 [1/0] via 192.168.2.2
C       192.168.1.0/24 is directly connected, FastEthernet0/0
C       192.168.2.0/24 is directly connected, Serial0/0/0

Look for the route to the destination network (10.0.0.0/8). The output shows a static route (S) with next-hop 192.168.2.2. However, note that 192.168.2.2 is not directly connected; the directly connected networks are 192.168.1.0/24 and 192.168.2.0/24. The next-hop should be an IP on a directly connected network. Here, 192.168.2.2 is on the 192.168.2.0/24 network, so it is directly connected. Wait, actually it is directly connected. Let me re-evaluate: The output shows C for 192.168.2.0/24, so 192.168.2.2 is directly connected. So this step is fine. But the problem is that the route exists but ping fails. So we need to check further.

Verify the next-hop reachability

ping 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

If ping succeeds, the next-hop is reachable. If it fails, there is a Layer 1/2 issue. In this scenario, ping succeeds, so the problem is elsewhere.

Check the routing table on R2

show ip route

Codes: C - connected, S - static, ...

     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.0.0.0/8 is directly connected, FastEthernet0/0
C       192.168.2.0/24 is directly connected, Serial0/0/0
S       192.168.1.0/24 [1/0] via 192.168.2.1

Check if R2 has a route back to the source network (192.168.1.0/24). The output shows a static route via 192.168.2.1, which is directly connected. So return route exists.

Check for packet filtering or ACLs

show access-lists

Extended IP access list 100
    deny icmp any any echo (4 matches)
    permit ip any any (10 matches)

If an ACL is blocking ICMP or the traffic, it will show matches. Here, ACL 100 denies ICMP echo requests, which explains why ping fails even though routes are correct.

Root Cause

An extended ACL (100) on R1 is blocking ICMP echo requests from the LAN to the server, causing ping failures despite correct routing.

Resolution

Remove the deny statement from ACL 100 or modify it to permit ICMP. Use the following commands: R1(config)# ip access-list extended 100 R1(config-ext-nacl)# no deny icmp any any echo R1(config-ext-nacl)# end Alternatively, if the ACL is applied to an interface, remove it: R1(config)# interface FastEthernet0/0 R1(config-if)# no ip access-group 100 in

Verification

Run 'show access-lists' to confirm no deny entries for ICMP. Then ping from a host on 192.168.1.0/24 to 10.1.1.1. Expected output: '!!!!!' (success). Also run 'show ip route' to confirm routes unchanged.

Prevention

1. Use ACLs only when necessary and ensure they permit required traffic. 2. Apply ACLs inbound on the interface closest to the source to filter early. 3. Regularly audit ACLs with 'show access-lists' to check for unintended denies.

CCNA Exam Relevance

On the CCNA 200-301 exam, this scenario tests the ability to read 'show ip route' output and correlate it with ACLs. Expect a multiple-choice question where you must identify why a route exists but ping fails. Key fact: A route in the routing table does not guarantee end-to-end connectivity; ACLs can block traffic.

Exam Tips

Always check ACLs when a route exists but ping fails — the exam loves this trap.

Remember that 'show ip route' only shows routing; packet filtering is separate.

Memorize the 'show access-lists' command and how to interpret match counts.

Commands Used in This Scenario

ping [ip]

The ping command sends ICMP echo requests to a destination IP address to test network connectivity and measure round-trip time.

show access-lists

Displays all configured access control lists (ACLs) on the device, including their entries and match counters, used to verify ACL configuration and traffic filtering.

show ip route

Displays the current IP routing table on a Cisco router, used to verify routes, check next-hop addresses, and troubleshoot connectivity issues.

Test Your CCNA Knowledge

Practice with scenario-based questions to prepare for the CCNA 200-301 exam.

Practice CCNA Questions