8.1 Tracing the route

You’ve used ping commands for checking networks, but there are other commands that can be used for diagnostics. A common one is traceroute, and I’ll talk about that now.

First of all, though, I want to say something about the limitations of ping. Some routers on the internet block incoming ping messages. This is particularly true with the gateways to some organisations and businesses.

Pings have been used maliciously by hackers, so this is probably why they are sometimes blocked. Blockages can lead to false conclusions.

For example, where there’s a blockage on pings, you might conclude that because pings fail on that IP address, no IP traffic can get through. But this might not be true. So that’s one possible problem with the ping test.

But leaving aside deliberate blocking, a problem with pinging occurs if you ping a host that is several routers away from you, or several hops away. If the ping times out, you can’t tell where the problem is. The ping might be failing at the destination, or at any of the routers on the way to the destination.

Traceroute is designed to help locate the problem in cases like this. Traceroute works by probing each router along the journey from your computer to the destination device. Each router should respond to the traceroute probe, so you can work out how far towards the destination your probes are getting.

For each hop of the journey, traceroute gives you get a round-trip time, or RTT. Ideally you should get a response from here, then here, and here, and so on. If there’s a router that’s not processing your probes, the responses should stop at the preceding router.

Let’s have a look at this in practice. I’m doing this traceroute test from a Windows machine. The traceroute command takes different forms depending on the device you’re sending it from. On Windows machines the traceroute command is this, which looks like ‘tracert’, but I think you’re supposed to read it as ‘trace rt’, and the ‘rt’ is an abbreviation for route.

On Cisco routing devices, at the command prompt you would enter the command traceroute .

I’m going to direct the traceroute command towards an online timeserver. A timeserver is an online clock that other online devices consult to find the current date and time. Home gateways generally use a timeserver to get the date and time, and computers do too.

So here I am at the command prompt of my Windows computer. I enter tracert and the IP address, which in this case is 128.138.140.44. And we can see that the host with this IP address is in the USA, so we can expect there to be lots of routers between my computer and the destination. I’m doing this at home, so this first line of the responses is from my home gateway. The traceroute command sends three packets to each router, and these are the three round-trip times corresponding to the three packets: 7 milliseconds, 6 milliseconds, and then 3 milliseconds. The second response is from a router with this IP address on one of its interfaces. I assume this router belongs to my internet service provider.

The third response is no response at all. It looks as though this router here is not replying to the command, but the fourth line shows that traffic is nevertheless getting beyond the third router.

The fourth and fifth responses look as though they’re from the same neck of the woods as the second.

You might be wondering why these round-trip times from routers further away are shorter than the round-trip times from the second router. The point here is that the round trip time doesn’t just include the time for the outward trip and the return trip. It also includes the time it takes for the router to get round to sending a response back to me. Response times vary a lot from router to router.

You can get situations like this where a more distant router has received a data packet, forwarded it, and sent a response, while an earlier router still hasn’t got round to responding.

Towards the end here you can see that several routers are located in the University of Colorado, which is where the destination host lives. The final response is from the IP address I typed at the start, so we know the destination was reached via 19 routers.

Something else you might be wondering is how these probes can be directed at particular routers, when the path isn’t known at the start. The answer is that the probes aren’t directed at particular routers. The IP packets used in these probes, like all IP packets, have a ‘time to live (TTL)’. The time to live is specified as the maximum number of hops a packet can do before it is discarded. As each router forwards a packet, it decreases the packet’s time to live by 1, or typically by 1. If the time to live hits zero before the packet arrives at its destination, the packet is discarded.

The first traceroute probe is launched with a time to live of 1. This packet gets only as far as the first router. The second is launched with a time to live of 2, and gets as far as the second router. The third has a time to live of 3, and so on.

As you saw, the traceroute command, by default, has a maximum of 30 hops, so the 19 hops in my example falls comfortably within the limit.

In principle, the traceroute’s round-trip time could be used to show the major causes of latency in a route, on the assumption that the round-trip time indicates the latency of each router. But, as I mentioned earlier, the round-trip time isn’t a reliable indicator of how quickly a router forwards packets, so you have to be very cautious about drawing conclusions about latency from traceroute.

In this video, I’m saying a little more about traceroute, but mainly setting the scene for Part 2 of this session, which looks at the way access to the radio channel is managed in Wi-Fi.

I said at the end of the last video that you had to be cautious about using round-trip times as an indication of latency. All the same, the round-trip times in traceroute can throw up some illuminating surprises, and I want to show you one here.

In this video I’m sending a traceroute command from one computer in my home to another, via the home gateway. I’ll do it twice. The first time, the sending and receiving computers are both wired to the Ethernet ports at the back of the gateway. The second time the computer at the receiving end uses Wi-Fi to communicate with the gateway. The sending computer remains connected by wire to the gateway.

So here’s the result of the first traceroute command, with both computers wired to the gateway. Notice that the traceroute command went to an IP address with this number at the end: 110. Round-trip times are short and consistent. One millisecond each time.

Now let’s look at what happened when the receiving computer used Wi-Fi. It’s the same computer at the receiving end, but its wireless interface and wired interface have different IP addresses – as is usual. This time I sent the traceroute command to this IP address, with a final number of 101. And this is what I got. The huge variation of round trip times is striking.

There could be more than one reason this. For example, on many laptops the wireless interface can go into a low-power mode during idle periods, and coming out of that mode could take some time. But what’s probably also significant is the way Wi-Fi devices regulate access to the radio channel, which can involve relatively long delays. And that’s what I’ll be looking at in Part 2.