Linux traceroute command
On Unix-like operating systems, the traceroute command prints the route that packets take to a network host.
This page covers the Linux version of traceroute.
Description
The Internet is a large and complex aggregation of network hardware, connected together by gateways. Tracking the route your packets follow (or finding a gateway that’s discarding your packets) can be difficult. The traceroute command utilizes the IP protocol «time to live» field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to some host.
The only mandatory parameter is the destination hostname or IP number. The default probe datagram length is 40 bytes, but this may be increased by specifying a packet size (in bytes) after the destination hostname.
traceroute attempts to trace the route an IP packet would follow to some Internet host by launching probe packets with a small ttl (time to live) then listening for an ICMP «time exceeded» reply from a gateway. It start its probes with a ttl of one and increases this by one until it gets an ICMP «port unreachable» (or TCP reset), which means we got to the «host», or hit a max (which defaults to 30 hops). Three probes (by default) are sent at each ttl setting and a line is printed showing the ttl, address of the gateway and round trip time of each probe. The address can be followed by additional information when requested. If the probe answers come from different gateways, the address of each responding system will be printed. If there is no response within a 5.0 seconds (default), an «*» (asterisk) is printed for that probe.
After the trip time, some additional annotation can be printed: !H, !N, or !P (host, network or protocol unreachable), !S (source route failed), !F (fragmentation needed), !X (communication administratively prohibited), !V (host precedence violation), !C (precedence cutoff in effect), or !num> (ICMP unreachable code num>). If almost all the probes result in some kind of unreachable, traceroute gives up and exit.
You don’t want the destination host to process the UDP probe packets, so the destination port is set to an unlikely value (you can change it with the -p flag). There is no such a problem for ICMP or TCP tracerouting (for TCP we use half-open technique, which prevents our probes to be seen by applications on the destination host).
In the modern network environment the traditional traceroute methods cannot be always applicable, because of widespread use of firewalls. Such firewalls filter the «unlikely» UDP ports, or even ICMP echoes. To solve this, some additional tracerouting methods are implemented (including tcp); see list of available methods below. Such methods try to use particular protocol and source/destination port, to bypass firewalls (to be seen by firewalls as a start of allowed type of a network session).
Syntax
traceroute [-46dFITUnreAV] [-f first_ttl] [-g gate. ] [-i device] [-m max_ttl] [-p port] [-s src_addr] [-q nqueries] [-N squeries] [-t tos] [-l flow_label] [-w waittime] [-z sendwait] [-UL] [-D] [-P proto] [--sport=port] [-M method] [-O mod_options] [--mtu] [--back] host [packet_len]
Options
| —help | Display a help message, and exit. |
| -4, -6 | Explicitly force IPv4 or IPv6 tracerouting. By default, the program will try to resolve the name given, and choose the appropriate protocol automatically. If resolving a hostname returns both IPv4 and IPv6 addresses, traceroute uses IPv4. |
| -I | Use ICMP ECHO for probes. |
| -T | Use TCP SYN for probes. |
| -d | Enable socket level debugging (if the kernel supports it). |
| -F | Do not fragment probe packets. (For IPv4 it also sets DF bit, which tells intermediate routers not to fragment remotely as well). |
Varying the size of the probing packet by the packet_len command-line parameter, you can manually obtain information about the MTU of individual network hops. The —mtu option (see below) tries to do this automatically.
The following options are intended for an advanced usage (another trace methods etc.):
| —sport=port | Chooses the source port to use. Implies -N 1. Normally source ports (if applicable) are chosen by the system. |
| —fwmark=mark | Set the firewall mark for outgoing packets (since Linux kernel 2.6.25). |
| -M method | Use specified method for traceroute operations. Default traditional udp method is called default, and icmp (-I) and tcp (-T) have the names icmp and tcp, respectively. Method-specific options can be passed by -O. Most methods have their simple shortcuts (-I means -M icmp, etc). |
| -O option | Specifies some method-specific option. Several options are separated by comma (or use several -O specifications on the command-line). Each method may have its own specific options, or many not have them at all. To print information about available options, use -O help. |
| -U | Use UDP to particular destination port for tracerouting (instead of increasing the port per each probe). Default port is 53 (dns). |
| -UL | Use UDPLITE for tracerouting (default port is 53). |
| -D | Use DCCP requests for probes. |
| -P protocol | Use raw packet of specified protocol for tracerouting. Default protocol is 253, as per rfc3692. |
| —mtu | Discover MTU along the path being traced. Implies -F -N 1. New mtu is printed once in a form of F=NUM at the first probe of a hop which requires such mtu to be reached. (Actually, the correspond «frag needed» icmp message normally is sent by the previous hop). Note, that some routers might cache once the seen information on a fragmentation. Thus you can receive the final mtu from a closer hop. Try to specify an unusual tos by -t, this helps for one attempt (then it can be cached there as well). See -F option for more info. |
| —back | Print the number of backward hops when it seems different with the forward direction. This number is guessed in assumption that remote hops send reply packets with initial ttl set to either 64, 128 or 255 (which is a common practice). It is printed as a negative value in a form of ‘—NUM‘ . |
List of available methods
In general, a particular traceroute method may have to be chosen by «-M name«, but most of the methods have their simple command-line switches (you can see them after the method name, if present).
Probe packets are udp datagrams with so-called «unlikely» destination ports. The «unlikely» port of the first probe is 33434, then for each next probe it is incremented by one. Since the ports are expected to be unused, the destination host normally returns «icmp unreach port» as a final response. (Nobody knows what happens when some application listens for such ports, though).
This method may be allowed for unprivileged users since the kernel 3.0 (IPv4 only), which supports new dgram icmp (or «ping») sockets. To allow such sockets, sysadmin should provide net/ipv4/ping_group_range sysctl range to match any group of the user.
If some filters are present in the network path, then most probably any «unlikely» udp ports (as for default method) or even icmp echoes (as for icmp) are filtered, and whole tracerouting will stop at such a firewall. To bypass a network filter, we have to use only allowed protocol/port combinations. If we trace for some, say, mailserver, then more likely -T -p 25 can reach it, even when -I cannot.
This method uses well-known «half-open technique», which prevents applications on the destination host from seeing our probes at all. Normally, a tcp syn is sent. For non-listened ports we receive tcp reset, and all is done. For active listening ports we receive tcp syn+ack, but answer by tcp reset (instead of expected tcp ack), this way the remote tcp session is dropped even without the application ever taking notice.
The tcp method may be one of the following:
Note, that unlike in tcp method, the corresponding application on the destination host always receive your probes (with random data), and most can easily be confused by them. In most cases it will not respond to your packets, so you never see the final hop in the trace. (DNS servers usually reply with something angry, however).
Notes
To speed up work, normally several probes are sent simultaneously. The downside is that this creates a «storm of packages», especially in the reply direction. Routers can throttle the rate of icmp responses, and some of replies can be lost. To avoid this, decrease the number of simultaneous probes, or even set it to 1 (like in initial traceroute implementation), i.e., -N 1
The final (target) host can drop some simultaneous probes, and might even answer only the latest ones. It can lead to extra «looks like expired» hops near the final hop. traceroute uses a smart algorithm to auto-detect such a situation, but if it cannot help in your case, use -N 1.
For even greater stability, you can slow down the program’s work with the -z option. For example, use -z 0.5 for a half-second pause between probes.
If some hops report nothing for every method, the last chance to obtain something is to use the ping command with the -R option (IPv4, and for nearest 8 hops only).
Examples
traceroute computerhope.com
Trace the route that packets take between your system and the host named computerhope.com, using the default method (udp datagram, 16 simultaneous probes). The results looks similar to the following output:
traceroute to computerhope.com (166.70.10.23), 30 hops max, 60 byte packets 1 176.221.87.1 (176.221.87.1) 1.474 ms 1.444 ms 1.390 ms 2 f126.broadband2.quicknet.se (92.43.37.126) 10.047 ms 19.868 ms 23.156 ms 3 10.5.12.1 (10.5.12.1) 24.098 ms 24.340 ms 25.311 ms 4 212.247.178.9 (212.247.178.9) 25.777 ms 27.184 ms 27.625 ms 5 vst-ncore-1.bundle-ether1.tele2.net (130.244.39.46) 30.632 ms 31.610 ms 32.194 ms 6 kst5-core-1.bundle-ether6.tele2.net (130.244.71.178) 33.608 ms 15.274 ms 16.449 ms 7 kst5-peer-1.ae0-unit0.tele2.net (130.244.205.125) 252.53 ms 11.169 ms 12.158 ms 8 avk6-peer-1.ae0-unit0.tele2.net (130.244.64.71) 19.661 ms 25.765 ms 26.730 ms 9 peer-as3257.avk6.tele2.net (130.244.200.106) 25.390 ms 24.863 ms xe-5-0-0.nyc30.ip4.tinet.net (89.149.181.109) 23.626 ms 10 fortress-gw.ip4.tinet.net (216.221.158.90) 29.943 ms 31.112 ms 29.002 ms 11 208.116.63.254 (208.116.63.254) 32.102 ms 29.862 ms 29.337 ms
Related commands
netstat — Print information about network connections, routing tables, interface statistics, masquerade connections, and multicast memberships.
ping — Send ICMP ECHO_REQUEST packets to network hosts.