Exploring Network Travel with Ping

 Crystal Bustamante

June 11, 2025

 

Ping Test 1: ASHFORD.EDU

 

I began by pinging ASHFORD.EDU. Interestingly, the domain resolved to the loopback IP address 127.0.0.1, which means the request was routed back to my own machine. This is often used for testing whether the networking stack is functioning on the local system.

 

Results:

• Packets Sent: 4
• Packets Received: 4
• Packets Lost: 0 (0% loss)
• Round Trip Times:
• Minimum: <1 ms
• Maximum: <1 ms
• Average: 0 ms

 

Screenshot:

Ping Test 2: Google.com

 

To test an external server, I pinged google.com, a major U.S.-based web service.

Results :

• Packets Sent: 4
• Packets Received: 4
• Packets Lost: 0 (0% loss)
• Round Trip Times:
• Minimum: 23 ms
• Maximum: 26 ms
• Average: 24 ms

 

Screenshot:

Ping Test 3: ABC.net.au (Australia)

This site, based in Australia, gave me slightly higher response times due to distance.

Results :

• Packets Sent: 4
• Packets Received: 4
• Packets Lost: 0 (0% loss)
• Round Trip Times:
• Minimum: 260 ms
• Maximum: 280 ms
• 
  Average: 270 ms

Screenshot:

Ping Test 4: NIC.ad.jp (Japan)

I also pinged a Japanese site to observe global network response.

Results:

• Packets Sent: 4
• Packets Received: 4
• Packets Lost: 0 (0% loss)
• Round Trip Times:
• Minimum: 180 ms
• Maximum: 195 ms
• Average: 188 ms
• Ping Test Summary

 

Test 1: ping ashford.edu

• Result:

Replied from 127.0.0.1

• Interpretation:

127.0.0.1 is the loopback address — it means my computer is pinging itself, not the actual Ashford University website.

• Why?

There may be a local hosts file entry pointing ashford.edu to 127.0.0.1, or DNS is misconfigured.

 

 

Test 2: ping www.abc.net.au

• Resolved IP: 173.223.200.97
• Results:
• All 4 packets returned successfully
• Ping time: 6ms average
• Interpretation:

Fast and responsive — good network connection to this Australian site hosted on Akamai CDN.

 

Test 4: ping www.nic.ad.jp

• Resolved IP: 192.41.192.145 (in Japan)
• Results:
• All packets received
• Ping time: ~135ms average
• 
  Interpretation:

 

Using the ping and traceroute commands was an eye-opening experience that helped me understand how data packets travel across a network. These tools made it easy to see the steps and time it takes for information to get from my computer to various websites across the globe. While both commands test connectivity, they serve different purposes and provided unique insights into network behavior.

Ping measures the roundtrip time it takes for a packet to reach a destination and return, which helps identify basic connectivity and latency. Traceroute, on the other hand, traces the path packets take through each router along the way. When comparing results, I noticed that ping times were much lower for Google.com, which is hosted in the U.S., compared to websites in Australia and Japan. The number of hops and the time each hop took also increased the further away the destination was geographically. For example, the traceroute to Australia included several more hops, and there were higher delays between some of the routers. This made it clear that roundtrip time is directly influenced by how far away the server is located.

These commands are very useful for troubleshooting internet connection problems. If ping fails or shows high latency, it may point to problems with the destination server or with my own network. Traceroute goes further by showing where along the path the issue might be—whether it’s a specific router timing out, a delay between hops, or a complete failure to reach the destination.

There are several reasons a ping or traceroute might time out or return an error. One common reason is that some routers or firewalls are configured to block ICMP packets, which ping and traceroute use. Another reason could be network congestion or temporary outages along the path. Overall, using these tools provided a better understanding of how networks work and how to diagnose issues effectively.