This was my first experience using a command prompt to ping an traceroute and IP address. I learned a lot and found it interesting to track a packet as it travels through the internet. Even more interesting, the ping and Tracert command have various options to change how the command is ran. The packet travels through the network by a series of hops until it arrives at its destination. Each 'hop' represents a host that the packet travels through before the destination host. I ran a Ping command to three different websites. I was surprised to find out that the website located on Japan servers resulted in the fast round trip time at an average of 9ms. The Google website, as well as the Australian website, took 55ms and 69ms, respectively. No website resulted in any packet loss. While trying to find websites to ping, I noticed that government websites resulted in 100 percent packet loss. I thought something was wrong at first until I choose a different website. I believe this may be due to increased firewall protection or secured servers for government websites.
Tracert was an interesting exercise. Like the Ping exercise, the Japan website resulted in the fastest trace, with only traveling seven hops. This tells me that I am closer, network wise, to the japan servers than Google and the Australian one. I can see how Tracert helps identify internet connectivity issues because it tells you where the packet request timed out. If the packet request timed out at your router, then you know something must be wrong with the router. The same goes for if the packet timed out at your service provider or the website's server. Tracert request timing out may be caused by a firewall somewhere along the way to the host destination. Also, a simple connection problem may be the cause.
Comments
Post a Comment