Skip to main content

Traveling Through a Network

Traveling Through a Network

Part 1: Ping Results

Using the ping command gave me a first view of connectivity and latency. I tested three domains:

  • Google.com: 5 packets sent, 5 received. Range of responses: 4.887 ms.
  • BBC.co.uk: 5 packets sent, 5 received. Range of responses: 11.061 ms.
  • ANU.edu.au: 5 packets sent, 0 received. No valid latency data (100% packet loss).






 Figure 1-3
Ping command results for three domains.

Part 2: Traceroute Results

The traceroute command showed how packets moved across routers to reach each site:

  • Google.com: 20 hops, latency 2–23 ms, final RTT ~21 ms. Destination reached successfully.
  • BBC.co.uk: 5 hops responded, then all others timed out. Likely blocked by firewall or CDN settings.
  • ANU.edu.au: 20 hops. Local/ISP hops (1–5) ranged 4–22 ms. A Trans-Pacific jump (hops 11–13) spiked to 50–187 ms. Final hops in Australia stabilized around 200–307 ms. Destination reached.










 Figures 1-5 Traceroute results across local, CDN, and international routes.

Part 3: Reflection Essay

Running both ping and traceroute gave me a hands-on understanding of how packets travel across networks. Ping measures round-trip time (RTT) and packet loss, while traceroute maps the sequence of routers a packet visits. Together, they revealed both speed and path.

For Google.com, the results showed an efficient route to a U.S. data center. Low latency (~19 ms) and a complete traceroute confirmed both speed and reliability. For BBC.co.uk, the story was different: ping worked fine (low latency), but traceroute stopped after 5 hops. This likely reflects the use of content delivery networks (CDNs) or firewall rules that block traceroute responses while still allowing normal traffic. Finally, ANU.edu.au showed packet loss in ping (blocked ICMP echo requests) but a successful traceroute, proving that traffic still reached the destination despite the server not responding to pings. The latency spikes across the Trans-Pacific hops (50–187 ms) highlight how distance impacts performance.

Peer feedback reminded me to consider why I limited ping to 5 packets. Using -c 5 gave a quick snapshot without overwhelming data. In practice, running longer tests (like 18–20 packets) helps smooth out anomalies and provides more accurate averages. Both approaches have advantages: short pings are efficient for quick checks, while extended tests reveal more stable trends.

Conclusion

From these results, I concluded that round-trip times generally increase with geographical distance. Google, hosted nearby, responded almost instantly. BBC, despite being overseas, appeared local due to CDN caching. ANU showed the expected latency of international travel, plus the effects of ICMP blocking.

Ping and traceroute are powerful troubleshooting tools. Ping confirms host reachability and stability. Traceroute identifies where delays or failures occur. Both can time out if routers or servers block ICMP traffic, or if congestion/firewalls drop probes. These tools are vital in diagnosing real-world network issues.

Labels: Networking, Ping, Traceroute, Connectivity, IT Tools

Labels:

Comments

Post a Comment