Installing the package
|
1 2 3 4 5 |
apt-get install traceroute $ traceroute {IP-address} $ traceroute XX.XXX.XXX.xx $ traceroute kutayzorlu.com |
|
1 2 3 4 5 |
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] |
> Windows tracert in linux ?
tracert equivalents to traceroute -I
To run Windows equivalent tracert command,
enter:
|
1 |
$ traceroute -I google.com |
|
1 2 |
$ tracepath {ip-address} $ tracepath kutayzorlu.com |
Disable IP address and host name mapping
Traceroute provides an option through which the mapping of IP addresses with host name (that traceroute tries) is disabled. The option for doing this is ‘-n’ . The following example illustrates this :
|
1 2 3 4 5 6 7 8 9 10 |
$ traceroute google.com -n traceroute to google.com (173.194.36.7), 30 hops max, 60 byte packets 1 220.224.141.129 109.352 ms 109.280 ms 109.248 ms 2 115.255.239.65 131.633 ms 131.598 ms 131.573 ms 3 124.124.251.245 131.554 ms 131.529 ms 131.502 ms 4 115.255.239.45 131.478 ms 131.464 ms 199.741 ms 5 72.14.212.118 199.674 ms 199.637 ms 199.603 ms 6 209.85.241.52 199.578 ms 199.549 ms 209.838 ms 7 209.85.241.187 199.488 ms 177.264 ms 177.196 ms 8 173.194.36.7 177.159 ms 187.463 ms 187.434 ms |
Configure Response Wait Time
The time for which traceroute utility waits after issuing a probe can also be configured. This can be done through ‘-w’ option that it provides. The -w option expects a value which the utility will take as the response time to wait for. In this example, the wait time is 0.1 seconds and the traceroute utility was unable to wait for any response and it printed all the *’s.
|
1 2 3 4 5 6 7 8 9 10 11 |
$ traceroute google.com -w 0.1 traceroute to google.com (74.125.236.101), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * .. 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * |
Configure Number of Queries per Hop
|
1 2 3 4 5 6 7 8 9 10 11 |
$ traceroute google.com -q 5 traceroute to google.com (173.194.36.46), 30 hops max, 60 byte packets 1 220.224.141.129 (220.224.141.129) 91.579 ms 91.497 ms 91.458 ms 91.422 ms 91.385 ms 2 115.255.239.65 (115.255.239.65) 91.356 ms 91.325 ms 98.868 ms 98.848 ms 98.829 ms 3 124.124.251.245 (124.124.251.245) 94.581 ms 107.083 ms 107.044 ms 107.017 ms 106.981 ms 4 115.255.239.45 (115.255.239.45) 106.948 ms 106.918 ms 144.432 ms 144.412 ms 144.392 ms 5 72.14.212.118 (72.14.212.118) 115.565 ms 115.485 ms 115.446 ms 115.408 ms 115.381 ms 6 72.14.232.202 (72.14.232.202) 115.351 ms 87.232 ms 117.157 ms 117.123 ms 117.049 ms 7 209.85.241.189 (209.85.241.189) 126.998 ms 126.973 ms 126.950 ms 126.929 ms 126.912 ms 8 bom04s02-in-f14.1e100.net (173.194.36.46) 126.889 ms 95.526 ms 95.450 ms 95.418 ms 105.392 ms So we see that after configuring the number of probes to 5, the output started showing five round trip times per hop. |
Configure the TTL value to start with
Traceroute utility is flexible enough to accept the TTL value that the user wants to start the utility with. By default its value is 1 which means it starts off with the first router in the path but using the ‘-f’ option (which expects the new value of TTL) a new value of the TTL field can be set. For example, I tried a normal traceroute operation and then tried a traceroute with a different TTL value.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
$ traceroute google.com traceroute to google.com (74.125.236.132), 30 hops max, 60 byte packets 1 220.224.141.129 (220.224.141.129) 89.181 ms 101.540 ms 101.503 ms 2 115.255.239.65 (115.255.239.65) 101.468 ms 101.431 ms 101.324 ms 3 124.124.251.245 (124.124.251.245) 121.373 ms 121.350 ms 158.694 ms 4 115.255.239.45 (115.255.239.45) 101.223 ms 141.135 ms 123.932 ms 5 72.14.212.118 (72.14.212.118) 123.867 ms 123.832 ms 123.802 ms 6 72.14.232.202 (72.14.232.202) 123.773 ms 123.742 ms 587.812 ms 7 216.239.48.179 (216.239.48.179) 587.723 ms 587.681 ms 587.642 ms 8 bom03s02-in-f4.1e100.net (74.125.236.132) 577.548 ms 577.524 ms 587.512 ms $ traceroute google.com -f 8 traceroute to google.com (74.125.236.129), 30 hops max, 60 byte packets 8 bom03s02-in-f1.1e100.net (74.125.236.129) 96.961 ms 96.886 ms 96.849 ms |
Description of Tracert
|
1 2 3 4 5 6 7 8 9 10 |
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. traceroute 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 host name 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 host name. 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 will give 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 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). |
Tracert Options
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 |
Options --help Print help info and exit. -4, -6 Explicitly force IPv4 or IPv6 traceouting. By default, the program will try to resolve the name given, and choose the appropriate protocol automatically. If resolving a host name returns both IPv4 and IPv6 addresses, traceroute will use IPv4. -I Use ICMP ECHO for probes -T Use TCP SYN for probes -d Enable socket level debugging (when the Linux 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. 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. -f first_ttl Specifies with what TTL to start. Defaults to 1. -g gateway Tells traceroute to add an IP source routing option to the outgoing packet that tells the network to route the packet through the specified gateway (most routers have disabled source routing for security reasons). In general, several gateway's is allowed (comma separated). For IPv6, the form of num,addr,addr... is allowed, where num is a route header type (default is type 2). Note the type 0 route header is now deprecated (rfc5095). -i interface Specifies the interface through which traceroute should send packets. By default, the interface is selected according to the routing table. -m max_ttl Specifies the maximum number of hops (max time-to-live value) traceroute will probe. The default is 30. -N squeries Specifies the number of probe packets sent out simultaneously. Sending several probes concurrently can speed up traceroute considerably. The default value is 16. Note that some routers and hosts can use ICMP rate throttling. In such a situation specifying too large number can lead to loss of some responses. -n Do not try to map IP addresses to host names when displaying them. -p port For UDP tracing, specifies the destination port base traceroute will use (the destination port number will be incremented by each probe). For ICMP tracing, specifies the initial icmp sequence value (incremented by each probe too). For TCP specifies just the (constant) destination port to connect. -t tos For IPv4, set the Type of Service (TOS) and Precedence value. Useful values are 16 (low delay) and 8 (high throughput). Note that in order to use some TOS precendence values, you have to be super user. For IPv6, set the Traffic Control value. -w waittime Set the time (in seconds) to wait for a response to a probe (default 5.0 sec). -q nqueries Sets the number of probe packets per hop. The default is 3. -r Bypass the normal routing tables and send directly to a host on an attached network. If the host is not on a directly-attached network, an error is returned. This option can be used to ping a local host through an interface that has no route through it. -s source_addr Chooses an alternative source address. Note that you must select the address of one of the interfaces. By default, the address of the outgoing interface is used. -z sendwait Minimal time interval between probes (default 0). If the value is more than 10, then it specifies a number in milliseconds, else it is a number of seconds (float point values allowed too). Useful when some routers use rate-limit for icmp messages. -e Show ICMP extensions (rfc4884). The general form is CLASS/TYPE: followed by a hexadecimal dump. The MPLS (rfc4950) is shown parsed, in a form: MPLS:L=label,E=exp_use,S=stack_bottom,T=TTL (more objects separated by / ). -A Perform AS path lookups in routing registries and print results directly after the corresponding addresses. -V Print the version and exit. There is a couple of additional options, 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. -M method Use specified method for traceroute operations. Default traditional udp method has name default, icmp (-I) and tcp (-T) have 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 on cmdline). 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). -P protocol Use raw packet of specified protocol for tracerouting. Default protocol is 253 (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 can help 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, or 128 or 255 (which seems a common practice). It is printed as a negate 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 cmdline switches (you can see them after the method name, if present). default 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. icmp -I 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. tcp -T 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: syn,ack,fin,rst,psh,urg,ece,cwr Sets specified tcp flags for probe packet, in any combination. flags=num Sets the flags field in the tcp header exactly to num. ecn Send syn packet with tcp flags ECE and CWR (for Explicit Congestion Notification, rfc3168) sack,timestamps,window_scaling Use the corresponding tcp header option in the outgoing probe packet. sysctl Use current sysctl (/proc/sys/net/*) setting for the tcp header options above and ecn. Always set by default, if nothing else specified. mss=num Use value of num for maxseg tcp header option (when syn). Default options is syn,sysctl. tcpconn 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). udp -U 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. udplite -UL Use udplite datagram for probes (with constant destination port, default 53). This method is allowed for unprivileged users. Options: coverage=num Set udplite send coverage to num. raw -P proto Send raw packet of protocol proto. No protocol-specific headers are used, just IP header only. Implies -N 1. Options: protocol=proto Use IP protocol proto (default 253). Notes 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. 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). |
* Implementation of tracert
Traceroute, by default, sends a sequence of User Datagram Protocol (UDP) packets addressed to a destination host; ICMP Echo Request or TCP SYN packets can also be used.[1] The time-to-live(TTL) value, also known as hop limit, is used in determining the intermediate routers being traversed towards the destination. Routers decrement TTL values of packets by one when routing and discard packets whose TTL value has reached zero, returning the ICMP error message ICMP Time Exceeded.[2] Common default values for TTL are 128 (Windows OS) and 64 (Unix-based OS).
Traceroute works by sending packets with gradually increasing TTL value, starting with TTL value of one. The first router receives the packet, decrements the TTL value and drops the packet because it then has TTL value zero. The router sends an ICMP Time Exceeded message back to the source. The next set of packets are given a TTL value of two, so the first router forwards the packets, but the second router drops them and replies with ICMP Time Exceeded. Proceeding in this way, traceroute uses the returned ICMP Time Exceeded messages to build a list of routers that packets traverse, until the destination is reached and returns an ICMP Echo Reply message.[2]
The timestamp values returned for each router along the path are the delay (latency) values, typically measured in milliseconds for each packet.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
Hop 192.168.1.2 Depth 1 Probe status: unsuccessful Parent: () Return code: Label-switched at stack-depth 1 <b>Sender timestamp:</b> 2008-04-17 09:35:27 EDT 400.88 msec <b> Receiver timestamp:</b> 2008-04-17 09:35:27 EDT 427.87 msec <b> Response time:</b> 26.92 msec MTU: Unknown Multipath type: IP Address Range 1: 127.0.0.64 ~ 127.0.0.127 Label Stack: Label 1 Value 299792 Protocol RSVP-TE |
The sender expects a reply within a specified number of seconds. If a packet is not acknowledged within the expected interval, an asterisk is displayed. The Internet Protocol does not require packets to take the same route towards a particular destination, thus hosts listed might be hosts that other packets have traversed. If the host at hop #N does not reply, the hop is skipped in the output.
On Unix-like operating systems, the traceroute utility uses User Datagram Protocol (UDP) datagrams by default, with destination port numbers ranging from 33434 to 33534. The traceroute utility usually has an option to instead use ICMP Echo Request (type 8) packets, like the Windows tracert utility does, or to use TCP SYN packets.[1][2] If a network has a firewall and operates both Windows and Unix-like systems, more than one protocol must be enabled inbound through the firewall for traceroute to work and receive replies.
Some traceroute implementations use TCP packets, such as tcptraceroute or layer four traceroute. PathPing is a utility introduced with Windows NT that combines ping and traceroute functionality. MTR is an enhanced version of ICMP traceroute available for Unix-like and Windows systems. The various implementations of traceroute all rely on ICMP Time Exceeded (type 11) packets being sent to the source.
The implementations of traceroute shipped with Linux, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, and OS X include an option to use ICMP Echo packets (-I), or any arbitrary protocol (-P) such as UDP, TCP or ICMP. On Linux, tracepath is a utility similar to traceroute, with the primary difference of not requiring superuser privileges.[3]
Cisco’s implementation of traceroute also uses a sequence of UDP datagrams, each with incrementing TTL values, to an invalid port number at the remote host; by default, UDP port 33434 is used. Extended version of this command (known as the extended traceroute command) can change the destination port number used by the UDP probe messages.[4]
Usage
Most implementations include at least options to specify the number of queries to send per hop, time to wait for a response, the hop limit and port to use. Invoking traceroute with no specified options displays the list of available options, while man traceroute presents more details, including the displayed error flags. Simple example on Linux:
|
1 |
<span class="nv">$ </span>traceroute -w <span class="m">3</span> -q <span class="m">1</span> -m <span class="m">16</span> kutayzorlu.com |
In the example above, selected options are to wait for three seconds (instead of five), send out only one query to each hop (instead of three), limit the maximum number of hops to 16 before giving up (instead of 30), with example.com as the final host.
This can help identify incorrect routing table definitions or firewalls that may be blocking ICMP traffic, or high port UDP in Unix ping, to a site. Note that a firewall may permit ICMP packets but not permit packets of other protocols.
Traceroute is also used by penetration testers to gather information about network infrastructure and IP ranges around a given host.
It can also be used when downloading data, and if there are multiple mirrors available for the same piece of data, one can trace each mirror to get a good idea of which mirror would be the fastest to use.
Origins
The traceroute manual page states that the original traceroute program was written by Van Jacobson in 1987 from a suggestion by Steve Deering, with particularly cogent suggestions or fixes from C. Philip Wood, Tim Seaver and Ken Adelman. Also, the inventor of the ping program, Mike Muuss, states on his website that traceroute was written using kernel ICMP support that he had earlier coded to enable raw ICMP sockets when he first wrote the ping program.[5]
References
- ^ Jump up to:a b “traceroute(8) – Linux man page”. linux.die.net. Retrieved 2014-02-26.
- ^ Jump up to:a b c Comer, Douglas (2004). Computer Network and Internets with Internet Applications. Pearson Education, Inc. pp. 360–362. ISBN 0131433512.
- Jump up^ “tracepath(8) – Linux man page”. linux.die.net. Retrieved 2015-06-21.
- Jump up^ “Understanding the Ping and Traceroute Commands”. Cisco IOS Software Releases 12.1 Mainline. cisco.com. 2006-11-29. Retrieved 2013-12-08.
- Jump up^ The Story of the PING Program
- kutayzorlu.com