Using Extended Ping and Traceroute to Isolate Network Faults
Presenting Symptom
A user at a remote branch office cannot reach a server at the corporate headquarters, but other branches can reach the server.
Network Context
The network consists of a small branch office (Branch1) connected to the corporate headquarters (HQ) via a WAN link using a serial interface. Branch1 has a Cisco 4321 router running IOS XE 16.9, and HQ has a Cisco 4451 router. The branch uses OSPF as the routing protocol. The problem occurs intermittently, and basic ping from the branch router to the HQ server fails.
Diagnostic Steps
Step 1: Verify basic connectivity from the branch router to the HQ server using a standard ping
ping 10.1.1.100Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.100, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
If ping fails (0% success), there is a connectivity issue. This confirms the symptom but does not pinpoint the cause.
Step 2: Use extended ping to test with different source addresses and packet sizes to isolate the problem
ping
Protocol [ip]:
Target IP address: 10.1.1.100
Repeat count [5]:
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 10.1.1.100, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)Same failure with larger packet size; if only small packets fail, it might indicate MTU issue.
If both small and large pings fail, the issue is likely not MTU-related. If only large pings fail, suspect path MTU problem.
Step 3: Use extended traceroute to identify where packets are dropped
traceroute
Protocol [ip]:
Target IP address: 10.1.1.100
Source address: 192.168.1.1
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 10.1.1.100
1 192.168.1.254 4 msec 4 msec 4 msec
2 10.0.0.2 20 msec 20 msec 20 msec
3 10.0.1.2 20 msec 20 msec 20 msec
4 * * *
5 * * *Traceroute stops at a certain hop (e.g., hop 4 shows asterisks), indicating packet loss beyond that point.
If traceroute stops at a specific hop, the problem is likely at that router or the link beyond. Asterisks indicate no response, possibly due to ACL, routing, or interface issue.
Step 4: Check routing table on the branch router to ensure route to destination exists
show ip route 10.1.1.100Routing entry for 10.1.1.0/24
Known via "ospf 1", distance 110, metric 20
Last update from 10.0.0.2 on Serial0/0/0, 00:00:05 ago
Routing Descriptor Blocks:
* 10.0.0.2, via Serial0/0/0, 00:00:05 ago
Route metric is 20, traffic share count is 1If route is present, routing is working. If missing, OSPF may be down or not advertising the network. If route is present but ping fails, the issue may be at the next hop or beyond.
Step 5: Check OSPF neighbor state on the branch router
show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface 10.0.0.2 1 FULL/DR 00:00:34 10.0.0.2 Serial0/0/0
If neighbor is FULL, OSPF adjacency is up. If not FULL, there is an OSPF issue. If FULL but ping fails, problem may be elsewhere.
Step 6: Check interface status and errors on the WAN link
show interfaces Serial0/0/0Serial0/0/0 is up, line protocol is up
Hardware is HD64570
Internet address is 10.0.0.1/30
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
CRC errors: 0, frame errors: 0, overrun: 0, abort: 0
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
0 carrier transitionsIf interface is up/up and no errors, the physical layer is fine. If there are CRC errors or input errors, suspect cable or hardware issue.
Step 7: Check for ACLs that might be blocking traffic
show access-listsExtended IP access list BLOCK_ICMP
10 deny icmp any any (5 matches)
20 permit ip any any (100 matches)If an ACL is blocking ICMP (as in this example), ping will fail. The matches counter shows how many packets matched the deny statement.
Root Cause
An extended ACL named BLOCK_ICMP is applied inbound on the WAN interface (Serial0/0/0) of the branch router, denying all ICMP traffic. This ACL was mistakenly added during a previous change and was not removed. It blocks ICMP echo requests and replies, causing ping and traceroute to fail, but other IP traffic (like TCP) is permitted.
Resolution
Verification
Run a standard ping from the branch router to the HQ server: ping 10.1.1.100 Expected output: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.100, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Also verify that traceroute works: traceroute 10.1.1.100 Expected output: Type escape sequence to abort. Tracing the route to 10.1.1.100 1 192.168.1.254 4 msec 4 msec 4 msec 2 10.0.0.2 20 msec 20 msec 20 msec 3 10.0.1.2 20 msec 20 msec 20 msec 4 10.1.1.100 20 msec 20 msec 20 msec
Prevention
1. Implement a change management process that requires review of ACL changes before deployment. 2. Use ACL logging to monitor matches and detect unexpected traffic blocks. 3. Regularly audit ACLs on critical interfaces to ensure they are necessary and correctly configured.
CCNA Exam Relevance
On the CCNA 200-301 exam, this scenario appears in troubleshooting questions where you must identify why ping fails despite a valid route. The exam tests your ability to use extended ping and traceroute to isolate faults, and to interpret show commands like show ip route, show interfaces, and show access-lists. A key fact is that ACLs can block ICMP while allowing other traffic, so ping failure does not always mean a routing problem.
Exam Tips
Remember that extended ping allows you to specify source address, packet size, and other options to test different scenarios.
Traceroute shows the path and where packets stop; asterisks may indicate filtering or no route.
Always check ACLs on the path when ping fails but routing is correct; use show access-lists to see matches.
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 interfaces
Displays detailed status and statistics for all interfaces or a specific interface, used to verify interface operational state, errors, and performance.
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.
traceroute [ip]
Traces the route packets take from the source device to a destination IP address, showing each hop along the path, used to diagnose network path issues and latency.
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions