traceroute
traceroute gibt die Route der Pakete zum Netzwerkhost aus
Beschreibung
Traceroute ist ein Kommandozeilenwerkzeug, um den Transportweg von IP-Datenpaketen zwischen dem eigenen Rechner und einer ausgewählten Gegenstelle zu ermitteln.
- Dabei wird die Antwortzeit der durchlaufenen Router gemessen.
- In der Praxis kann das Programm genutzt werden, um einerseits das Routing einer Verbindung anzuzeigen und um andererseits den Verursacher von Verzögerungen zu identifizieren.
Traceroute ist ein Computerprogramm, mit dem ermittelt werden kann, über welche IP-Router Datenpakete bis zum abgefragten Ziel-Host vermittelt werden.
Funktionsweise
Traceroute sendet mehrfach IP-Datenpakete vom Typ ICMP Echo Request an den Ziel-Host, beginnend mit einer Time-to-live (TTL) von 1. Der erste Router, der das Datenpaket weiterleiten soll, zählt den Wert der TTL um eins herunter auf 0, woraufhin er es nicht weiterleitet, sondern verwirft.
Dabei sendet er die ICMP-Antwort Typ 11: Time exceeded mit Code 0: Time to live exceeded in transit an den Absender.
- Dieses Datenpaket enthält als Source Address die IP-Adresse des betreffenden Routers.
- Diese Information wird vom Traceroute-Programm zusammen mit der gesamten Übertragungsdauer aufgezeichnet.
Anschließend wiederholt das Programm diesen Schritt mit einer um 1 erhöhten TTL, um auf dieselbe Weise den nächsten Router auf dem Weg durch das Netzwerk zu ermitteln.
- Dies wird solange wiederholt, bis der Ziel-Host oder das vom jeweiligen Traceroute-Programm verwendete Maximum an Hops erreicht wurde.
- Wird der Ziel-Host erreicht, sendet er bei ICMP-basiertem Traceroute die ICMP Antwort Typ 3 ICMP Echo Replies bzw. bei UDP-basiertem Traceroute Destination Unreachable Code 3 Port Unreachable.
Die Sequenz der so gesammelten Adressen kennzeichnet den Weg zum Ziel durch das Netz.
- Der Rückweg ist in der Regel identisch, kann aber bei asymmetrischem Routing anders verlaufen.
- In der Regel werden an jeden Host drei Pakete gesendet.
- Die drei angezeigten Werte in Millisekunden geben die Antwortzeit dieser drei Versuche wieder.
Das Ergebnis von Traceroute zeigt nicht immer den tatsächlichen Weg.
- Es wird beeinflusst von Firewalls, fehlerhaften Implementierungen des IP-Stacks, Network Address Translation, IP-Tunneln oder der Wahl eines anderen Pfades bei Netzwerküberlastung und anderen Faktoren.
Unter Unix existiert auf IPv6-fähigen Systemen neben traceroute in der Regel auch traceroute6.
- Unter Windows ist Traceroute als tracert.exe aufrufbar.
- Daneben gibt es seit Windows 2000 noch pathping das eigentlich zur Überprüfung eines kompletten Netzwerkpfades gedacht ist, sich aber auch als schnellerer Traceroute benutzen lässt.
Der Vorteil von pathping ist, dass es die Pakete nicht nacheinander, sondern gleichzeitig verschickt und dadurch kürzere Wartezeiten entstehen.
- Der Nachteil ist, dass es mit manchen fehlerhaften Netzen nicht zurechtkommt.
- Unter Linux hat mtr eine ähnliche Funktionalität.
Windows-Traceroute sendet standardmäßig ICMP-Pakete, Unix-Traceroute arbeitet mit UDP-Paketen.
- Mit TCP-Paketen arbeiten nur spezielle Programme beispielsweise Tcptraceroute oder LFT (Layer Four Traceroute).
- Alle diese Traceroute-Implementierungen sind jedoch auf die zurückkommenden ICMP-Pakete angewiesen.
- Verschiedene Protokolle und Ports auszuprobieren ist dann sinnvoll, wenn eine Firewall den Traceroute blockiert.
- Insbesondere die Verwendung von UDP ist oft problematisch.
- Manche Unix-Traceroutes lassen sich mit dem Parameter "-I" auf ICMP bzw. mit "-T" auf TCP umstellen.
Installation
Anwendungen
traceroute auf www.google.de
$ traceroute www.google.de traceroute to www.google.de (216.58.210.3), 30 hops max, 60 byte packets 1 172.31.1.1 (172.31.1.1) 0.150 ms 0.122 ms 0.078 ms 2 11016.your-cloud.host (159.69.96.18) 0.194 ms 0.173 ms 0.125 ms 3 * * * 4 spine1.cloud2.fsn1.hetzner.com (213.239.225.41) 0.746 ms 1.021 ms spine2.cloud2.fsn1.hetzner.com (213.239.225.45) 0.807 ms 5 core24.fsn1.hetzner.com (213.239.239.129) 7.971 ms 7.964 ms core23.fsn1.hetzner.com (213.239.239.137) 0.343 ms 6 core0.fra.hetzner.com (213.239.252.41) 5.090 ms core4.fra.hetzner.com (213.239.229.73) 4.925 ms * 7 72.14.218.94 (72.14.218.94) 5.160 ms 72.14.218.176 (72.14.218.176) 4.921 ms 4.954 ms 8 * * 108.170.251.193 (108.170.251.193) 4.879 ms 9 209.85.251.239 (209.85.251.239) 4.968 ms 216.239.47.244 (216.239.47.244) 5.093 ms 108.170.235.250 (108.170.235.250) 5.754 ms 10 fra16s07-in-f3.1e100.net (216.58.210.3) 4.879 ms 4.825 ms 4.799 ms
traceroute auf www.google.de ohne Namensauflösung
$ traceroute -n www.google.de traceroute to www.google.de (172.217.23.163), 30 hops max, 60 byte packets 1 172.31.1.1 0.155 ms 0.114 ms 0.090 ms 2 159.69.96.18 0.156 ms 0.083 ms 0.103 ms 3 * * * 4 213.239.225.45 0.764 ms 0.757 ms 213.239.225.41 0.695 ms 5 213.239.239.137 3.897 ms 213.239.239.125 4.929 ms 213.239.239.137 3.856 ms 6 213.239.203.149 5.041 ms 213.239.252.41 5.679 ms 5.647 ms 7 72.14.218.176 5.207 ms 4.866 ms 72.14.218.94 5.094 ms 8 * 108.170.251.129 5.181 ms * 9 74.125.37.98 5.143 ms 216.239.47.245 5.197 ms 216.239.48.42 5.135 ms 10 172.217.23.163 5.088 ms 108.170.252.83 5.518 ms 172.217.23.163 5.053 ms
Traceroute unter Unix und Linux
$ traceroute wikipedia.de traceroute to wikipedia.de (130.94.122.197), 30 hops max, 40 byte packets 1 fli4l.Netz1 (192.168.0.1) 0.765 ms 0.651 ms 0.497 ms 2 217.5.98.7 (217.5.98.7) 14.499 ms 14.648 ms 21.394 ms 3 217.237.152.46 (217.237.152.46) 14.831 ms 13.655 ms 13.403 ms 4 62.154.14.134 (62.154.14.134) 118.090 ms 119.522 ms 119.665 ms 5 p16-1-0-3.r20.asbnva01.us.bb.verio.net (129.250.9.141) 117.004 ms 117.370 ms 117.073 ms 6 p64-0-0-0.r21.asbnva01.us.bb.verio.net (129.250.2.35) 119.105 ms 119.284 ms 119.206 ms 7 p16-0-1-2.r20.plalca01.us.bb.verio.net (129.250.2.192) 180.035 ms 195.498 ms 178.704 ms 8 p16-1-0-0.r06.plalca01.us.bb.verio.net (129.250.3.81) 177.280 ms 177.263 ms 176.692 ms 9 p4-0-3-0.r00.sndgca01.us.bb.verio.net (129.250.3.10) 194.322 ms 193.477 ms 193.743 ms 10 ge-1-1.a03.sndgca01.us.da.verio.net (129.250.27.84) 192.527 ms 193.003 ms 192.464 ms 11 Pliny.wikipedia.org (130.94.122.197) 192.604 ms 193.875 ms 194.254 ms
Tracert.exe unter Windows (Referenzanbindung Universität Augsburg-T-Online Frankfurt am Main):
C:\> tracert www.t-online.de Routenverfolgung zu www.t-online.de [217.6.164.162] über maximal 30 Abschnitte: 1 <1 ms <1 ms <1 ms 137.250.124.250 2 <1 ms <1 ms <1 ms csc72.Net.Uni-Augsburg.DE [137.250.90.250] 3 <1 ms <1 ms <1 ms ar-augsburg1-ge3-1.x-win.dfn.de [188.1.37.137] 4 3 ms 3 ms 3 ms cr-stuttgart1-po4-2.x-win.dfn.de [188.1.18.126] 5 3 ms 3 ms 3 ms 62.156.138.237 6 6 ms 6 ms 6 ms f-eb1.F.DE.net.DTAG.DE [62.154.17.138] 7 6 ms 6 ms 6 ms rincewind.sfm.t-online.de [62.159.199.6] 8 6 ms 6 ms 6 ms 217.6.167.198 9 7 ms 6 ms 6 ms 217.6.164.162
Ablaufverfolgung beendet.
Pathping unter Windows XP:
C:\qemu>pathping -p 1 -w 1000 -q 1 google.at Routenverfolgung zu google.at [66.249.93.104] über maximal 30 Abschnitte: 0 cerberus [10.10.10.110] 1 10.10.10.254 2 80.123.142.xxx 3 62.47.95.239 4 172.19.89.145 5 195.3.66.142 6 195.3.70.37 7 195.3.70.86 8 de-cix10.net.google.com [80.81.192.108] 9 209.85.249.180 10 209.85.248.182 11 209.85.248.79 12 72.14.233.77 13 66.249.94.46 14 ug-in-f104.google.com [66.249.93.104]
Berechnung der Statistiken dauert ca. 0 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 cerberus [10.10.10.110]
0/ 1 = 0% |
1 2ms 0/ 1 = 0% 0/ 1 = 0% 10.10.10.254
0/ 1 = 0% |
2 5ms 0/ 1 = 0% 0/ 1 = 0% 80.123.142.xxx
0/ 1 = 0% |
3 23ms 0/ 1 = 0% 0/ 1 = 0% 62.47.95.239
0/ 1 = 0% |
4 14ms 0/ 1 = 0% 0/ 1 = 0% 172.19.89.145
0/ 1 = 0% |
5 14ms 0/ 1 = 0% 0/ 1 = 0% 195.3.66.142
0/ 1 = 0% |
6 17ms 0/ 1 = 0% 0/ 1 = 0% 195.3.70.37
0/ 1 = 0% |
7 17ms 0/ 1 = 0% 0/ 1 = 0% 195.3.70.86
0/ 1 = 0% |
8 26ms 0/ 1 = 0% 0/ 1 = 0% de-cix10.net.google.com [80.81.192.108]
0/ 1 = 0% |
9 38ms 0/ 1 = 0% 0/ 1 = 0% 209.85.249.180
0/ 1 = 0% |
10 34ms 0/ 1 = 0% 0/ 1 = 0% 209.85.248.182
0/ 1 = 0% |
11 40ms 0/ 1 = 0% 0/ 1 = 0% 209.85.248.79
0/ 1 = 0% |
12 35ms 0/ 1 = 0% 0/ 1 = 0% 72.14.233.77
0/ 1 = 0% |
13 51ms 0/ 1 = 0% 0/ 1 = 0% 66.249.94.46
0/ 1 = 0% |
14 39ms 0/ 1 = 0% 0/ 1 = 0% ug-in-f104.google.com [66.249.93.104]
Ablaufverfolgung beendet.
Problembehebung
Aufruf
$ traceroute [OPTIONEN] HOSTNAME
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]
Optionen
| Option (Kurzform) | Option (Langform) | Beschreibung |
|---|---|---|
| --help | Zeigt eine kurze Hilfe zu der Bedienung des Programmes. | |
| -4, -6 | Setzt das verwendete Internet Protokoll auf IPv4 bzw. IPv6. Das Programm wählt normalerweise das richtige Protokoll automatisch aus. | |
| -F | --dont-fragment | Packete werden nicht fragmentiert. |
| -I | --icmp | Das ICMP ECHO verwenden. |
| -n | IP-Adressen werden nicht in ihre Domännamen aufgelöst. | |
| -V | --version | Zeigt die benutzte Version des Programmes. |
| -w ANTWORTZEIT | --wait=ANTWORTZEIT | Setzt die Wartezeit für die Antwort auf ein Testpaket auf ANTWORTZEIT in Sekunden. Standardeinstellung ist 5 Sekunden. |
| -z WARTEZEIT | --sendwait=WARTEZEIT | Setzt die Zeit zwischen zwei Testpaketen auf mindestens WARTEZEIT.
|
Argumente
Umgebungsvariablen
Exit-Status
Konfiguration
Dateien
Sicherheit
Dokumentation
RFC
- RFC 1393: Traceroute using an IP Option
- RFC 792: Internet Control Message Protocol (ICMP)
Man-Page
Info-Pages
Siehe auch
- ping
- ping(8)
- ping6(8)
- tcpdump(8)
- netstat(8)
Links
Projekt-Homepage
Weblinks
Manpage
DESCRIPTION
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).
OPTIONS
--help Print help info 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 host name returns both IPv4 and IPv6 addresses, traceroute will use IPv4.
-I, --icmp Use ICMP ECHO for probes
-T, --tcp Use TCP SYN for probes
-d, --debug Enable socket level debugging (when the Linux kernel supports it)
-F, --dont-fragment 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, --first=first_ttl Specifies with what TTL to start. Defaults to 1.
-g gateway, --gateway=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, --interface=interface Specifies the interface through which traceroute should send packets. By default, the interface is selected according to the routing table.
-m max_ttl, --max-hops=max_ttl Specifies the maximum number of hops (max time-to-live value) traceroute will probe. The default is 30.
-N squeries, --sim-queries=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, --port=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 and others specifies just the (constant) destination port to connect. When using the tcptraceroute wrapper, -p specifies the source port.
-t tos, --tos=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 precedence values, you have to be super user. For IPv6, set the Traffic Control value.
-l flow_label, --flowlabel=flow_label Use specified flow_label for IPv6 packets.
-w max[,here,near], --wait=max[,here,near] Determines how long to wait for a response to a probe.
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).
-q nqueries, --queries=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, --source=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, --sendwait=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, --extensions 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, --as-path-lookups Perform AS path lookups in routing registries and print results directly after the corresponding addresses.
-V, --version Print the version and exit.
There are additional options intended for advanced usage (such as alternate trace methods und weitere):
--sport=port Chooses the source port to use. Implies -N 1 -w 5 . Normally source ports (if applicable) are chosen by the system.
--fwmark=mark Set the firewall mark for outgoing packets (since the Linux kernel 2.6.25).
-M method, --module=name 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, --options=options 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, --udp 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, --dccp Use DCCP Requests for probes.
-P protocol, --protocol=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' .
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.
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:
raw Use only raw sockets (the traditional way). This way is tried first by default (for compatibility reasons), then new dgram icmp sockets as fallback.
dgram Use only dgram icmp sockets.
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).
info Print tcp flags of final tcp replies when the target host is reached. Allows to determine whether an application listens the port and other useful things.
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.
dccp
-D 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:
service=num Set DCCP service code to num (default is 1885957735).
raw
-P proto Send raw packet of protocol proto. No protocol-specific headers are used, just IP header only. Implies -N 1 -w 5 . 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.
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). kategorie/Linux/Befehl
TMP
Trace Route
Mit traceroute kann der Weg eine IP-Datagramms ermittelt werden
$ traceroute google.de traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets 1 fritz.box (192.168.100.1)0.450 ms0.593 ms0.743 ms 2 ber1005dihr001.versatel.de (62.214.63.92)12.670 ms12.750 ms12.693 ms 3 62.214.37.245 (62.214.37.245)13.746 ms13.787 ms13.825 ms 4 62.214.37.130 (62.214.37.130)23.674 ms23.716 ms 62.214.37.158 (62.214.37.158)41.595 ms 5 72.14.222.28 (72.14.222.28)22.010 ms22.063 ms 89.246.109.250 (89.246.109.250)29.791 ms 6 108.170.251.145 (108.170.251.145)26.073 ms 108.170.252.18 (108.170.252.18)37.669 ms 108.170.252.19 (108.170.252.19)24.852 ms 7 209.85.245.203 (209.85.245.203)18.491 ms 209.85.242.79 (209.85.242.79)44.834 ms 209.85.244.219 (209.85.244.219)23.396 ms 8 ham02s17-in-f3.1e100.net (172.217.19.67)18.911 ms17.654 ms19.136 ms
Das Programm kann zur Analyse von Netzwerkproblemen genutzt werden
- Nimmt ein Paket den erwarteten Weg, oder kommt es über Umwege dorthin?
- Welche alternativen Wege beschreitet ein Paket beim Ausfall eines Netzknotens?
Es werden die Laufzeiten zwischen den einzelnen Stationen (Hops) ermittelt, so dass überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt
Funktionsweise
Der Absender sendet eine ICMP-Nachricht vom Typ Echo Request an den Zielrechner
- Von besonderer Bedeutung ist hierbei die Lebenszeit der Nachricht von eins (TTL=1)
Die nächste Station auf dem Weg zum Zielrechner vermindert den Wert von TTL um eins, so daß dieser Wert jetzt Null beträgt und die Nachricht daraufhin verworfen wird
- Der Absender wird jedoch über diesen Vorgang informiert und erhält eine ICMP-Nachricht vom Typ time to live exceeded in transit, die auch die IP-Adresse der Zwischenstation enthält
Der Absender verschickt daraufhin erneut ein Echo Request an den Zielrechner - dieses Mal jedoch mit einer TTL von zwei
- Somit erreicht die Nachricht die zweite Zwischenstation auf dem Weg zum Ziel, bevor auch diese verworfen und der Absender benachrichtigt wird
Der Absender versendet nun weitere Nachrichten vom Typ Echo Request - und erhöht jeweils den Wert der Lebenszeit - bis der Zielrechner erreicht wird und eine ICMP-Nachricht vom Typ Echo Reply erhalten wird
Am Ende des Programmablaufs wird von traceroute eine nummerierte Liste erhalten, die die IP-Adressen der durchlaufenen Zwischenstationen und der dazugehörigen Laufzeiten enthält