Throughout my career, I have utilized the commands ping and traceroute (tracert) to troubleshoot numerous issues. Having a reliable and functional network is critical operating in an enterprise or using the Internet from home. Both ping and tracert, are ICMP (Internet Control Message Protocol), which the ability to confirm basic connectivity between networked systems. However, some networks choose to block ICMP for security reasons, which prevent ping and tracert from returning results or functioning at all. When available, or responding completely, ping and tracert response provide visibility into the underlying connectivity, including distance in milliseconds between systems and the number of systems, or routers. For this assignment, I choose to ping and perform tracert on google.com, www.australia.gov.au, and tutanota.com.
Google.com
Google.com
Google.com, as seen in Figures 1 and 4, has widely varying response times from 596ms to 70ms. This could indicate potential issues of latency when accessing google.com from a browser or could show the load-balancing routing packets to different regions. When performing a tracert to google.com, 20 different routers, or other systems were transversed to access google.com. Some of the devices responded exceptionally slowly.
Figure 1 - Traceroute google.com
australia.gov.au
Figure 1 - Traceroute google.com
australia.gov.au
www.australia.gov.au, as seen in Figures 2 and 4, also had a range of response times. After observing this, it could be possible that my ISP, at&t, or other services are caching responses. With the site being in Australia, the ping time should have been consistently at ~250ms. The tracert clearly showed that traffic traveled to Washington, DC, and then New York, before leaving the US. It appears that numerous routers did not respond as the traffic made its way to Australia.
Tutanota.com
Figure 2 - Traceroute www.australia.gov.au
Tutanota.com
tutanota.com, a German email provider focused on user privacy can be seen in Figures 3 and 4. The ping times for tutanota.com were consistently around 575ms, which seems a bit slow for traffic to Europe, but no caching was occurring. The tracert seemed to indicate that the traffic did not leave the at&t backbone, my isp, until getting into Frankfurt. All the devices responded but did not provide any information other than IP addresses.
This was an enjoyable exercise. I don't often run ping and tracert when there is not a technical issue. Baselining these results could be beneficial if problems were to occur in the future.
Figure 3 - Traceroute tutanota.com