Cisco CCNA And CCNP Certification Exam Training:

Using Ping And Extended Ping To Troubleshoot Networks

By Chris Bryant, CCIE #12933

To earn your CCNA and CCNP certification, not to mention being able to troubleshoot network connectivity issues, you better know all about ping!

The ICMP packets sent by pings are technically echo request and echo reply messages. To compare the two ping commands and use them to troubleshoot a network, we'll use R1 and R3 in the following topology. As always, the last octet of the network is the router number. There are no routing protocols running on these routers.

If you use "regular" ping, five ICMP packets are sent by default.

R1#ping 172.12.123.3

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

If you use extended ping, you've got the option to send more or less than that, as shown below.  The bolded commands are the extended commands.  Here, we'll send 100 pings and send them one second apart.

R1#ping
Protocol [ip]:
Target IP address: 172.12.123.3
Repeat count [5]: 100
Datagram size [100]:
Timeout in seconds [2]: 1
Extended commands [n]: y
Source address or interface: 172.12.123.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 100, 100-byte ICMP Echos to 172.12.123.3, timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.
Success rate is 98 percent (65/66), round-trip min/avg/max = 68/68/72 ms

I used <ctrl-shift-6><ctrl-shift-6> to terminate the ping before all 100 ICMP packets were sent.  It's normal to see a ping failure at the very end of a terminated ping (65/66).

Why would you ever use the ping extended commands?  Let's consider a situation where a new LAN segment is added to R1. 

Pings from R3 to R1's new segment fail, but pings from R1 to R3 succeed. debug ip icmp shows why.

R1#ping 172.12.123.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 72/72/72 ms
R1#
23:01:33: ICMP: echo reply rcvd, src 172.12.123.3, dst 172.12.123.1
23:01:33: ICMP: echo reply rcvd, src 172.12.123.3, dst 172.12.123.1
23:01:33: ICMP: echo reply rcvd, src 172.12.123.3, dst 172.12.123.1
23:01:33: ICMP: echo reply rcvd, src 172.12.123.3, dst 172.12.123.1
23:01:33: ICMP: echo reply rcvd, src 172.12.123.3, dst 172.12.123.1

Since the pings from R1 to R3 are exiting R1 on 172.12.123.1, that's the default source interface for the ping; when R3 returns them, 172.12.123.1 is the destination, and R3's already connected to that network and can therefore return the pings. R3 cannot send a packet of any kind to 10.1.1.1 /24, since R3 doesn't have an entry for that network in its routing table.

The only way to send a ping from R1's ethernet interface to R3 is to use the extended ping with extended commands.

R1#ping
Protocol [ip]:
Target IP address: 172.12.123.3
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 10.1.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, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Extended ping has shown us that R1's Serial0 interface can ping R3, but R1's Ethernet0 cannot.  Don't make the assumption that you have 100% IP connectivity on a router just because one interface can ping a given destination.

Configuring RIP for both networks should resolve the situation.

R1#show ip protocols
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 11 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    Serial0               2     2
    Serial1               2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    172.12.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.12.123.3         120      00:00:12
    172.12.123.2         120      00:50:07
  Distance: (default is 120)

R1(config)#router rip
R1(config-router)#network 10.0.0.0

R1#ping
Protocol [ip]:
Target IP address: 172.12.123.3
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 10.1.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, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 72/72/72 ms

R1#
23:07:24: ICMP: echo reply rcvd, src 172.12.123.3, dst 10.1.1.1
23:07:24: ICMP: echo reply rcvd, src 172.12.123.3, dst 10.1.1.1
23:07:24: ICMP: echo reply rcvd, src 172.12.123.3, dst 10.1.1.1
23:07:24: ICMP: echo reply rcvd, src 172.12.123.3, dst 10.1.1.1
23:07:24: ICMP: echo reply rcvd, src 172.12.123.3, dst 10.1.1.1

The pings are correctly sourced from 10.1.1.1, and the incoming echo replies are indeed destined for that address.

Pings are simple enough on the surface, but to earn your CCNP certification and lay the groundwork for your CCIE studies, you need to dig beneath the surface. And when it comes to Cisco routing, there's always something else beneath the surface to learn!

To your success,

Chris Bryant

CCIE #12933

chris@thebryantadvantage.com