Tracert

Tracert is a low level tool that can be invaluable when diagnosing network problems, it is normally run from a command prompt within Windows, and for the information to be meaningful must be run with no other internet activity being carried out.

To run a tracert from a command prompt type "tracert www.bbc.co.uk" or whatever the site or ip address is that you wish to trace to.

When reading a tracert there are certain things to be aware of, first and most important is that not all routers or web sites respond to icmp traffic and you may see timeouts which do not necessarily indicat a problem. Second is that icmp traffic is generally treated as lowest priority by routers and occasionally abnormally high figures will show up which do not necessarily indicate a problem.

Some sample tracerts and what they mean are shown below.

1 1 ms 1 ms 1 ms 192.168.2.1
2 10 ms 11 ms 9 ms 10.149.79.254
3 10 ms 9 ms 9 ms swan-t2cam1-b-ge910.inet.ntl.com [80.0.254.149]
4 29 ms 10 ms 9 ms swa-t2core-b-ge-wan61.inet.ntl.com [213.105.225.145]
5 12 ms 31 ms 13 ms win-bb-b-so-220-0.inet.ntl.com [62.253.187.241]
6 19 ms 13 ms 15 ms pop-bb-a-so-000-0.inet.ntl.com [62.253.185.201]
7 * * * Request timed out.
8 14 ms 15 ms 14 ms 212.58.239.217
9 19 ms 16 ms 16 ms www22.thdo.bbc.co.uk [212.58.224.122]

Hop 1 is my home network and I would be very concerned if this was showing a response time above 10ms

Hop 2 is the private side of my local UBR, this is the hop that will normally show very high figures if there is too much traffic being fed from my local cable loop. The figure will be higher the further away you are from the UBR and high figures do not necessarily indicate a problem. It is more important that the responses are consistent.
A response of 48 ms 11 ms 83 ms would suggest some issues here.

Hop 3 is the local cam, a big ring road around each headend that routes the traffic to the core.

Hop 4 the core, data is now transferred onto fibre optic cables and transmitted through the service backbone.

Hops 5 and 6 are hops across the ntl backbone - note the bb in the host name, these route the data to the peering point at telehouse.

Hop 7 - This is the interesting one, a repeat of the test reveals that this one is telehouse and first observation would seem to indicate that there is a problem here. (see the same entry in the following example also.)
The router in the first trace appears to drop all packets, and in the second trace appears to drop 33% of packets and to slow the remaining packets down. However this is an example of the low icmp priority and can be seen by looking at Hop 8.

Hop 8 - All traffic reaching hop 8 has to pass through hop 7. The times given for the hop are cumulative through each hop on the trace and the fact that hop 8 shows 100% replies and at low ping times indicates that hop 7 though replying to the traffic very poorly, is actually passing traffic with no problems. Hop 8 is the transfer point from telehouse to the bbc website.

Hop 9 - Final destination. Return times of less than 20ms indicate no problems with this route despite the timeouts on hop 7

Repeat test

1 1 ms 1 ms 1 ms 192.168.2.1
2 39 ms 10 ms 9 ms 10.149.79.254
3 10 ms 10 ms 8 ms swan-t2cam1-b-ge910.inet.ntl.com [80.0.254.149]
4 10 ms 12 ms 10 ms swa-t2core-b-ge-wan61.inet.ntl.com [213.105.225.145]
5 14 ms 12 ms 24 ms win-bb-b-so-220-0.inet.ntl.com [62.253.187.241]
6 15 ms 16 ms 49 ms pop-bb-a-so-000-0.inet.ntl.com [62.253.185.201]
7 43 ms 86 ms * tele-ic-2-so-000-0.inet.ntl.com [62.253.185.86]
8 14 ms 20 ms 14 ms 212.58.239.217
9 16 ms 15 ms 14 ms www22.thdo.bbc.co.uk [212.58.224.122]

OK on this one I am seeing some variation at Hop 2, but hop 3,4,5 are ok suggesting again that the variation on hop 2 should not cause a problem
Hop 7 again looks decidedly dodgy, but again hops 8 and 9 need to be looked at and indicate no problems with data passing though hop 7.

A bad trace from an oversubscribed cable would something like this
(I forced this one by downloading at 980k while running the test)

1 2 ms 1 ms 1 ms 192.168.2.1
2 177 ms 25 ms 12 ms 10.149.79.254
3 218 ms 93 ms 154 ms swan-t2cam1-b-ge910.inet.ntl.com [80.0.254.149]
4 198 ms 215 ms 247 ms swa-t2core-b-ge-wan61.inet.ntl.com [213.105.225.145]
5 256 ms 175 ms 92 ms win-bb-b-so-220-0.inet.ntl.com [62.253.187.241]
6 210 ms 119 ms 59 ms pop-bb-a-so-000-0.inet.ntl.com [62.253.185.201]
7 * * * Request timed out.
8 123 ms 143 ms 142 ms 212.58.239.217
9 157 ms 174 ms 179 ms www15.thdo.bbc.co.uk [212.58.224.115]

OK hop 2 high and variable, but this time note the lag on hop 2 has transferred itself right through the trace and given an average 160ms to the final destination.

This next one would be what I would expect to see where packet loss is involved. I have doctored this as it is very difficult to find a proper example.

1 1 ms 1 ms 1 ms 192.168.2.1
2 39 ms 10 ms 9 ms 10.149.79.254
3 10 ms 10 ms 8 ms swan-t2cam1-b-ge910.inet.ntl.com [80.0.254.149]
4 10 ms * 10 ms swa-t2core-b-ge-wan61.inet.ntl.com [213.105.225.145]
5 * 12 ms * win-bb-b-so-220-0.inet.ntl.com [62.253.187.241]
6 15 ms * 49 ms pop-bb-a-so-000-0.inet.ntl.com [62.253.185.201]
7 43 ms * * tele-ic-2-so-000-0.inet.ntl.com [62.253.185.86]
8 * 20 ms 14 ms 212.58.239.217
9 16 ms * * www22.thdo.bbc.co.uk [212.58.224.122]

Note packet loss here starting at Hop 4 will transfer itself right through the trace as traffic from hop 5 and above needs to pass through the troublesome hop.

My last example is to a site in the USA

Tracing route to www2.microsoft.akadns.net [207.46.250.252]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 192.168.2.1
2 9 ms 9 ms 11 ms 10.149.79.254
3 9 ms 9 ms 10 ms swan-t2cam1-a-ge910.inet.ntl.com [80.0.254.21]
4 9 ms 12 ms 10 ms swan-t2cam1-b-ge11.inet.ntl.com [80.0.255.10]
5 10 ms 11 ms 10 ms swa-t2core-b-ge-wan61.inet.ntl.com [213.105.225.145]
6 13 ms 33 ms 12 ms win-bb-b-so-220-0.inet.ntl.com [62.253.187.241]
7 15 ms 15 ms 43 ms P4-0.BRSBB1.Pop.opentransit.net [193.251.254.145]
8 19 ms 19 ms 19 ms So5-0-0.LONCR1.London.opentransit.net [193.251.243.242]
9 92 ms 91 ms 92 ms P3-0.NYKCR3.New-york.opentransit.net [193.251.243.21]
10 98 ms 111 ms 96 ms P12-0.OAKCR1.Oakhill.opentransit.net [193.251.242.254]
11 97 ms 97 ms 99 ms So4-0-0.ASHBB1.Ashburn.opentransit.net [193.251.248.109]
12 97 ms 120 ms 98 ms 207.46.45.69
13 96 ms 98 ms 100 ms 207.46.46.129
14 97 ms 99 ms 98 ms 207.46.34.25
15 189 ms 191 ms 189 ms 207.46.33.61
16 190 ms 188 ms 188 ms 207.46.36.214
17 195 ms 191 ms 191 ms 207.46.155.13
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.

Points of interest here are hop 9 time jumps from 19 to 90ms, this is entirely normal for traffic crossing the Atlantic. Data travels through cables at the speed of light, and even at this speed there is a huge overhead on data being bounced off a server in USA.
Hop 15 this is New York on the east coast of the USA to Seattle on the West coast, another huge jump is to be expected.
Hop 18 and onwards. This does not indicate a problem with the final destination, merely that the Microsoft servers are blocked to UDP and ICMP traffic. The site responds fine to page requests.