Traveling Through a Network - Using Ping and Traceroute

When you use ping, you are sending a small packet of information to an IP address and requesting a response from the recipient. Essentially, you are testing to see whether that destination is reachable. Traceroute is used to “trace” the route that a packet takes while traveling to another device.

I pinged and tracerouted three websites – google.com, mofa.go.kr (Republic of Korea’s government website), and australia.gov.au (Australia’s government website). You can view the results below! Pings for both Google and the Australian website returned four of four packets. Something that was surprising to me was that the response time was faster for the Australian website than for Google. Google’s response time ranged from 18ms to 28ms with the average being 21ms and the Australian website’s response time ranged from 14ms to 17ms with an average of 15ms. I had assumed that a geographic location further away would result in a slower ping response time. However, I am assuming that the Australian website’s destination is farther from me than Google’s. I am also wondering if perhaps the amount of traffic the website gets could also be a factor; I’m sure that Google has far more traffic and that could have been a factor in the slower response time.

When pinging the Korean website, four packets were also attempted but none were received. When I googled the issue, I came across an IBM forum titled, “Resolving the PING Command Problems,” which suggested that a foreign host can fail to respond due to many situations, such as, the foreign host may not be listening to the network, the foreign host may be inoperative, the host may be slow because of activity, the packet may be too large for the foreign host, or the routing table on the local host may not have an entry for the foreign host (2021).

Ping #1 – google.com

Four packets were sent and four were received. The response time ranged from 18ms to 28ms with the average being 21ms.

Ping #2 – mofa.go.kr (Republic of Korea government website)

Four packets were sent and zero were received. There was no time date due to the 100% loss.

Ping #3 – Australia.gov.au (Australian government website)

Four packets were sent and four were received. The time ranged from 14ms to 17ms with an average of 15ms.

The traceroute for Google had 13 hops, all successful. The traceroute for Australia.gov.au had 11 hops with one hop timing out. Just like the ping for the Korean government website, the traceroute was unsuccessful and ended up timing out. What is helpful about the traceroute, however, is that it shows you exactly where the connectivity issue started. For example, I can tell that the Korean traceroute made it all the way to Seattle, Washington with no issues prior to timing out.

Traceroute #1 – google.com

There were thirteen successful hops taken. The fastest hop was 2ms and the slowest was 53ms.

Traceroute #2 – mofa.go.kr

There were thirty hops attempted. Eight of the hops timed out (all seven of the last hops). The first few hops were relatively quick, but as the number of hops increased, the speed decreased. The first hop ranged from 2 – 8ms and the last hop before timing out ranged from 205 – 261ms.

Traceroute #3 – Australia.gov.au

There were eleven hops attempted and ten were successful. All hops were pretty quick with the range being from 2ms – 29ms.

Resources:

Resolving the ping command problems. IBM.com. (2021, March 1). Retrieved March 19, 2023, from https://www.ibm.com/docs/en/zvm/7.1?topic=node-resolving-ping-command-problems

Vahid, F., & Lysecky, S. (2019). Computing technology for all. zyBooks.