Traveling Through a Network : Ping and Traceroute

Part 1: Ping Activity

Reviewing the steps from our guide this is what I got from google.com.

    From this you can see that the ping indicates 4 packets were sent and 4 were received with 0 loss.  Communication was successful as our guide says that we will see the round-trip time in milliseconds and if not, we will get an error message. There was an average 28ms response time, which according to TestOut, is “comfortable” if the response time is 50ms or shorter. This shows a strong and reliable internet connection.

Next, I pinged abc.edu.au which is The Australian Broadcasting Corporation.

    The results showed that 4 packets were sent, 4 packets, were returned, and 0 packets were lost. This confirms that there are no connectivity issues. However, the response time increased to an average of 258ms, showing that it was way slower than my recent ping to Google. This shows that an increase in response time is because data had to travel a longer distance to reach Australia and return which could cause “slower page loads and delayed playback” (Calix, 2026).

Lastly, I pinged bbc.co.uk which is The British Broadcasting Corporation.

    These results show 4 packets were sent, 4 packets were received, and 0 packets lost. Also confirming that there are no connection issues. The response time confused me as the UK is overseas which I believed would show a higher latency response time. After doing a little research on why this would be the case, apparently BBC uses “two external CDNs called Akamai and Limelight (now known as Edigo)” (Connected Devices Team, 2021). A Content Delivery Network (CDN) “enables faster web performance by locating copies of web content closer to end users” (Smith & Jones, 2024), which ensures faster response times. This showed a strong connection as well.

Part 2: Traceroute Activity

    The traceroute to google.com, shows that the packets went through 22 hops before reaching its final destination. The hop times ranged between 15ms and 38ms, with hop seven reaching the highest timed hop at 49ms. According to our guide this indicates how long it takes to reach the next router. Even though hop 11-21 is not considered successful hops (marked by *) shows the final destination at the end of the command. This traceroute was successful.

    This second traceroute was The Australian Broadcasting Corporation shows that the packets went through 14 hops before reaching the final destination. There was a noticeable increase when the packets arrived at hop 7, where it jumped to around 232ms-240ms indicating that the packets traveled internationally. “Request timed out” happened during different hops in which case those hops were not successful. Overall, since it finally reached its destination, it was successful.

    The last traceroute was to the British Broadcast Corporation. It shows that the packets went through 5 hops before arriving to the final the final location. Since the domain was not specified it only showed the IP address. Only hop four was not successful. The response time ranged from 14ms-38ms from hop two and three but increased during the last hop with the lowest at 41ms and the highest at 70ms. The traceroute is successful and compared to the “Australian” route was significantly faster, probably due to the CDNs I mentioned during part 1.

Part 3: Traveling Through a Network Reflection Essay

    Comparing the results from different websites showed that the paths varied in both the number of hops and response times. The Australian website had significantly higher round trip times, which supports the idea that greater geographical distance generally increases latency.

    The relationship between round trip time and location is clear as the farther the data has to go, it will likely take longer to return. Unless CDNs are involved like with BBC in the United Kingdom, the latency will usually always stay higher.

    Ping and Traceroute are useful trouble shooting tools as ping checks whether or not a device is reachable and traceroute shows the path packets take and where delays or failures occur showing that both go hand in hand.

    Regarding why either of them will time out or return with an error, according to Paessler PRTG, ping errors could indicate that “your computer cannot find a route to the target” (Paessler Editorial Team, 2025) or “The host name cannot be resolved to an IP address” (Paessler Editorial Team, 2025). For traceroute errors, according to Caleb Dagenette, it could be due “consecutive timeouts across multiple hops” often indicating packet loss or “consecutive hop may signal a routing loop, trapping data in a cycle between routers” (Dagenette, 2024).

    Overall, doing this activity helped me better understand how packets travel across a network.

References

Calix. (2026, January 29). What Is Latency in Internet, and Is It the Key to Faster Online Experiences? Calix.com; Calix. https://www.calix.com/blog/2026/01/latency-in-internet.html

Connected Devices Team . (2021, February 21). Beyond Speed Tests: CDN Performance. Thousandeyes.com; ThousandEyes. https://www.thousandeyes.com/blog/beyond-speed-tests-cdn-performance

Dagenette, C. (2024, August 15). Understanding Traceroute: A Key Tool for Network Troubleshooting - xByte Cloud Blog. XByte Cloud Blog. https://blog.xbytecloud.com/understanding-traceroute-a-key-tool-for-network-troubleshooting/

Paessler Editorial Team. (2025, August 20). How to Use Ping for Troubleshooting. Blog.paessler.com. https://blog.paessler.com/how-to-use-ping-for-troubleshooting

Susnjara, S., & Smalley, I. (2024, July 23). Content delivery network. Ibm.com. https://www.ibm.com/think/topics/content-delivery-networks

TestOut Corp. (2024). CertMaster Learn Tech+. http://www.testout.com