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:

h1 h2 sw1 icmp request reply

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:

osi model first three layers ok

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.

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 requ

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

small network ping troubleshooting example

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.

r1 ping h1 other interface

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.

If you think an access-list is blocking ICMP packets, you can always try the telnet command to different port numbers. This is a quick way to test if the remote device is blocking traffic to certain TCP port numbers. For example, on Cisco IOS, you can try to telnet to 192.168.1.1 80 to see if you can reach TCP port 80 on 192.168.1.1. On your desktop, nmap is a great tool to try.

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!

The ping command can also be used to isolate MTU problems, which is covered in the MTU troubleshooting lesson.

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.

Tags: , , ,


Forum Replies

  1. Rene,
    Hi. Great explanations. Couple quick clarifications.

    1. You mention ‘The MSS value isn’t synchronized between hosts, it can be different for each direction’ - I thought this gets negotiated as a part of the 3 way handshake? Are you saying in your example above if say set “ip tcp adjust-mss 1360” on the f0/1 of R2 and then set “ip tcp adjust-mss 1460” on the f0/1 of R1 then it wouldnt negotatiate down to the lowest common MSS and hence break?

    2. Assuming I am using GRE over IPSEC with transport mode I looked at a recent customer network in which the tunnel i

    ... Continue reading in our forum

  2. Hi Rene,

    As you mention the interface MTU for both end doesn’t need to be same.

    If let say R1 with interface MTU 9000 and R2 with interface MTU 1500. It will not cause any issue?

    Because the R1 sending 6 times more packet in one frame, R2 will able to receive it without any problem?

    Davis

  3. Hello Sameer.

    The quick answer is yes. Fragmentation will occur during encapsulation. If a PC is preparing an email to send, it will take the transport segment and encapsulate it into an IP packet. An IP packet can theoretically be up to 65535 bytes long. So during encapsulation from the Network to the Data Link layer on the PC, if an IP packet is larger than the allowable 1500 bytes

    ... Continue reading in our forum

  4. Got a few questions-

    1. You mention that it is no problem when the frame reaches 1514 bytes, but realistically how high can this go before it starts causing an issue on Ethernet?

    2. Why did it cause a problem communicating with the web server when you reduced the MTU to 1400? Should it not have just fragmented it? Is the DF bit used in HTTP? I mean it would slow things down a bit to fragment, but not stop them working altogether?

    3. What happens if one side has an MTU of 1400, and the other 1500? Does the side set to 1400 have an issue receiving packets over this

    ... Continue reading in our forum

  5. ... Continue reading in our forum

128 more replies! Ask a question or join the discussion by visiting our Community Forum