Verwenden des Traceroute-Befehls auf Betriebssystemen

Aktualisiert:16. Oktober 2023
Dokument-ID:22826

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

    Einleitung

    In diesem Dokument wird beschrieben, wie der traceroute Befehl auf verschiedenen Systemen ausgeführt wird.

    Voraussetzungen

    Anforderungen

    Leser dieses Dokuments müssen Grundkenntnisse über eines der folgenden Betriebssysteme haben:

    • Cisco IOS® Software

    • Linux 

    • Microsoft Windows

    Verwendete Komponenten

    Die Informationen in diesem Dokument beziehen sich auf folgende Software- und Hardwareversionen:

    • Cisco Router mit Cisco IOS Software, Version 12

    • PC mit Red Hat Linux

    • PC, auf dem MS Windows läuft 

    Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

    Konventionen

    Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

    Hintergrundinformationen

    traceroute Der Befehl ermöglicht Ihnen, den Pfad zu bestimmen, den ein Paket nimmt, um von einer bestimmten Quelle zu einem Ziel zu gelangen, indem die Sequenz der Hops zurückgegeben wird, die das Paket durchlaufen hat. Dieses Dienstprogramm ist im Lieferumfang des Host-Betriebssystems (z. B. Linux oder Microsoft (MS) Windows) sowie der Cisco IOS-Software enthalten.

    Allgemeiner Betrieb

    Wenn Sie die traceroute ip-address auf einem Quellgerät (z. B. einem Host oder einem Router, der als Host fungiert) sendet er IP-Pakete mit TTL-Werten (Time To Live) an das Ziel, die sich bis zur maximalen angegebenen Hop-Anzahl erhöhen. Standardmäßig ist dies 30. Normalerweise dekrementiert jeder Router im Pfad zum Ziel das TTL-Feld um eine Einheit, während er diese Pakete weiterleitet. Wenn ein Router in der Mitte des Pfads ein Paket mit TTL = 1 findet, antwortet er mit einer ICMP-Meldung an die Quelle. Mit dieser Meldung wird die Quelle informiert, dass das Paket diesen bestimmten Router als Hop durchläuft.

    Es gibt einige Unterschiede zur Implementierung des traceroute Befehls in den verschiedenen Betriebssystemen, die in diesem Dokument beschrieben werden.

    Cisco IOS und Linux

    Die TTL für die anfängliche User Datagram Protocol (UDP)-Datagrammprobe wird auf 1 (oder die minimale TTL) festgelegt, wie vom Benutzer im erweiterten traceroute Befehl angegeben. Der Ziel-UDP-Port der anfänglichen Datagrammsonde ist auf 33434 eingestellt (oder wie in der erweiterten traceroute Befehlsausgabe angegeben). Der erweiterte traceroute Befehl ist eine Variante des normalen traceroute Befehls, mit dem die Standardwerte der vom traceroute Vorgang verwendeten Parameter wie TTL und Zielportnummer geändert werden können. Weitere Informationen zur Verwendung des erweiterten traceroute Befehls finden Sie unter Grundlegendes zu den erweiterten Ping- und Traceroute-Befehlen. Der Quell-UDP-Port der anfänglichen Datagrammsonde ist randomisiert und verfügt über den logischen Operator OR mit 0x8000 (stellt einen minimalen Quell-Port von 0x8000 sicher). Diese Schritte veranschaulichen, was geschieht, wenn das UDP-Datagramm gestartet wird:

    note-icon

    Hinweis: Die Parameter können konfiguriert werden. Dieses Beispiel beginnt mit n = 1 und endet mit n = 3.

    1. Das UDP-Datagramm wird mit TTL = 1, dem Ziel-UDP-Port = 33434 versendet, und der Quellport wird randomisiert.

    2. Der UDP-Zielport wird inkrementiert, der Quell-UDP-Port randomisiert und das zweite Datagramm gesendet.

    3. Schritt 2 wird für bis zu drei Sonden wiederholt (oder so oft, wie in einer erweiterten traceroute Befehlsausgabe angefordert). Für jeden der gesendeten Tests erhalten Sie die Meldung "TTL überschritten", die verwendet wird, um einen schrittweisen Pfad zum Zielhost zu erstellen.

    4. Die TTL wird inkrementiert, und dieser Zyklus wird mit inkrementellen Zielportnummern wiederholt, wenn die ICMP-Meldung über die Zeitüberschreitung eingeht. Sie können auch eine der folgenden Nachrichten erhalten:

      • Eine ICMP-Nachricht vom Typ 3, Code 3 (Ziel nicht erreichbar, Port nicht erreichbar), die anzeigt, dass ein Host erreicht wurde.

      • Ein Host ist nicht erreichbar, ein Netz ist nicht erreichbar, die maximale TTL ist überschritten, oder es wird eine Zeitüberschreitungsmeldung ausgegeben, die besagt, dass die Anfrage erneut gesendet wird.

    Cisco Router senden UDP-Probe-Pakete mit einem zufälligen Quell-Port und einem inkrementellen Ziel-Port (zur Unterscheidung der verschiedenen Tests). Cisco Router senden die ICMP-Nachrichtenzeit, die überschritten wurde, an die Quelle zurück, von der das UDP-/ICMP-Paket empfangen wurde.

    Der Linux traceroute -Befehl ähnelt der Cisco Router-Implementierung. Es wird jedoch ein fester Quellport verwendet. Die Fehlermeldung -n -Option im traceroute Befehl wird verwendet, um eine Anforderung an einen Namensserver zu vermeiden.

    Microsoft Windows

    Der MS Windows-tracertBefehl verwendet ICMP-Echoanforderungs-Datagramme anstelle von UDP-Datagrammen als Tests. ICMP-Echo-Anfragen werden mit inkrementierender TTL gestartet, und es erfolgt derselbe Vorgang, der in Cisco IOS und Linux beschrieben wird. Die Verwendung von ICMP-Echoanforderungs-Datagrammen hat die Bedeutung, dass der endgültige Hop nicht von der Antwort einer ICMP-Meldung abhängt, die vom Zielhost nicht erreichbar ist. Stattdessen wird eine ICMP-Echo-Antwortnachricht verwendet.

    Die Befehlssyntax lautet wie folgt:

    tracert [-d] [-h maximum_hops] [-j computer-list] [-w timeout] target_name

    In dieser Tabelle werden die Befehlsparameter erläutert:

    Parameter Beschreibung
    -d Gibt an, dass Adressen nicht in Computernamen aufgelöst werden sollen.
    -h Maximum_Hops Gibt die maximale Anzahl von Hops für die Suche nach einem Ziel an.
    -j Computerliste Gibt eine lose Quellroute entlang der Computerliste an.
    -w Zeitüberschreitung Wartet die Anzahl der Millisekunden, die durch das Timeout für jede Antwort angegeben wird.
    Zielname Name des Zielcomputers.

    Durchsatzbegrenzung "ICMP Unreachables"

    Die Anzahl der nicht erreichbaren ICMPs pro 500 ms ist auf ein Paket (zum Schutz vor Denial-of-Service (DoS)-Angriffen) in einem Cisco Router begrenzt. Ab Version 12.1 der Cisco IOS Software ist dieser Wert konfigurierbar. Der eingeführte Befehl lautet:

    Router(config)#ip icmp rate-limit unreachable ?
  <1-4294967295>  Once per milliseconds
  DF              code 4, fragmentation needed and DF set

    Diese Einschränkung gilt für die Gesamtrate aller nicht erreichbaren ICMPs, wie diese Ausgabe zeigt. Weitere Informationen finden Sie unter RFC 792.

    type = 3, code 
0 = net unreachable; 
1 = host unreachable; 
2 = protocol unreachable; 
3 = port unreachable; 
4 = fragmentation needed and DF set; 
5 = source route failed.

    Diese Einschränkung wirkt sich nicht auf andere Pakete wie ICMP-Echo-Anfragen oder ICMP-Meldungen zur Zeitüberschreitung aus.

    Beispiele

    Diese Netzwerktopologie wird für die folgenden Beispiele verwendet:

    Network TopologyNetzwerktopologie

    In jedem der drei Beispiele wird ein anderes Gerät A verwendet. Von Gerät A wird der traceroute 10.1.4.2 Befehl an Gerät 7C ausgeführt.

    In jedem der Beispiele debug ip packet detail wird auf Gerät 11A ausgeführt.

    Cisco Router mit Cisco IOS-Software

    Dieses erweiterte traceroute Befehlsbeispiel zeigt die Optionen, die Sie ändern können, wenn Sie einen Befehl von einem Cisco Router aus ausführen traceroute . In diesem Beispiel wird alles standardmäßig belassen:

    rp-10c-2611#traceroute
Protocol [ip]: 
Target IP address: 10.1.4.2 
Source address: 10.1.1.1 
Numeric display [n]: 
Timeout in seconds [3]: 
Probe count [3]: 
Minimum Time to Live [1]: 
Maximum Time to Live [30]: 
Port Number [33434]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Type escape sequence to abort.
Tracing the route to 10.1.4.2

1 10.1.1.2 4 msec 0 msec 4 msec
2 10.1.2.2 4 msec 4 msec 0 msec
3 10.1.3.2 0 msec 0 msec 4 msec
4 10.1.4.2 4 msec * 0 msec 


rp-11a-7204#
*Dec 29 13:13:57.060: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 13:13:57.060: ICMP type=11, code=0
*Dec 29 13:13:57.064: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 13:13:57.064: ICMP type=11, code=0
*Dec 29 13:13:57.064: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 13:13:57.068: ICMP type=11, code=0

    In dieser Debug-Ausgabe sendet Gerät 11A Meldungen über die ICMP-Zeitüberschreitung an die Quelle der Tests (10.1.1.1). Diese ICMP-Meldungen werden als Antwort auf die anfänglichen Tests mit einem TTL=1 ausgegeben. Einrichtung 11A senkt die TTL auf Null und antwortet mit den Nachrichten, die die Zeit überschritten haben.

    note-icon

    Hinweis: Die UDP-Tests werden in dieser Debugausgabe aus zwei Gründen nicht angezeigt:

    • Gerät 11A ist nicht das Ziel der UDP-Tests.

    • Die TTL wird auf Null dekrementiert, und das Paket wird nie geroutet. Daher erkennt das Debugging-Programm das Paket nie.

      *Dec 29 13:13:57.068: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.068: UDP src=40309, dst=33437
*Dec 29 13:13:57.068: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.068: ICMP type=11, code=0
*Dec 29 13:13:57.072: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.072: UDP src=37277, dst=33438
*Dec 29 13:13:57.072: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.072: ICMP type=11, code=0
*Dec 29 13:13:57.076: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.076: UDP src=36884, dst=33439
*Dec 29 13:13:57.076: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.076: ICMP type=11, code=0

    Diese Debug-Ausgabe zeigt den UDP-Prüfpunkt von Quelle 10.1.1.1 an, der an 10.1.4.2 gerichtet ist.

    note-icon

    Hinweis: Bei diesen Tests ist TTL=2 (dies ist beim Debuggen nicht sichtbar). Gerät 11A dekrementiert die TTL auf 1 und leitet die UDP-Pakete an Gerät 7A weiter. Gerät 7A senkt die TTL auf Null und antwortet mit "ICMP time beyond"-Meldungen.

    *Dec 29 13:13:57.080: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.080: UDP src=37479, dst=33440
*Dec 29 13:13:57.080: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.080: ICMP type=11, code=0
*Dec 29 13:13:57.084: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.084: UDP src=40631, dst=33441
*Dec 29 13:13:57.084: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.084: ICMP type=11, code=0
*Dec 29 13:13:57.084: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.088: UDP src=39881, dst=33442
*Dec 29 13:13:57.088: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.088: ICMP type=11, code=0

    Die nächsten drei UDP-Tests werden in dieser Debugausgabe angezeigt. Die TTL für diese Tests ist 3. Gerät 11A dekrementiert die TTL auf 2 und leitet sie an Gerät 7A weiter. Einrichtung 7A dekrementiert die TTL auf 1 und leitet die Pakete weiter an Einrichtung 7B, die die TTL auf Null dekrementiert und mit ICMP-Meldungen antwortet, bei denen die Zeit überschritten wird.

    *Dec 29 13:13:57.088: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.088: UDP src=39217, dst=33443
*Dec 29 13:13:57.092: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.092: ICMP type=3, code=3
*Dec 29 13:13:57.092: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.096: UDP src=34357, dst=33444
*Dec 29 13:14:00.092: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:14:00.092: UDP src=39587, dst=33445
*Dec 29 13:14:00.092: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:14:00.092: ICMP type=3, code=3

    Die letzten drei UDP-Tests werden in dieser Debugausgabe angezeigt. Die ursprüngliche TTL dieser Sonden betrug 4. Die TTL wurde durch die Vorrichtung 11A auf 3 dekrementiert, dann durch die Vorrichtung 7A auf 2 dekrementiert und dann durch die Vorrichtung 7B auf 1 dekrementiert. Gerät 7C antwortet mit Meldungen, dass der ICMP-Port nicht erreichbar ist, da es das Ziel der Tests war.

    note-icon

    Hinweis: Gerät 7C sendet aufgrund der Ratenbegrenzung nur zwei nicht erreichbare ICMP-Ports.

    PC mit Linux

    [root#linux-pc]#traceroute -n 10.1.4.2
traceroute to 10.1.4.2 (10.1.4.2), 30 hops max, 40 byte packets
1. 10.1.1.2 1.140 ms 0.793 ms 0.778 ms
2. 10.1.2.2 2.213 ms 2.105 ms 3.491 ms
1. 10.1.3.2 3.146 ms 2.314 ms 2.347 ms
1. 10.1.4.2 3.579 ms * 2.954 ms 


rp-11a-7204#
*Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0
*Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0
*Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0

    In dieser Debug-Ausgabe sendet Gerät 11A Meldungen über die ICMP-Zeitüberschreitung an die Quelle der Tests (10.1.1.1). Diese ICMP-Meldungen werden als Antwort auf die anfänglichen Tests mit einem TTL=1 ausgegeben. Einrichtung 11A senkt die TTL auf Null und antwortet mit den Nachrichten, die die Zeit überschritten haben.

    Die UDP-Tests werden in dieser Debugausgabe aus zwei Gründen nicht angezeigt:

    1. Gerät 11A ist nicht das Ziel der UDP-Tests.

    2. Die TTL wird auf Null dekrementiert, und das Paket wird nie geroutet. Daher erkennt das Debugging-Programm das Paket nie.



    *Jan 2 07:17:27.894: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.894: UDP src=33302, dst=33438
*Jan 2 07:17:27.898: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.898: ICMP type=11, code=0
*Jan 2 07:17:27.898: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.898: UDP src=33302, dst=33439
*Jan 2 07:17:27.898: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.898: ICMP type=11, code=0
*Jan 2 07:17:27.898: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.898: UDP src=33302, dst=33440
*Jan 2 07:17:27.902: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.902: ICMP type=11, code=0
    note-icon

    Hinweis: In dieser Debug-Ausgabe sehen Sie nun den UDP-Prüfpunkt von Quelle 10.1.1.1, der an 10.1.4.2 gerichtet ist.

    note-icon

    Hinweis: Bei diesen Tests ist TTL=2 (dies ist beim Debuggen nicht sichtbar). Gerät 11A dekrementiert die TTL auf 1 und leitet die UDP-Pakete an Gerät 7A weiter. Gerät 7A senkt die TTL auf Null und antwortet mit "ICMP time beyond"-Meldungen.

    *Jan 2 07:17:27.902: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.902: UDP src=33302, dst=33441
*Jan 2 07:17:27.906: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.906: ICMP type=11, code=0
*Jan 2 07:17:27.906: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.906: UDP src=33302, dst=33442
*Jan 2 07:17:27.910: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.910: ICMP type=11, code=0
*Jan 2 07:17:27.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.910: UDP src=33302, dst=33443
*Jan 2 07:17:27.910: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.910: ICMP type=11, code=0

    Die nächsten drei UDP-Tests werden jetzt in dieser Debugausgabe angezeigt. Die TTL für diese Tests ist 3. Gerät 11A dekrementiert die TTL auf 2 und leitet sie an Gerät 7A weiter. Einrichtung 7A dekrementiert die TTL auf 1 und leitet die Pakete weiter an Einrichtung 7B, die die TTL auf Null dekrementiert und mit ICMP-Meldungen antwortet, bei denen die Zeit überschritten wird.

    *Jan 2 07:17:27.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.910: UDP src=33302, dst=33444
*Jan 2 07:17:27.914: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.914: ICMP type=3, code=3
*Jan 2 07:17:27.914: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.914: UDP src=33302, dst=33445
*Jan 2 07:17:32.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:32.910: UDP src=33302, dst=33446
*Jan 2 07:17:32.914: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:32.914: ICMP type=3, code=3

    Diese Debug-Ausgabe zeigt die letzten drei UDP-Tests an. Die ursprüngliche TTL dieser Sonden betrug 4. Die TTL wurde durch die Vorrichtung 11A auf 3 dekrementiert, dann durch die Vorrichtung 7A auf 2 dekrementiert und dann durch die Vorrichtung 7B auf 1 dekrementiert.

    Das Gerät 7C antwortet dann mit Meldungen, dass der ICMP-Port nicht erreichbar ist, da es das Ziel der Tests war.

    note-icon

    Hinweis: Gerät 7C sendet aufgrund der Ratenbegrenzung nur zwei nicht erreichbare ICMP-Ports.

    PC mit MS Windows

    C:\>tracert 10.1.4.2 

1 <10 ms <10 ms <10 ms 10.1.1.2
1 <10 ms <10 ms <10 ms 10.1.2.2
1 <10 ms <10 ms <10 ms 10.1.3.2
1 <10 ms 10 ms 10 ms 10.1.4.2

Trace complete

rp-11a-7204#
*Dec 29 14:02:22.236: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 78, forward
*Dec 29 14:02:22.236: UDP src=137, dst=137
*Dec 29 14:02:22.240: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:22.240: ICMP type=3, code=3
*Dec 29 14:02:23.732: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 78, forward
*Dec 29 14:02:23.732: UDP src=137, dst=137
*Dec 29 14:02:23.736: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:23.736: ICMP type=3, code=3
*Dec 29 14:02:25.236: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 78, forward
*Dec 29 14:02:25.236: UDP src=137, dst=137
*Dec 29 14:02:25.236: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:25.240: ICMP type=3, code=3
*Dec 29 14:02:26.748: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 14:02:26.748: ICMP type=11, code=0
*Dec 29 14:02:26.752: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 14:02:26.752: ICMP type=11, code=0
*Dec 29 14:02:26.752: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 14:02:26.752: ICMP type=11, code=0

    In dieser Debug-Ausgabe sendet Gerät 11A Meldungen über die ICMP-Zeitüberschreitung an die Quelle der Tests (10.1.1.1). Diese ICMP-Nachrichten reagieren auf die anfänglichen Tests, bei denen es sich um ICMP-Echoanforderungspakete mit einem TTL = 1 handelt. Gerät 11A dekrementiert die TTL auf Null und antwortet mit den ICMP-Meldungen.

    note-icon

    Hinweis: Oben sehen Sie die NETBIOS-Namensanforderungen. Diese Anfragen werden als UDP-Pakete mit Quell- und Ziel-Ports von 137 angesehen. Aus Gründen der Übersichtlichkeit werden die NETBIOS-Pakete aus dem Rest der Debugausgabe entfernt. Sie können die -d Option im Befehl verwenden, um das NETBIOS-Verhalten zu tracert deaktivieren.

    Die ICMP-Tests werden in dieser Debugausgabe aus zwei Gründen nicht angezeigt:

    1. Gerät 11A ist nicht das Ziel der ICMP-Tests.

    2. Die TTL wird auf Null dekrementiert, und das Paket wird nie geroutet. Daher erkennt das Debugging-Programm das Paket nie.


    *Dec 29 14:02:32.256: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:32.256: ICMP type=8, code=0
*Dec 29 14:02:32.260: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:32.260: ICMP type=11, code=0
*Dec 29 14:02:32.260: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:32.260: ICMP type=8, code=0
*Dec 29 14:02:32.260: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:32.260: ICMP type=11, code=0
*Dec 29 14:02:32.264: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:32.264: ICMP type=8, code=0
*Dec 29 14:02:32.264: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:32.264: ICMP type=11, code=0

    In dieser Debugausgabe wird nun der ICMP-Prüfpunkt von Quelle 10.1.1.1 angezeigt, der an 10.1.4.2 gerichtet ist.

    note-icon

    Hinweis: Bei diesen Tests ist TTL=2 (dies ist beim Debuggen nicht sichtbar). Gerät 11A setzt die TTL auf 1 herab und leitet die UDP-Pakete an Gerät 7A weiter. Gerät 7A senkt die TTL auf Null und antwortet mit "ICMP time beyond"-Meldungen.

    *Dec 29 14:02:37.776: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:37.776: ICMP type=8, code=0
*Dec 29 14:02:37.776: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:37.776: ICMP type=11, code=0
*Dec 29 14:02:37.780: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:37.780: ICMP type=8, code=0
*Dec 29 14:02:37.780: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:37.780: ICMP type=11, code=0
*Dec 29 14:02:37.780: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:37.780: ICMP type=8, code=0
*Dec 29 14:02:37.784: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:37.784: ICMP type=11, code=0

    In dieser Debugausgabe werden die nächsten drei ICMP-Tests angezeigt. Die TTL für diese Tests ist 3. Gerät 11A dekrementiert die TTL auf 2 und leitet sie an Gerät 7A weiter. Einrichtung 7A dekrementiert die TTL auf 1 und leitet die Pakete weiter an Einrichtung 7B, die die TTL auf Null dekrementiert und mit ICMP-Meldungen antwortet, bei denen die Zeit überschritten wird.

    *Dec 29 14:02:43.292: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:43.292: ICMP type=8, code=0
*Dec 29 14:02:43.296: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 92, forward
*Dec 29 14:02:43.296: ICMP type=0, code=0
*Dec 29 14:02:43.296: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:43.296: ICMP type=8, code=0
*Dec 29 14:02:43.300: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 92, forward
*Dec 29 14:02:43.300: ICMP type=0, code=0
*Dec 29 14:02:43.300: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:43.300: ICMP type=8, code=0
*Dec 29 14:02:43.304: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 92, forward
*Dec 29 14:02:43.304: ICMP type=0, code=0

    Diese Debug-Ausgabe zeigt die letzten drei ICMP-Tests an. Die ursprüngliche TTL dieser Sonden betrug 4. Die TTL wurde durch die Vorrichtung 11A auf 3 dekrementiert, dann durch die Vorrichtung 7A auf 2 dekrementiert und dann durch die Vorrichtung 7B auf 1 dekrementiert. Das Gerät 7C antwortet dann mit ICMP-Echo-Antwortnachrichten (Typ=0, Code=0), da es das Ziel der Sonden war.

    note-icon

    Hinweis: Die Anzahl der ICMP-Echo-Antwortnachrichten ist nicht begrenzt, da die Nachrichten für den ICMP-Port "unreachable" (nicht erreichbar) dies waren. In diesem Fall werden alle drei ICMP-Echo-Antwortnachrichten gesendet.

    Zusätzliche Hinweise

    Bei Cisco Routern lauten die Codes für eine traceroute Befehlsantwort:

    ! -- success
* -- time out
N -- network unreachable
H -- host unreachable
P -- protocol unreachable
A -- admin denied
Q -- source quench received (congestion)
? -- unknown (any other ICMP message)

    Wenn Sie den traceroute Befehl unter UNIX ausführen, beachten Sie Folgendes:

    • Sie erhalten traceroute: icmp socket: Permission denied Nachrichten.

    • Das traceroute Programm basiert auf dem Network Interface Tap (NIT), um im Netzwerk Snoop zu erstellen. Auf dieses Gerät kann nur über den Root zugegriffen werden. Sie müssen das Programm entweder als root ausführen oder die Benutzer-ID für root festlegen.

    Zusammenfassung

    Dieses Dokument hat gezeigt, wie der traceroute Befehl den Pfad eines Pakets von einer bestimmten Quelle zu einem bestimmten Ziel mithilfe von UDP- und ICMP-Paketen bestimmt. Folgende Arten von ICMP-Meldungen werden in den Ausgängen ausgegeben:

    • Wenn die TTL bei der Übertragung überschritten wird, Typ=11, Code=0, dann wird das Paket vom Transit-Router in allen Fällen zurückgesendet, in denen die TTL der Testpakete abläuft, bevor die Pakete das Ziel erreichen.

    • Wenn der Port nicht erreichbar ist, Typ=3, Code=3, wird das Paket als Antwort auf die UDP-Prüfpakete zurückgesendet, wenn sie das Ziel erreichen (die UDP-Anwendung ist nicht definiert). Diese Pakete sind auf ein Paket pro 500 ms beschränkt. Dies erklärt, warum die Antwort vom Ziel (siehe die Ausgaben für den Cisco Router und Linux) bei den geraden Antworten fehlschlug. Gerät 7C erzeugt keine ICMP-Meldung, und die traceroute -Befehls in jedem Gerät länger als eine Sekunde wartet. Bei MS Windows tracert -Befehls ausgegeben wird, wird die ICMP-Meldung generiert, da der UDP-Port 137 auf einem Cisco Router nicht vorhanden ist.

    • Gibt es ein Echo, Typ=8, Code=0, so wird das Echo-Probe-Paket vom MS Windows PC gesendet.

    • Bei einer Echo-Antwort, Typ=0, Code=0, wird eine Antwort auf das vorherige Paket gesendet, wenn das Ziel erreicht ist. Dies gilt nur für MS Windows tracert aus.

    Zugehörige Informationen

    Revisionsverlauf

    Überarbeitung Veröffentlichungsdatum Kommentare
    2.0
    16-Oct-2023
    Rezertifizierung
    1.0
    11-Apr-2002
    Erstveröffentlichung
    TAC Authored

    Beiträge von Cisco Ingenieuren

    War dieses Dokument hilfreich?

    FeedbackFeedback

    Cisco kontaktieren