Quantcast
Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Tracepath vs. Traceroute

Registriert
11. September 2010
Beiträge
22.680
Lösungen
10
Reaktionspunkte
70.637
Punkte
1.103
Hallo
Da ich Aussetzer bei meinem Internetanschluss habe, wurde ich, von meinem Provider gebeten, den Befehl
Code:
tracepath -[x] IP
ins Terminal einzu geben.
Nun kommt die Meldung
Code:
tracepath -x IP
bash: tracepath: Kommando nicht gefunden.
Wenn ich hingegen
Code:
traceroute -x IP
eingebe funktioniert es.

Sind die Ergebnisse/Ausgaben beider Befehle identisch?
Ich habe Lubuntu 14.04.

MfG
 
AW: Tracepath vs. Traceroute

Hi,

das ist ein extra Paket unter Linux:

root@trallala ~ > apt-get install iputils-tracepath
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
iputils-tracepath
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 33.1 kB of archives.
After this operation, 119 kB of additional disk space will be used.
Get:1 wheezy/main iputils-tracepath amd64 3:20101006-1+b1 [33.1 kB]
Fetched 33.1 kB in 0s (189 kB/s)
Selecting previously unselected package iputils-tracepath.
(Reading database ... 35620 files and directories currently installed.)
Unpacking iputils-tracepath (from .../iputils-tracepath_3%3a20101006-1+b1_amd64.deb) ...
Processing triggers for man-db ...
Setting up iputils-tracepath (3:20101006-1+b1) ...
root@trallala ~ > tracepath
Usage: tracepath [-n] [-b] [-l <len>] <destination>[/<port>]
root@trallala ~ >

traceroute ist "inklusive" unter Windows und Linux.

Auszug Manpage:

TRACEPATH(8) System Manager's Manual: iputils TRACEPATH(8)

NAME
tracepath, tracepath6 - traces path to a network host discovering MTU
along this path

SYNOPSIS
tracepath [-n] [-b] [-l pktlen] destination [port]

DESCRIPTION
It traces path to destination discovering MTU along this path. It uses
UDP port port or some random port. It is similar to traceroute, only
does not require superuser privileges and has no fancy options.

tracepath6 is good replacement for traceroute6 and classic example of
application of Linux error queues. The situation with IPv4 is worse,
because commercial IP routers do not return enough information in icmp
error messages. Probably, it will change, when they will be updated.
For now it uses Van Jacobson's trick, sweeping a range of UDP ports to
maintain trace history.

OPTIONS
-n Print primarily IP addresses numerically.

-b Print both of host names and IP addresses.

-l Sets the initial packet length to pktlen instead of 65536 for
tracepath or 128000 for tracepath6.

OUTPUT
root@mops:~ # tracepath6 3ffe:2400:0:109::2
1?: [LOCALHOST] pmtu 1500
1: dust.inr.ac.ru 0.411ms
2: dust.inr.ac.ru asymm 1 0.390ms pmtu 1480
2: 3ffe:2400:0:109::2 463.514ms reached
Resume: pmtu 1480 hops 2 back 2

The first column shows TTL of the probe, followed by colon. Usually
value of TTL is obtained from reply from network, but sometimes reply
does not contain necessary information and we have to guess it. In this
case the number is followed by ?.

The second column shows the network hop, which replied to the probe.
It is either address of router or word [LOCALHOST], if the probe was
not sent to the network.

The rest of line shows miscellaneous information about path to the cor-
respinding hetwork hop. As rule it contains value of RTT. Addition-
ally, it can show Path MTU, when it changes. If the path is asymmetric
or the probe finishes before it reach prescribed hop, difference
between number of hops in forward and backward direction is shown fol-
lowing keyword async. This information is not reliable. F.e. the third
line shows asymmetry of 1, it is because the first probe with TTL of 2
was rejected at the first hop due to Path MTU Discovery.

The last line summarizes information about all the path to the destina-
tion, it shows detected Path MTU, amount of hops to the destination and
our guess about amount of hops from the destination to us, which can be
different when the path is asymmetric.

SEE ALSO
traceroute(8), traceroute6(8), ping(8).

Edit:

Hier mal beides auf google.de:

root@trallala ~ > tracepath google.de
1: trallala 0.129ms pmtu 1500
1: trallala.de 0.040ms
1: trallala.de 0.029ms
2: hawk4-vl20-10GE.anc-ffm.routers.as35366.net 7.971ms asymm 3
3: hawk5-10GE.tel-ams.routers.as35366.net 12.022ms asymm 4
4: no reply
5: no reply
6: no reply
7: no reply
^C
root@trallala ~ > traceroute google.de
traceroute to google.de (173.194.112.152), 30 hops max, 60 byte packets
1 trallala.de a.b.c.d) 0.038 ms 0.015 ms 0.016 ms
2 hawk4-vl20-10GE.anc-ffm.routers.as35366.net (85.31.190.5) 4.679 ms 4.776 ms 4.888 ms
3 hawk5-10GE.tel-ams.routers.as35366.net (81.7.0.18) 11.800 ms 11.907 ms 11.893 ms
4 * * *
5 209.85.248.112 (209.85.248.112) 19.350 ms 12.244 ms 209.85.248.92 (209.85.248.92) 12.078 ms
6 209.85.253.249 (209.85.253.249) 14.634 ms 72.14.238.69 (72.14.238.69) 12.424 ms 209.85.253.249 (209.85.253.249) 14.620 ms
7 209.85.241.229 (209.85.241.229) 14.877 ms 209.85.246.41 (209.85.246.41) 12.462 ms 209.85.241.229 (209.85.241.229) 14.924 ms
8 209.85.250.142 (209.85.250.142) 15.030 ms 14.952 ms 209.85.251.247 (209.85.251.247) 14.697 ms
9 72.14.236.223 (72.14.236.223) 15.408 ms 15.071 ms 15.510 ms
10 fra07s31-in-f24.1e100.net (173.194.112.152) 12.318 ms 12.399 ms 12.470 ms
root@trallala ~ >

Mit "trallala" habe ich meine persönlichen Infos rausgenommen.
 
Zuletzt bearbeitet:
AW: Tracepath vs. Traceroute

Danke hat alles geklappt.
Nun warte ich nur noch auf die Aussetzer, die eigentlich seit Tagen da sind. Natürlich heute nicht.

MfG
tracepath -n 8.8.8.8
1: XXXXXXXX 0.518ms pmtu 1500
1: XXXXXXXX 428.898ms
1: XXXXXXXX 4.643ms
2: XXXXXXXX 10.883ms
3: XXXXXXXXX 9.265ms
4: XXXXXXXX 66.929ms
5: XXXXXXXX 14.582ms
6: XXXXXXXX 18.670ms
7: XXXXXXXX 11.385ms
8: XXXXXXXX 11.420ms
9: no reply
10: XXXXXXXXX 860.232ms
11: XXXXXXXXX 23.134ms
12: XXXXXXXXX 36.353ms
13: XXXXXXXXX 29.165ms
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
So sieht es bei mir aus und da läuft es heute gut.
 
Zuletzt bearbeitet:
AW: Tracepath vs. Traceroute

H,

Das ist das "Routing", da sieht man wo es "hakt" inkl. Verbindungszeiten...

Solche Tools sind wichtig!

traceroute sollte aber genügen, vor allem wenn Dir Dein Provider sagt Du mögest ein Log schicken...

Viele Grüße :emoticon-0157-sun:
 
AW: Tracepath vs. Traceroute

Das ist mir klar.
Es ging darum, das am Anfang traceroute ging, tracepath aber nicht. Nun geht es ja, Dank Dir.
Der hat mir auch gesagt, das er ein Monitoring macht. Nur habe ich seit dem keinen einzigen Hänger.

MfG

P.S. Gibt es eine Möglichkeit, tagsüber wenn ich nicht da bin, z.B.
Code:
tracepat -n 8.8.8.8
alle 10min laufen zu lassen?
 
AW: Tracepath vs. Traceroute

Mit einem Cronjob?

Welcher die Ausgabe in eine Datei anhängt.

Sollte so ungefähr aussehen:

Code:
*/10 * * * * tracepath -n 8.8.8.8 >> /temp/tracepath.log

Das führt tracepath alle 10min aus und hängt die Ausgabe hinten an /temp/tracepath.log an.

Gruß
 
Zuletzt bearbeitet:
Zurück
Oben