Traveling as a "Packet" through the internet

Ping and Trace-route are an excellent tool to "travel" through your network infrastructure. For myself utilizing terminal as I am an Apple OS user, was quite interesting considering I had to deal with a network outage and re-run some queries to get valid information back to discuss upon it. 

For pings seeing information as ICMP packets on how fast my information travels to a site and back or as an echo is very useful and can show how quickly I can effectively communicate with the sites servers to retrieve information on normal browsing activities throughout these sites I used.

Pinging an AU based site showed how location impacted my response time with latency of echos returned to be reaching almost 40ms. The closer you are the better your connection to the server



Trace-route provides me the information on where my data is being sent through on the various sources throughout the internet that is sending and receiving information. For each hop and latency ping it shows me the path and the time it takes before it can reach its destination source this can be useful in determining where the data is going and coming from and if there are any errors like the timeouts I received along the intended path. Also, as an IT professional monitoring network traffic through these means is also key to see if there is any misconfigurations in the routers network congestion or specific firewall settings that could be blocking the information.

For the trace-route, due to my ISP losing connection whilst I was attempting to conduct them there were timeouts occurring within the 12th hop and into the 15th reaching it's destination at the 21st hop. 










In conclusion using queries such as ping and trace route is incredibly useful for diagnosing and troubleshooting network connectivity issues. Ping is a very simple to use command to validate whether a specific host is reachable in the first place and if it is one can measure the exact time it takes, as well as determining if the device or server is even online and responsive or if you must conduct diagnostics on it or your own host. With a command like trace route the detailed map of the route your packets take to reach their destination and identifying the hops along the way. this is valuable in pinpointing bottlenecks, routing problems, or a failure in specific segments of the network. Used in conjunction they can offer an individual a clearer view of overall network performance and reliability and allow network admins to monitor and ensure there are no issues with their networks.

Comments

  1. From Peer;

    You’ve got a thorough and insightful analysis of your ping and traceroute results! It’s interesting how your ISP outage added an extra layer of complexity to your testing, but you still managed to collect and interpret meaningful data.

    For your ping results, I noticed your average roundtrip times were slightly higher (Google: 36.258 ms, Australian site: 33.108 ms, EU site: 34.752 ms) compared to mine, which hovered around 18–22 ms for Google and other regional servers. The ISP outage likely contributed to the higher latency in your tests, which is a great example of how external factors like network interruptions can impact performance. Your consistent 0% packet loss across all sites, even with the higher latency, highlights stable connections once your ISP service resumed.

    For traceroutes, your experience with timeouts and incomplete paths is something I’ve encountered as well, particularly with international sites. For example, in my traceroutes to European and Asian servers, I also noticed multiple hops timing out due to servers blocking ICMP packets or network congestion. Your observations about using traceroute to monitor network traffic and pinpoint issues like misconfigurations or firewalls are spot on.

    One thing I found interesting is that your traceroute to Google reached its destination, albeit with timeouts at the 21st hop. My traceroute to Google completed with fewer hops and no persistent timeouts, which might be due to differences in our physical locations, ISP configurations, or the specific Google data center being accessed.

    Overall, I think you did an excellent job of explaining how these tools can be used for troubleshooting and monitoring networks. It’s clear you’ve got a strong understanding of how to apply these commands in real-world scenarios.

    ReplyDelete
  2. From Peer;

    Good Evening Camren,

    Your ping results showed slightly higher latencies than mine, likely due to geographic distance, ISP differences, or your ISP outage. For example, your ping to Google.com averaged 36.258 ms compared to my 16.9 ms. Your traceroutes, however, experienced more persistent timeouts, particularly for news.com.au and eudicom.eu, which reached the 40-hop limit. This highlights how network architecture, routing, or congestion can impact results, even when testing the same sites.

    Your essay is detailed and explains the importance of ping and traceroute well. To improve, consider discussing how ISP outages affect test results and how traceroute timeouts often result from security policies or packet prioritization rather than failures. Adding these points would provide more context and technical depth for your blog post.

    ReplyDelete

Post a Comment