Ping Troubleshooting on Cisco IOS

The ping command can be used to quickly check if a remote device is reachable or not. In this lesson, I’ll show you how you can use it to troubleshoot issues in your network. Take a look at the following picture:

Above we have two host computers connected to a switch. H1 is sending a ping (ICMP request) and receiving an ICMP reply.

When this ping from H1 to H2 is successful, what does it tell us?

C:\Users\H1>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time<1ms TTL=255
Reply from 192.168.1.2: bytes=32 time=1ms TTL=255
Reply from 192.168.1.2: bytes=32 time<1ms TTL=255
Reply from 192.168.1.2: bytes=32 time<1ms TTL=255

Ping statistics for 192.168.1.2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

It does tell us quite some things. Think of the OSI model:

Since this ping is working, it tells me that everything on the physical layer, data link layer, and network layer in between H1 and H2 are functional.  We don’t have to worry about things like cabling, connectors, interfaces, VLANs, MAC addresses, ARP, IP addresses and subnet masks. If any of these were configured incorrectly, the upper layers wouldn’t work.

It doesn’t tell me much about the transport, session, presentation and application layers though. This ping worked, which uses the ICMP protocol but that doesn’t mean that an application would work. For example, TCP traffic for certain ports could be blocked by an access-list or a web server is not listening on TCP port 80. These are things we can’t check with the ping command. It only tells me that ICMP traffic was able to make it to the other end.

Let’s take a look at another example, where routing is also involved:

Look at the picture above for a moment, think of some of the routing related things we need in this network to make it work so that H1 can reach H2:

• Behind R2 is the 192.168.2.0/24 network. R1 has to know how to reach this network.
• Behind R1 is the 192.168.1.0/24 network. R2 has to know how to get there.
• H1 should use R1 as its default gateway so that is can get out of its own subnet.
• H2 should use R2 as the default gateway.

Let’s imagine that we are the administrator of R1, we don’t have access to any of the other devices. The user from H1 is sending us this ping result:

C:\Users\H1>ping 192.168.2.2

Pinging 192.168.2.2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.2.2:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

This ping from H1 to H2 is failing but this doesn’t tell us anything. Let’s look at some of the things we can do on R1 to figure our where the issue is.

Let’s go for a quick win, see if we can ping H2 from R1:

R1#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 0 percent (0/5)

This ping is failing. What I should do now, is ping the IP address that is one step closer to R1. That is 192.168.2.254 on R2:

R1#ping 192.168.2.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

This ping is also failing. What does this tell me? There are three options:

• Maybe the link in between R1 and R2 is not working.
• Maybe R1 doesn’t know how to reach 192.168.2.254.
• Maybe an access-list is blocking my traffic.

Let’s go back one more step, we will ping the IP address of R2 on the directly connected interface:

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

This ping is working. This tells me that at least the link between R1 and R2 is working. This could be a routing issue or an access-list that is filtering my traffic.

I don’t have to check if R1 has an access-list since packets that are generated locally are not filtered by the access-list. The access-list only checks traffic that transits the router. If R2 has an access-list or not might be hard to tell. If you send a ping that is denied by an access-list on Cisco IOS then you will receive a U (Unreachable) message. Most firewalls however, will silently drop your traffic.

Whether R2 has an access-list or not might be hard to tell. On Cisco IOS, if a packet is denied then the router will respond with a U (Unreachable) message. Most firewalls, however, will silently drop your traffic.

It’s easy to check if R1 has a route to network 192.168.2.0 so let’s start there:

R1#show ip route static

Gateway of last resort is not set

R1 doesn’t have a route for this network. Let’s add one:

R1(config)#ip route 192.168.2.0 255.255.255.0 192.168.12.2

Let’s try that ping to 192.168.2.254 again:

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

Finally, it’s working. This proves that R1 knows how to reach the 192.168.2.0 network. Let’s go one step further and see if R1 is now able to reach H2:

R1#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 = 2/5/7 ms

This ping is also working. This proves that H2 has a default gateway configured. H2 receives an IP packet from 192.168.12.1 and knows how to reply to it, it needs a default gateway for that.

We still don’t know if H1 is now able to reach H2 so let’s continue. First, let’s see if R1 is able to reach H1:

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

This ping is working. It tells us that H1 will be able to reach its default gateway. What it doesn’t tell us, is if H1 has a default gateway configured…

When R1 sends a ping, it will use its IP address on the closest interface to the destination. With the ping above, that means the source address is 192.168.1.254.

To test if H1 has a default gateway configured or not, we can send a ping from R1 that uses a different source IP address. We can do this with the extended ping command. Just type ping without any parameters and hit enter:

R1#ping
Protocol [ip]: 
Target IP address: 192.168.1.1
Repeat count [5]: 
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y
Ingress ping [n]: 
Source address or interface: 192.168.12.1
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [0x0000ABCD]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.12.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/6 ms

The router will ask you which parameters you want to configure. If you don’t enter something, it will use the default value. The source IP address will be 192.168.12.1 and H1 is able to reply to it. This tells us that H1 has a default gateway configured since it has to reply to an IP address that it outside of its own subnet.

You can also specify parameters behind the ping command like this, it’s faster than using the ping “wizard” every time:

R1#ping 192.168.1.1 source 192.168.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.12.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/5/6 ms

Ok, so we know that H1 can reach external networks through its default gateway and R1 is able to reach 192.168.2.2.

The only thing left we can try is to send a ping from R1 to H2 with an IP address from the 192.168.1.0 network:

R1#ping 192.168.2.2 source 192.168.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.254
.....
Success rate is 0 percent (0/5)

This ping is failing but it does tell us a lot. We know that R1 is able to reach H2, we also know that H1 can reach external networks. There are two options left:

• R2 doesn’t know how to reach the 192.168.1.0 network.
• R2 is filtering traffic from network 192.168.1.0.

There is no way for us to tell if R2 is using an access-list by only using the ping command, making it difficult to figure out if it’s a missing route or an access-list.

This is a good moment to pick up the phone and call the administrator of R2 to check their router:

R2#show ip route static

Gateway of last resort is not set

R2 is missing a route for network 192.168.1.0, that’s definitely something we need so let’s add it:

R2(config)#ip route 192.168.1.0 255.255.255.0 192.168.12.1

Now we can try another ping from 192.168.1.254 to 192.168.2.2:

R1#ping 192.168.2.2 source 192.168.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.254 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/6/8 ms

This proves that R2 does know how to reach network 192.168.1.0. That’s all we can do on R1, this would be a good moment to ask the user of H1 to try another ping:

C:\Users\H1>ping 192.168.2.2

Pinging 192.168.2.2 with 32 bytes of data:
Reply from 192.168.2.2: bytes=32 time<1ms TTL=255
Reply from 192.168.2.2: bytes=32 time<1ms TTL=255
Reply from 192.168.2.2: bytes=32 time<1ms TTL=255
Reply from 192.168.2.2: bytes=32 time<1ms TTL=255

Ping statistics for 192.168.2.2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Great, this ping is now working!

Conclusion

You have now learned how you can use the ping command to find and isolate (routing) problems in your network. By using the ping command and different sources, you can verify reachability throughout the network. In another lesson, we will look at traceroute which is a similar tool.