Post #4: Traveling Through a Network

 

Traveling Through a Network Post

When data is sent over the internet, it is broken into small pieces, called packets. Those packets are then labeled with information like the destination and origin, and sent out. From there, things get interesting as the packets may be sent through several different computers on their way, even taking separate routes. While it may be interesting, this is the type of thing that is completely ignored and the end user just sees data after it has been parsed, shipped, routed and rerouted, received, assembled, and interpreted. To see behind the scenes at the packet transfer process, the ping and traceroute commands can be used.

Ping sends a series of packets to a location and then back again. The ping records how long it takes for the round trip. The time frame is so quick that the round trip is measured in milliseconds. I pinged 3 sites starting with Google for a local sample. Then I looked for something around the world, so I pinged the Japanese government’s website (www.japan.go.jp). Then, to see around the world in the other direction, I looked for a site in England, and because England is famous for their Queen (note: this post was originally written prior to the passing of Queen Elizabeth II), I pinged the Queen’s site (www.royal.uk).

All the pings worked and there was no packet—data—loss. What was most interesting to me was that the local ping (Google) was the intermediate time. Based on the average round trip, Japan was the fastest, Google (wherever they are) was the intermediate time, and England was the slowest time. This came as a surprise to me as I expected Japan to be the slowest time due to Japan being the farthest from me. To double-check, I used Google Earth to get some approximate distances. According to Google Earth, Japan is approximately 6,000 miles from Colorado whereas England is approximately 4,500 miles.

Then I used traceroute (tracert since I use a Windows PC) to trace the packet route for the same three websites. The biggest surprise here was how long the packets spent bouncing around Colorado. For instance, the trip to England’s Royal.uk took 12 hops. The first 7 hops were all probably in Colorado. The first line was my local address. Then hops 2 and 3 were Englewood, which is between here and Denver. Next, there were 2 hops in Denver. The next 2 hops were on 1601milehigh which sounds like a Colorado server. So, on 12 hops from here to England the first 7 were all in Colorado.

Next, the packet went to Texas for 3 hops. Texas is much farther away, but compared to England, it is still very close. Hop 11 is just an IP address, so not sure where it is. Finally, hop 12 is the Royal.uk IP address.

Another interesting point was that the journey to Japan had several hops that timed out before the packet found another route that worked. 2 reasons a ping request might time out could be that a server is overworked and the request was answered too slowly. Another possibility is that the server is down, possibly for maintenance.

Traceroute and Ping could be used to troubleshoot by determining where the problem lies. Just today, before beginning work on this assignment I was trying to get on the Bureau of Land Management’s site and could not get it to load. I checked to see if it was my internet connection by loading another website. If I had read this text I could have used Ping to see if their website was up or not. If there was still no response I could have used traceroute to see if the problem was at my end, their end, or somewhere in between.