Traveling Through a Network

 

              Packets of information travel through the Internet by navigating along a path of routers between your computer and the destination sought, such as Google. Like a dot-to-dot exercise, the information “hops” from one router to another along the web to reach its destination, which is the domain name or IP address selected by the user. The entire process is incredibly fast, as evidenced by the fact that the packets’ delivery is measured in milliseconds. By using the command "ping" on ones computer, you can see the path the packets travel to request and deliver the desired information. Here are the results of my ping exercise for Google, a villa resort in France, and Amazon UK (completed on my Windows 10 desktop computer):

 Google:

 

 

• Number of Packets sent: 4
• Number of packets received: 4
• Number of packets lost: 0
• Range of response speeds: Minimum = 16 milliseconds, Maximum = 22 ms, Average = 19 ms

 

Villa Sequoia (lodging options in France):

 

• Number of Packets sent: 4
• Number of packets received: 4
• Number of packets lost: 0
• Range of response speeds: Minimum = 123 milliseconds, Maximum = 132 ms, Average = 125 ms

 

Amazon UK:

 

• Number of Packets sent: 4
• Number of packets received: 4
• Number of packets lost: 0
• Range of response speeds: Minimum = 138 milliseconds, Maximum = 141 ms, Average = 139 ms

 

            The ping from Google was completed very quickly, and the value of the numbers represented in the milliseconds it took for the information to be requested and then sent is the lowest of the three instances. The ping from the villa lodgings in the Lorraine region of France had a higher ping time than Google, as it had to travel to France and back, as opposed to California. The ping that took the longest time was to Amazon UK with about 20 milliseconds longer than it took to ping France. While the difference between the distance from Oklahoma to France compared to London is negligible, Amazon is a site that experiences a vastly higher amount of Internet traffic, which can cause a slight slowdown of the information delivery.

                The command traceroute, in contrast from the ping, shows each step along the way of the dot-to-dot path of the information from my computer to its destination. Here are the traceroute results for the same three domains that I used in the ping exercise:

 Google:

• Number of routers passed through: 10
• Time to hop to new router: Minimum = 5 milliseconds, Maximum = 25 ms, Average = 16 ms
• Number of hops timed out: 0
• Success or failure in delivery: Success

 

Villa Sequoia (lodging options in France):

• Number of routers passed through: 11
• Time to hop to new router: Minimum = 3 milliseconds, Maximum = 132 ms, Average = 157 ms
• Number of hops timed out: 3
• Success or failure in delivery: Success

 

Amazon UK:

• Number of routers passed through: 15
• Time to hop to new router: Minimum = 4 milliseconds, Maximum = 147 ms, Average = 69 ms
• Number of hops timed out: 15
• Success or failure in delivery: Failure

 

 

            The traceroute from my location to California only took 10 hops and there was not a time above 25 milliseconds. Because of the greater distance for the information to travel, the tracert to France had more hop attempts, and once it hopped the Atlantic Ocean, the hop times increased significantly. The hop times when it was still local wasn’t going above 20 milliseconds. When it moved to Canada and then New Jersey, there was a jump to about 60-70 milliseconds. The moment it crossed the Atlantic Ocean, those numbers hit triple digits. Once in France, there were 3 timed out requests, but the information was still delivered in the end. The attempt to tracert to Amazon UK had a different result. While, like France, the packets had to hop overseas, it ended up using all 30 of the preset attempts to get to its end destination and failed. The numbers also jumped in a similar fashion, the further the data traveled, but once it hit London, time out issues arose rather quickly. The amount of not only Internet traffic in such a densely populated area, but also of available routers, skyrockets. Those that are geographically closer to the destination are likely getting a higher priority, as it takes less time for their data to transmit, causing my data to time out and connection to fail. While the traceroute for Amazon UK failed, I still can easily type the domain into a browser and the page will load without any issue.

  

             Ping and traceroute are valuable tools in determining connectivity issues in a network. The ping results show that the machine on the other end, in addition to the routers in between, are on and working properly. You are then given an estimated amount of time that it would take for information to be exchanged between them. Traceroutes will show you how many times the data must hop, and you can more easily pinpoint where a latency issue might occur based on the number of milliseconds it takes to transfer said data. Requests can time out if the IP address you are requesting information from is not online. Another reason a request can time out is if the routers attempting to be used have firewalls, blocking any hops to be made through them, for security purposes.

 

References:

 

Adams, S. (2016, September 27). Traceroute request timed out? Why traceroute is broken. Retrieved July 02, 2020, from https://community.spiceworks.com/networking/articles/2531-traceroute-request-timed-out-why-traceroute-is-broken

Beal. (2018, August 27). The difference between traceroute and ping. Retrieved July 02, 2020, from https://www.webopedia.com/DidYouKnow/Internet/traceroute_ping.asp

Cisco. (2020, March 14). Understanding the ping and traceroute commands. Retrieved July 02, 2020, from https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-software-releases-121-mainline/12778-ping-traceroute.html

Jain, S. (Ed.). (2019, August 12). Difference between ping and traceroute. Retrieved July 02, 2020, from https://www.geeksforgeeks.org/difference-between-ping-and-traceroute/

Mitchell, S. (2019, December 31). How to read a Traceroute, InMotion hosting support center. Retrieved July 02, 2020, from https://www.inmotionhosting.com/support/website/ssh/read-traceroute/