Traveling through a Network

The best way to describe a packet's trip through the network is with some PING commands.

The first address I pinged was Google.com. The ping sent four packets by default, and all four were received with zero lost packets. The response speeds ranged between 21 and 26 milliseconds for an average of 23 milliseconds.

The next address to be pinged was fujigoko.tv in Japan. The ping sent four packets, and all four were received with zero lost packets. The response speeds ranged from 133 to 149 milliseconds, with an average of 139 milliseconds.

The last address to be pinged was worldcam.eu in Europe. Again, the ping sent four packets, and all were received with zero lost packets. The response speeds ranged from 168 to 194 milliseconds, with an average of 175 milliseconds.

Ping is fine, but what route do the packets take to get to the destination? Let's review some TRACERT commands.

I used tracert on google.com. It passed through eight routers. The tracert succeeded end-to-end, and every router responded. The hop times ranged from 1 millisecond for my home internet router to 28 milliseconds for the slowest connection along the path.

Next, I used tracert on fujigoko.tv in Japan. It passed through fifteen routers. The tracert succeeded end-to-end, but some of the routers along the way timed out for the ping. The hop times varied from 1 millisecond for my home router to 176 milliseconds for the slowest connection along the path.

Finally, I used tracert on worldcam.eu in Europe. It passed through nine routers. The tracert succeeded end-to-end, and all routers responded to at least one ping. The hop times varied from 1 millisecond for my home router to 170 milliseconds for the slowest along the path.

Reflection

Using the PING and TRACERT commands was fun and educational. Packets are sent out to the local router, complete with their destination address. My home internet router receives the packet and says basically, "I don't know where that address is, but I know the next step is to go to this router." It forwards the packet as-is except for decreasing the Time To Live (TTL) counter inside the packet by 1. The next router gets the packet and does the same thing, and the packet travels this way until it reaches the router that has a direct connection to the destination address, or the TTL reduces to zero. The final router says, "Hey, I have that address right here," and forwards the packet to the system at the destination address.

The PING and TRACERT results showed that google.com is only eight routers away from my computer. Google.com has servers located in the USA, just like my router. Because of this, the PINGs were quick with low millisecond response times. The results of the server in Japan were longer times because there were fifteen routers between my computer and Japan. Also, the destination is further away across the Pacific. The results from the site in Europe reported the longest times. There were nine routers along the path, and Europe is further away from me than Japan, so this made sense.

In general, the further away a server is, the longer it will take for packets to travel there. Packets are sent with electricity or light, and even though these mediums are fast, they are not instant. Another factor is the number of routers that the packets have to travel through. Each time a packet is processed by a router, time is spent routing.

PING can be used to determine if a server is alive. For example, at my work, I IPL (reboot) our development IBM every week. It takes 15-30 minutes, and I know it has completed the reboot when it responds to a PING. TRACERT can be used to determine why a particular server responds slowly. TRACERT pings each router along the path to a server, and if there is a slow leg of the journey, the router that is slow and all subsequent routers along the path will have long PING times. If all routers PING with low response times, then the troubleshooter will know that the slowdown is probably not due to a slow network, but maybe a slow server or server-side application. While using TRACERT, some of the routers along the way showed '*' for the ping times. It can happen because the router is too busy doing its primary job--routing. It can also be that the router does not respond to PINGs. Some routers and devices are configured to not respond to PING packets. It might be to prevent denial of service attacks. Many computers might PING a certain server endlessly from many spots around the globe, and the router can become so busy that it can't route. Some servers are also set up to not respond to PINGs for security purposes.

Overall, it was a fun and educational experience. It fascinates me that as I sit here, I am sending data all the way to Japan and Europe and getting it back in milliseconds. These little self-contained packets know their source and destination address, and the routers along the way give them directions along their digital journey.