Doing a traceroute from your locating to your hosting provider is something that Vivio Technical Support sometimes asks in order to help identify speed or networking issues. Usually what we do is first perform a traceroute to your location, then we may ask for a traceroute back from your location. Using this method, our technicians can help isolate problem areas in the connection between you and Vivio - this often lets us know who we can contact to help address the problem.

The following article describes how to perform a traceroute from your Linux-based workstation, what that information means, and how you can use that information to identify the cause of most networking issues.

Step-by-step guide - Debian/Ubuntu

In some installs of Debian/Ubuntu, the traceroute tool is not always installed by default, so we have to run the following command in order to install it:

$ sudo apt-get install traceroute

Once you have traceroute installed, you can run a traceroute command simply by typing

$ traceroute [host]

Host can be either an IP Address, like 127.0.0.1, or a domain name, like localhost or google.com. In our example, we'll just use google.com:


$ traceroute google.com

traceroute to google.com (216.58.193.174), 30 hops max, 60 byte packets
1 192.168.254.1 (192.168.254.1) 0.537 ms 0.777 ms 0.759 ms
2 208.77.211.129 (208.77.211.129) 12.604 ms 12.592 ms 12.572 ms
3 pin-206-126-16-161.static.pocketinet.com (206.126.16.161) 12.553 ms 12.533 ms 12.513 ms
4 core01-sea.net.pocketinet.com (206.126.21.9) 13.331 ms 15.410 ms 16.634 ms
5 six.sea01.google.com (206.81.80.17) 16.644 ms 16.929 ms 20.069 ms
6 66.249.94.212 (66.249.94.212) 20.623 ms 13.192 ms 15.240 ms
7 209.85.244.59 (209.85.244.59) 15.472 ms 15.474 ms 16.509 ms
8 sea09s15-in-f14.1e100.net (216.58.193.174) 18.918 ms 18.910 ms 18.902 ms

The above results are my results from the Vivio Internal Network, your results will be different, as you're probably on a different network. We'll talk more about these differences and what they mean further down in the article.


Step-by-step guide - RHEL/CentOS

In some installs of RHEL/CentOS, the traceroute tool is not always installed by default, so we have to run the following command in order to install it:

# yum install traceroute

Once you have traceroute installed, you can run a traceroute command simply by typing

# traceroute [host]

Host can be either an IP Address, like 127.0.0.1, or a domain name, like localhost or google.com. In our example, we'll just use google.com:


# traceroute google.com

traceroute to google.com (216.58.193.174), 30 hops max, 60 byte packets
1 192.168.254.1 (192.168.254.1) 0.537 ms 0.777 ms 0.759 ms
2 208.77.211.129 (208.77.211.129) 12.604 ms 12.592 ms 12.572 ms
3 pin-206-126-16-161.static.pocketinet.com (206.126.16.161) 12.553 ms 12.533 ms 12.513 ms
4 core01-sea.net.pocketinet.com (206.126.21.9) 13.331 ms 15.410 ms 16.634 ms
5 six.sea01.google.com (206.81.80.17) 16.644 ms 16.929 ms 20.069 ms
6 66.249.94.212 (66.249.94.212) 20.623 ms 13.192 ms 15.240 ms
7 209.85.244.59 (209.85.244.59) 15.472 ms 15.474 ms 16.509 ms
8 sea09s15-in-f14.1e100.net (216.58.193.174) 18.918 ms 18.910 ms 18.902 ms

The above results are my results from the Vivio Internal Network, your results will be different, as you're probably on a different network. We'll talk more about these differences and what they mean further down in the article.

But what does it mean?

Okay, so now we have our traceroute, but what does a traceroute actually mean? How does it help us?

Technically put, a traceroute shows all layer 3 hops between where you're initiating your traceroute, and your destination host. In the OSI Model, "Layer 3" refers to the networking layer.

So, looking at our traceroute, let's take a look at the first "hop":

1 192.168.254.1 (192.168.254.1) 0.537 ms 0.777 ms 0.759 ms

In the above, the following are what each section refers to:

  1. Hop Number
    This section displays the number of hops between you and this device. Since this is our first hop, it's number one!
  2. Hostname (will display IP if no hostname found)
    By default, traceroute will attempt to lookup the hostname for each hop. This is because hostnames can sometimes provide additional information, like where the hop is located. Depending on the network, the information found in a hostname isn't always reliable, but since we're dealing with Google and major ISP's here, the information we find in hostnames is probably going to be reliable.
  3. IP Address
    This section will always display the IP Address. IP Addresses are useful because you can find out who owns the IP Address (what network it belongs to) and often you can find where it's located.
  4. Round Trip Time 1
    By default, traceroute will send three additional packets to each hop in order to get the 'round trip times' for that hop. This information is useful as it helps show if there is any latency between you and that hop, which can show you that there's a problem between you and that hop.
  5. Round Trip Time 2
    The second packet sent to get the RTT.
  6. Round Trip Time 3
    The third packet sent to get the RTT.

So, looking again at our traceroute to google, this is what we can see:

  1. 192.168.254.1 - Vivio's internal network firewall
  2. 208.77.211.129 - one of Vivio's public IP's on our routers
  3. pin-206-126-16-161.static.pocketinet.com - looks like we're getting routed through Vivio's PocketInet fiber connection
  4. core01-sea.net.pocketinet.com - Pocket then sends us off to one of their Seattle routers
  5. six.sea01.google.com - we then get passed to Google's Seattle Internet Exchange (SIX) router
  6. 66.249.94.212 - being routed around inside Google's network - guesisng a data center gateway
  7. 209.85.244.59 - another internal Google router - guessing a load balancer
  8. sea09s15-in-f14.1e100.net - finally we hit a server located in seattle - sweet!


That's neat, but how does that info help me?

By looking at the Round Trip Time (RTT) for each hop, if our connection is slow for any reason, you can see where your packets start to get held up. In the world of the Internet, anything slower than about 300ms is considered 'slow'. 1000ms is a standard second, so that means that anything literally slower than one-third of a second is considered slow.

As a general rule, you will see latency at the first hop BEYOND where the problem is. For example, in our traceroute above, if we saw slow responses from 'six.sea01.google.com' and the hops beyond - any responses above 300ms - we would know that the problem was the connection between PocketInet and the Seattle Internet Exchange.

Similarly, If we saw slow responses from everything past 'pin-206-126-16-161.static.pocketinet.com', we would know that there's a problem with Vivio's connection to PocketInet.

Once you know where the problem is, you can know who to contact in order to get the problem addressed.

Happy tracerouting!

Related articles

Related articles appear here based on the labels you select. Click to edit the macro and add or change labels.



Related issues