Post #4 - Traveling Through a Network

 

Ping and traceroute are tools I have been using since my first day working in IT, ping in particular is extremely useful to verify the existence or absence of IP communication beyond the local computer or device; ping can fail for the following reasons:

-          The device issuing the ping command does not have an IP assigned via DHCP.

-          The destination device being pinged is not available to respond to ping.

-          A device in the route the ICMP packets are traversing is down or does not have a route to the destination IP.

Traceroute is used when a ping command fails to verify that the ICMP packets can traverse the network to the destination and to check where in the route it is failing. It is also useful when troubleshooting network slowness and route problems; provided that all the routers respond to ICMP, we can better understand where the choke point may reside. Traceroute fails for one of the following reasons:

-          The router in the hop blocks ICMP echo replies.

-          A device in the route is not responding.

In the first case, the traceroute program completes and shows the destination device. In the second case, the traceroute will continue to try all 30 hops and fail to provide the destination reply.

Ping and traceroute to www.google.com

The ping results to google demonstrate that as a company, they have a point of presence in most major cities and geographical areas, given by the low latency of 25 milliseconds on average, as shown in the “Average = 25ms” and highlighted in the ping screenshot.

Since I am using a company-provided laptop, the number of hops shown in the traceroute screenshot is slightly larger than if I were to use a personal computer at home since I have to traverse the company network before going out to the service provider. The number of hops is 10, and only the first and last IP addresses respond; the first is my gateway, and the last is the device hosting the www.google.com webpage.

For security reasons, many service providers block ICMP echo requests, which is the protocol the traceroute utility uses to get information about the routers it traverses, in my case, all the hops in-between show “Request timed out” instead of an IP address, this is because my company’s firewall is blocking that information. Unfortunately, I do not have a personal computer at home that I could use for this activity.

Ping and traceroute to www.japan.go.jp

Since this is the government of Japan’s website located in that country, it is understandable that the latency would be higher than the google numbers. The average latency is 63ms.

Traceroute took 17 hops to reach its destination, which makes sense given the geographical location of the website is reached. As with the case of Google, the company firewall is blocking ICMP echo requests.

Ping and traceroute to www.admin.ch

As expected, the latency to the government of Switzerland’s website is higher than that of google and surprisingly less than that of Japan at an average of 47 milliseconds. It sits between the google and Japan sites, which I was not expecting to be that much different from the Japan website because it is on another continent. I suspect that there is a lot more bandwidth available to continental Europe than to the country of Japan; therefore, the latency is lower.

Traceroute shows 15 hops which is 2 hops less than Japan. Yet, the latency is significantly lower than to Japan, which corroborates my suspicion that the bandwidth to continental Europe is larger than to the county of Japan.

Latency or time

www.google.com – 24ms.

www.japan.go.jp – 62ms.

www.admin.ch – 47ms.

The number of hops

www.google.com – 10 hops.

www.japan.go.jp – 17 hops.

www.admin.ch – 15 hops.