Ping (ICMP)

Introduction

Ping is a network utility to check network connectivity to a target destination. Ping is built-in on Windows, Linux and MAC OS. Ping operates based on the Internet Control Message Protocol (ICMP). It is commonly used to find out whether a destination host is reachable or not.

Intuition

In this quarantine period, people stay at home during the lockdown restrictions. After spending countless day binge watching Netflix, you suddenly miss your friends. The natural thing to do is to reach out to our iPhone and call them — “Hey <insert weird name here>, are you still alive?”.

Machine also needs to know if their peers (target destination) are alive to communicate. Instead of iPhones, the machines use the PING command to check if their peers are still reachable on the network.

There are two ways for machines to check for host reachability;

(A) using Keepalive message (periodical)

Some devices like routers use keep alive messages that are sent out periodically to check if their peers are still alive. For example, routers that run on RIPv1 sends out updates every 30s to all their peers to keep the heartbeat alive.

(B) using Ping command (triggered)

End devices normally send PING request to a destination host and waits for the PING reply to determine if the target is reachable after a period of inactivity. For the devices that are already in a TCP session, there is no need to PING since we are sure these devices are already connected.

ICMP

The Internet Control Message Protocol (ICMP) is a helper protocol that supports IP for error reporting and simple queries. Imagine throwing a stone at your neighbour’s house — your neighbour might throw the same piece of stone back at you; or if you got lucky, he might throw a piece of gold back at you. ICMP provides machines the same capability to throw this ‘are you alive’ message back and forth.

ICMP is a simple protocol; there are only 2 types of ICMP messages.

PING use ICMP request and reply to check for network/host connectivity

In this example, Host_A pings Host_B. Here, the Host_A sends the ICMP request to Host_B. If Host_B is reachable, it sends ICMP reply back to Host_A. If Host_B is not reachable, an ICMP error message is generated by the router and sent to Host_A.

There are two outcomes of the ICMP operations —

(A) Ping is successful

the source host successfully received the ICMP reply from the destination host. In this case, the connection metrics will be shown.

PING is successful, 4 ICMP requests are sent to destination; 4 ICMP replies are received. The first ICMP request is responded in 5ms; the remaining Time-to-live (TTL) is 128 hops. The second and third ICMP request is responded in less than 1ms. The fourth ICMP is replied after 8ms; probably due to network congestion.

(B) Ping failed

the source host did not received the ICMP reply from the destination after a period of time. In this case, an ICMP error message will be generated to the source host.

There are many types of options for these two ICMP messages. This options made ICMP error messages to be intuitive; so we can quickly guess what’s causing the connectivity issues. The full table of ICMP codes can be found here. The two most common errors are Destination network unreachable and Request timed out.

ICMP error — Destination host unreachable. This means 192.168.2.1 is not reachable. This could be the host is down, or the router of the remote network is down, or the link connecting the routers are down. The local router 192.168.1.254 generate this message to inform the sender that the destination is not reachable.
ICMP error — Request timed out. This message is generated by the sender itself after the max duration to wait for the ICMP reply has timed out. This could be a problem with the host itself, like having invalid IP, or no default gateway is assigned to the host.

How to use PING command

Ping is pre-installed as part of the network utilities in most modern OS. The syntax for ping is:

PING <IP address of target host>eg.
ping 192.168.1.1

To use PING on Windows:

1. Launch command prompt.

2. Type the command ‘ping’ followed by the ‘destination host IP address’

To use PING on MAC OS

1. Launch terminal.

2. Type the command ‘ping’ followed by the ‘destination host IP address’

To use PING on Linux

1. Launch Shell

2. Type the command ‘ping’ followed by the ‘destination host IP address’

As you can see, the ping command is universal across most OS. The only differences is the types of options we can add while using the ping command. For example, on Windows; 4 ICMP request are sent for each ping command. Meanwhile, on Linux; the ICMP requests are sent indefinitely until the user manually stop it.

We can find out the options for PING using the -h parameter.

All the available options for PING to satisfy your needs

If we issue a ping to Google web server on a MAC; the machine will continuously ping until we press ctrl+c to terminate it.

Ping in Linux and MAC is indefinite. On Windows, only 4 ICMP are sent for each command execution

To send only 2 ICMP request, we use the -c options. Here, we simply type ‘ping google.com -c 2’ to set the ICMP count.

Setting the count for ICMP request with -c option

There are many other options that you can experiment with based on the guides from -h output.

The figure below visualise what just happened — a local host with IP 192.168.1.1 is trying to ping Google.com web server located somewhere on the Internet with the IP 172.217.174.174. Firstly, the local host sends DNS request to DNS server to resolve ‘google.com’. Secondly, the DNS server return the IP 172.217.174.174 to the local host. Thirdly, the local host builds the ICMP request to the destination 172.217.174.174. After a shortwhile, Google replied back to the local host.

How messages flow when PC1 ping Google.com

Troubleshooting connectivity issues with PING

Continuing from the earlier example where PC1 failed to ping failure Google Web Server. How do we fix this connectivity issues? — The first step is to isolate the point of failure. In this case, any device starting from PC1 itself, to the routers in the middle, until the destination web server can be a point of failure. To find out where it fails, we need to systematically ping each of the node along the path to detect where the ICMP packets are dropped.

Any nodes along the path from PC1 to Google Server is a possible point of failure

A systematic troubleshooting starts from the source; going to the direction of destination. Here’s how we can perform step by step troubleshooting:

(1) Perform Self Diagnostic on PC1

On PC1, we perform a self-ping using the command ping 127.0.0.1. This is a self diagnostic test to check if the TCP/IP stack on PC1 is working properly. If the ping is successful, this means the problem is on some other nodes after PC1.

PC1 passed self test. The ICMP packet should be sent successfully to the next hop, which is Router1

If the ping fails, it means the NIC of PC1 might not be working properly.

PC1 is the point of failure. The packet is not sent out from PC1.

(2) Perform Ping Test to Router1

If PC1 is cleared, next we try to ping next hop address; which is Router1. We can ping either interfaces; 192.168.1.254 or 10.10.10.1 directly connected to Router1. If the ping is successful, this mean the packet is discarded somewhere after Router1.

Router1 has already forwarded the packet to the next hop, Router2

If the ping failed, this imply that Router1 is mis-configured with the wrong IP address or the interface is not yet set to UP (using the no shut command); or the router is simply broken.

Misconfigurations on Router1, Packet is dropped at Router1

(3) Perform Ping Test to Router2

If Router1 is cleared, next we ping 10.10.10.2 on Router2. If the ping is successful, this means Router2 has already forwarded the packet to the next hop.

Router2 is presumed to have already forwarded the packet to the next hop

If it fails, this can means several things:

(a) IP is configured wrongly on Router2

(b) Interfaces on Router2 is not set to UP

(c) Hardware issues with Router2

(d) Routing is not configured from PC1’s Network to Google’s Network

(e) Firewall is blocking ICMP request from entering Router2

(f) If the ping pass at 10.10.10.2 but failed at 172.217.174.174, this could indicate issues with NAT configurations on Router2

The packet is dropped at Router2. Router1 will generate an ICMP error back to PC1 to inform on the non-delivery

(4) Perform Ping Test to Google Web Server

If Router2 is cleared, this means that the packet has succesfully traveled from PC1 →Router1 →Router2; so the last possible point of failure is the Google Web server.

If the ping is successful, then Google Web server will send the ICMP reply back in the opposite direction back to PC1 and that’s how PC1 see this output on its end.

PC1 → Server is connected.

This could due to the server is down at the moment, or the load balancer in Google Data center is simpl not responding. Most of the time, Google has setup Firewall to prevent outsiders from pinging their servers to prevent the denial-of-service attack. In some rare cases, the server is actually reachable; but the ICMP reply going back from the server →PC1 is dropped on the way back due to security settings like ACL.

Google Server dropped the packet, possibly due to security settings

Normally, we would ping the destination host directly in ping test. Step by step troubleshooting is only nessecarily if the ping fails.

Checking end to end connectivity with Trace Route

So step by step troubleshooting is cool, but imagine isolating a point of failure on a topology with 200 routers in between the source and the destination. That’s where trace route comes in.

Trace route is a network service (like ping on steroid) that check end to end connectivity at per-hop basis. Think automatically ping each nodes in the path leading to the destination; all with one ‘tracert’ command. The syntax is:

tracert <destination IP>eg. 
tracert 172.217.174.174

Using the same example network, we can quickly check the point of failure by performing tracert on PC1 to Google Web Server.

PC1 →Server passing through 2 hops with extremely low latency

The output shows that Google Web server is reachable from PC1, across 3 hops. The latency of each hops is also shown. Tracert is also useful to troubleshoot poor performing nodes, especially to find out which router is congested when online game is lagging. In our example, both hops are so fast that the packet is forwarded to the next hop in only 6ms.

We can measure the time it takes for packet to travel from source to destination back to source as Round trip time (RTT). RTT gives a clearer picture of the network quality since the path taken to go from source →destination and back from destination →source might be different.

I’m just a little boy, lost in the tech world. But remember, love is a riddle, and life with tech is more amazing than ever