Travelling Through the Network

This week's assignment was very illuminating. The intricacies of how packets travel through the internet are not lost on me. At a high level, packets are forwarded from router to router as they inch closer and closer to their ending destination. The results from pinging or tracing the route show that the further a location is physically from the initial location, the longer the packet takes to reach its final destination. However, there are significant differences between the results of pinging the Japanese Yahoo and the Australian websites; the physical distance to Japan is almost 3,000 miles closer than Australia, but the average time to Japan is 253.145ms, whereas it was only 95.284ms to reach Australia. The difference in travel time could result from having two additional hops, heavier traffic, or router issues that could be slowing the travel time. But, in general, packet travel is still limited by physics; even a direct fiber optic connection between me and my destination is limited by the speed of light. Therefore, the larger the distance, the longer the minimum time to travel. Although many factors determine the maximum time, the bare minimum time for a packet to reach its destination is determined by the number of hops, the type of connection between routers, traffic, and physical distance.

Ping and Traceroute

My experience using the ping and traceroute commands may differ from many of the rest of the class. The ping command was built into my Linux distribution, but I was surprised that traceroute was not. I had to install the traceroute command manually, using the apt-get (apt is the package manager on most Ubuntu-based distributions, which Linux Mint is) command. For some reason, if I used the default options Linux provides for traceroute, it resulted in hitting the maximum jumps and timeouts. I decided to do some additional research and found that the "-T" flag would force the traceroute command to use TCP ACK requests, which use the TCP protocol in place of the default UDP protocol (Windows uses ICMP requests, which are a completely different protocol). TCP forces acknowledgment of the packet, whereas UDP is like throwing the packet out but not caring about whether or not it successfully hits the destination (at a basic level).

What Do the Results Mean?

The triple asterisks in the traceroute command indicate a timeout at that particular hop. The timeout in and of itself does not imply an issue; some routers are configured to deny ping / traceroute requests. Sometimes, a firewall configuration may deny traceroute packets or may not send an acknowledgment back to the origin. Other times, traffic congestion or significant issues (such as a router losing power or failing) can cause these timeouts. Still, if the packet reaches its end destination, sometimes those hops can be called "anonymous hops" and do not indicate an actual issue. There are similar reasons for potential errors in pinging. For instance, at my work, we have many firewall rules that completely deny IMCP requests (the default for pinging, generally). The errors do not mean an issue, per se, though if the router were unplugged, we may see a similar result.

Conclusion

To boil down the reasons for using ping versus traceroute, the ping command can determine immediate connectivity issues. If I ping a web server or IP address that fails immediately, I use a traceroute to help me decide where the connection fails. I have used ping many times in my day-to-day life, especially when setting up new Apache Tomcat servers that are experiencing issues. I use traceroute more sparingly, as the connections I typically work with are either direct connections or have only one or two extra hops. I use packet tracing tools more frequently to help determine networking issues, but the preliminary tools of ping and traceroute can help start the conversation, so to speak.

---

Results

Ping

Ping Results for Google

Ping Results for Yahoo in Japan

Ping Results for The Australian

Result Table

Destination	Packets Sent	Packets Received	Packets Lost	Time to Receive
Google (U.S.)	11	11	0	27.5ms
Yahoo (Japan)	11	11	0	253.1ms
The Australian (Australia)	11	11	0	95.3ms

Traceroute

Traceroute Results for Google

Traceroute Results for Yahoo in Japan

Traceroute Results for The Australian

Result Table

Destination	Number of Hops	Average Time per Hop	Did it Fail
Google (U.S.)	22	35.636ms	No
Japan (Yahoo)	22	167.336ms	No
Australia (The Australian)	20	43.960ms	No (One Packet Loss)