What does 'ping' and 'traceroute' mean?

The ping utility checks whether a host is alive and reachable or not. This is done by sending an ICMP Echo Request packet to the host, and waiting for an ICMP Echo Reply from the host.

The traceroute utility works in a different way - UDP packets with increasing TTL values are sent to the host, with three packets sent for each TTL value. Each group of packets 'expire' at a succeeding router on the path to the host, making the routers reply with an ICMP Time Exceeded packet, until the host is reached, at which time it replies with an ICMP Port Unreachable packet.

As UDP packets must be sent to a specific port, traceroute sends the first packet to port 33434, and increments the port number for each packet sent. Those increments are done in order to differentiate between the ICMP packets - the ICMP packets include the offending packet's headers, and the port number from those headers tells how far (= how many hops) the packet traveled before expiring. This number was chosen as UDP ports in that neighborhood are probably unused. As those ports might actually be used, a different start number is usually configurable via an appropriate switch.

Microsoft's TRACERT works a little differently - it sends ICMP Echo Request packets, rather then UDP packets, and therefore expects the host to reply with an ICMP Echo Reply packet. The logic behind this change is, by speculation, that UDP is commonly filtered, while ICMP is not, so using ICMP should work most of the time, when UDP might fail.

The catch is that the original ICMP specifications dictated that ICMP errors should not be sent as replies to ICMP packets, so old routers would not respond correctly to Microsoft's TRACERT. The specifications have since been revised so that ICMP errors are not sent as replies to ICMP error packets only, which better solves the problem of errors bouncing back and forth across the net.

Sample output :
traceroute to www.ibm.com (204.146.18.33), 30 hops max, 20 byte packets
1 teg.technion.ac.il (132.68.7.254) 1 ms 1 ms 1 ms
2 tau-smds.man.ac.il (128.139.210.16) 6 ms 5 ms 5 ms
3 128.139.198.129 (128.139.198.129) 9 ms 8 ms 10 ms
4 TAU-shiber.route.ibm.net.il (192.115.73.5) 160 ms 57 ms 43 ms
5 *fe7507.tlv.ibm.net.il (192.116.177.1) 24 ms 15 ms
6 port1br1.pt.uk.ibm.net (152.158.16.1) 266 ms 173 ms 152 ms
7 165.87.220.34 (165.87.220.34) 468 ms 408 ms 422 ms
8 165.87.28.105 (165.87.28.105) 453 ms 446 ms 434 ms
9 colu35-16-br2.oh.us.ibm.net (165.87.35.18) 453 ms
colu35-32-br2.oh.us.ibm.net (165.87.35.34) 514 ms
colu35-16-br2.oh.us.ibm.net (165.87.35.18) 525 ms
10 colu35-64-sf1.oh.us.ibm.net (165.87.35.76) 590 ms 536 ms 489 ms
11 204.146.18.33 (204.146.18.33) 526 ms 465 ms 473 ms

Failure indications are as follows:
'*' No response received [= timeout]
'!H' ICMP Host Unreachable indication received in response to query
'!N' ICMP Net Unreachable indication received in response to query
'!' Response from final destination had TTL set to < 1, usually due to a bug in the TCP/IP stack (code derived from BSD 4.2 & 4.3)
In this case the TTL must be set to twice the number of hops to the destination, making it look twice as far as it really is.

A possible problem is demonstrated in hop 9 in the above example - a single hop is replied by different hosts. This might be caused by either the path being changed while traced or by a router using multipath routing.

Another possible problem is for a single router to appear in two consecutive hops. This is caused by routers forwarding packets with TTL decremented to 0, so instead of generating a TTL exceeded themselves, the next hop routers do so for them, taking their place in the output.

A possible surprise would be to see a router with an address which is, according to RFC1918, reserved to private internets (that is an address from the blocks 10/8, 172.16/12, 192.168/16). This can happen when somebody assigns a reserved (unroutable) address to an internal router, saving himself IP addresses on machines that need not be accessible to the Internet.

Another possible surprise would be that the round trip to one router would be larger (even significantly larger) than the round trip to the next router. This could happen for several reasons - CPU load on the nearer router might be high causing a delay in the generation of the ICMP reply, ICMP error generation might have a low priority on the nearer router, and it's possible the packet that expired on the nearer router took a different and more congested route on either way or met temporary congestion on the same path.