TRACEROUTE(1) | Traceroute For Linux | TRACEROUTE(1) |
traceroute - print the route packets trace to network host
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 waittimes] [-z sendwait]
[-UL] [-D]
[-P proto] [--sport=port] [-M method] [-O
mod_options]
[--mtu] [--back]
host [packet_len]
traceroute6 [options]
tcptraceroute [options]
lft [options]
traceroute tracks the route packets taken from an IP network on their way to a given host. It utilizes the IP protocol's time to live (TTL) field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to the host.
traceroute6 is equivalent to traceroute -6
tcptraceroute is equivalent to traceroute -T
lft , the Layer Four Traceroute, performs a TCP traceroute, like traceroute -T , but attempts to provide compatibility with the original such implementation, also called "lft".
The only required parameter is the name or IP address of the destination host . The optional packet_len`gth is the total size of the probing packet (default 60 bytes for IPv4 and 80 for IPv6). The specified size can be ignored in some situations or increased up to a minimal value.
This program 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. We start our probes with a ttl of one and increase by one until we get 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 certain timeout, 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 will give up and exit.
We 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 can not 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, in order to bypass firewalls (to be seen by firewalls just as a start of allowed type of a network session).
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.
Note, that non-fragmented features (like -F or --mtu) work properly since the Linux kernel 2.6.22 only. Before that version, IPv6 was always fragmented, IPv4 could use the once the discovered final mtu only (from the route cache), which can be less than the actual mtu of a device.
There are three (in general) float values separated by a comma (or a slash). Max specifies the maximum time (in seconds, default 5.0) to wait, in any case.
Traditional traceroute implementation always waited whole max seconds for any probe. But if we already have some replies from the same hop, or even from some next hop, we can use the round trip time of such a reply as a hint to determine the actual reasonable amount of time to wait.
The optional here (default 3.0) specifies a factor to multiply the round trip time of an already received response from the same hop. The resulting value is used as a timeout for the probe, instead of (but no more than) max. The optional near (default 10.0) specifies a similar factor for a response from some next hop. (The time of the first found result is used in both cases).
First, we look for the same hop (of the probe which
will be printed first from now). If nothing found, then look for some
next hop. If nothing found, use max. If here and/or
near have zero values, the corresponding computation is skipped.
Here and near are always set to zero if only max is
specified (for compatibility with previous versions).
There are additional options intended for advanced usage (such as alternate trace methods etc.):
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 can help
for one attempt (then it can be cached there as well).
See -F option for more info.
In general, a particular traceroute method may have to be chosen by -M name, but most of the methods have their simple cmdline switches (you can see them after the method name, if present).
The traditional, ancient method of tracerouting. Used by default.
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 is allowed for unprivileged users.
Most usual method for now, which uses icmp echo packets for
probes.
If you can ping(8) the destination host, icmp tracerouting is applicable as
well.
This method may be allowed for unprivileged users since the kernel
3.0 (IPv4, for IPv6 since 3.11), 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.
Options:
Well-known modern method, intended to bypass firewalls.
Uses the constant destination port (default is 80, http).
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 just 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 can not.
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.
There is a couple of options for tcp method:
Default options is syn,sysctl.
An initial implementation of tcp method, simple using connect(2) call, which does full tcp session opening. Not recommended for normal use, because a destination application is always affected (and can be confused).
Use udp datagram with constant destination port (default 53, dns).
Intended to bypass firewall as well.
Note, that unlike in tcp method, the correspond application on the destination host always receive our probes (with random data), and most can easily be confused by them. Most cases it will not respond to our packets though, so we will never see the final hop in the trace. (Fortunately, it seems that at least dns servers replies with something angry).
This method is allowed for unprivileged users.
Use udplite datagram for probes (with constant destination port, default 53).
This method is allowed for unprivileged users.
Options:
Use DCCP Request packets for probes (rfc4340).
This method uses the same "half-open technique" as used for TCP. The default destination port is 33434.
Options:
Send raw packet of protocol proto.
No protocol-specific headers are used, just IP header only.
Implies -N 1 -w 5 .
Options:
To speed up work, normally several probes are sent simultaneously. On the other hand, it 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 of the simultaneous probes, and might even answer only the latest ones. It can lead to extra "looks like expired" hops near the final hop. We use a smart algorithm to auto-detect such a situation, but if it cannot help in your case, just use -N 1 too.
For even greater stability you can slow down the program's work by -z option, for example use -z 0.5 for half-second pause between probes.
To avoid an extra waiting, we use adaptive algorithm for timeouts (see -w option for more info). It can lead to premature expiry (especially when response times differ at times) and printing "*" instead of a time. In such a case, switch this algorithm off, by specifying -w with the desired timeout only (for example, -w 5).
If some hops report nothing for every method, the last chance to obtain something is to use ping -R command (IPv4, and for nearest 8 hops only).
11 October 2006 | Traceroute |