Traveling Through a Network

 


The ping and traceroute (tracert) commands are useful in troubleshooting connectivity problems and latency when accessing resources over the network or internet. The results from each of the commands help one determine the destination address and the path the packets take to reach it. 

The following screenshots below demonstrate the basics of using the ping and tracert commands from a Windows PC.

Figure 1
Ping to Google.com

Note. The ping results from my Windows PC to Google.com returned an IPv6 address. No packets were dropped or lost and the average speed across the four replies was 19ms.

Figure 2
Ping to Carused.jp
Note. The ping results to carused.jp had 100% packet loss.

Interestingly, my ping test to carused.jp had a 100% packet loss even though the site was rendered properly in a browser. I suspect the issue could be a setting, perhaps in their firewall where the site is hosted that prevents pings. The reason the site worked correctly is that it uses a different port such as 443 for HTTPS.

Figure 3
Ping to Sina.com.cn


Note. The ping results to sina.com.cn were successful with 0% packet loss. The average speed in round trip times was 218ms, which is much slower than the ping response from Google..

With the ping activity complete, here are my trace results:

Figure 4
Tracert Command to Google.com


Note. Tracert to google.com completed in 10 hops with no indication of latency. However, hops 5 and 8 seem to indicate that packets were not returned in the expected time, which may be an indication of some packet loss in the round trip time (RTT) or the router is discarding the traceroute packet.

Figure 5
Tracert Command to Carused.jp
Note. Tracert to Carused.jp completed in the maximum 30 hops. After the 13th hop, the tracert requests began to time out until they reached the maximum number of hops.

Figure 6
Tracert Command to Sina.com.cn

Note. Tracert to Sina.com.cn completed in 18 hops. Although the hops 1 through 8 returned relatively quickly, hops 9 through 18 indicated a bit of latency with traceroute requests returning over 150ms. The increased time in RTT is not a surprise given the destination is likely hosted internationally.

In conclusion, using ping and traceroute (tracert) commands can be a good first step in identifying connectivity-related issues. For example, when attempting to reach Google.com, the computer will send the request to a DNS server to identify the destination IP Address. After reaching the DNS server, the DNS server returns a response (packet) to the computer with the destination address of Google.com. The computer receives the packet and is now able to communicate with Google's server(s) at the IP address provided. If a computer is encountering a problem reaching Google, the ping and tracert commands can be used in identifying the problem. However, it is important to know that ping or traceroute requests may fail. A couple of reasons a ping or traceroute request may fail, include: a firewall setting may prevent ping requests or a router may be configured to disregard traceroute requests. In these situations, other troubleshooting methods may need to be considered, e.g., testing from another computer on the network and checking firewall rules.

Comments