Grundlegendes zu den ping- und traceroute-Befehlen
Inhalt
Einleitung
Dieses Dokument veranschaulicht die Verwendung der ping- und traceroute-Befehle.
Voraussetzungen
Anforderungen
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
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
In diesem Dokument wird diese Basiskonfiguration für Beispiele in diesem Artikel verwendet:
Basiskonfiguration von IPs und Routern
Der Befehl „ping“
Der Befehl ping ist eine sehr häufige Methode zur Fehlerbehebung bei der Zugänglichkeit von Geräten. Er verwendet eine Reihe von ICMP-Echomeldungen (Internet Control Message Protocol), um Folgendes zu bestimmen:
-
Ob ein Remote-Host aktiv oder inaktiv ist.
-
Die für die Kommunikation mit dem Host verwendete Round-Trip-Verzögerung.
-
Paketverlust.
Der ping-Befehl sendet zuerst ein Echo-Anfrage-Paket an eine Adresse und wartet dann auf eine Antwort. Der Ping ist nur in folgenden Fällen erfolgreich:
-
Die Echo-Anfrage erreicht das Ziel und
-
das Ziel ist in der Lage, innerhalb einer vorgegebenen Zeit, die als Timeout bezeichnet wird, eine Echo-Antwort an die Quelle zu geben. Der Standardwert für dieses Timeout beträgt bei Cisco Routern zwei Sekunden.
Der TTL-Wert eines Ping-Pakets kann nicht geändert werden.
Dieses nächste Codebeispiel zeigt den Befehl ping, nachdem der Befehl debug ip packet detail aktiviert wurde.
Router1#debug ip packet detail IP packet debugging is on (detailed) Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms Router1# Jan 20 15:54:47.487: IP: s=172.16.12.1 (local), d=172.16.0.12 (Serial0), len 100, sending Jan 20 15:54:47.491: ICMP type=8, code=0 !--- This is the ICMP packet 172.16.12.1 sent to 172.16.0.12.
!--- ICMP type=8 corresponds to the echo message. Jan 20 15:54:47.523: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 100, rcvd 3 Jan 20 15:54:47.527: ICMP type=0, code=0 !--- This is the answer we get from 172.16.0.12. !--- ICMP type=0 corresponds to the echo reply message.
!--- By default, the repeat count is five times, so there will be five
!--- echo requests, and five echo replies.
Mögliche Werte für den ICMP-Typ:
| ICMP-Typ | Literal |
|---|---|
| 0 | echo-reply |
| 3 | destination-unreachable-Code 0 = Netz nicht erreichbar 1 = Host nicht erreichbar 2 = Protokoll nicht erreichbar 3 = Port nicht erreichbar 4 = Fragmentierung erforderlich und DF festgelegt 5 = Quellroute fehlgeschlagen |
| 4 | source-quench |
| 5 | redirect-Code 0 = Weiterleitungs-Datagramme für das Netzwerk 1 = Weiterleitungs-Datagramme für den Host 2 = Weiterleitungs-Datagramme für den Service- und Netzwerk-Typ 3 = Weiterleitungs-Datagramme für den Service- und Host-Typ |
| 6 | alternate-address |
| 8 | echo |
| 9 | router-advertisement |
| 10 | router-solicitation |
| 11 | time-exceeded-Code 0 = Lebensdauer überschritten während der Übertragung 1 = Fragment-Wiederzusammensetzungszeit überschritten |
| 12 | parameter-problem |
| 13 | timestamp-request |
| 14 | timestamp-reply |
| 15 | information-request |
| 16 | information-reply |
| 17 | mask-request |
| 18 | mask-reply |
| 31 | conversion-error |
| 32 | mobile-redirect |
Mögliche Ausgabezeichen der Ping-Funktion
| Zeichen | Beschreibung |
|---|---|
| ! | Jedes Ausrufezeichen steht für den Empfang einer Antwort. |
| . | Jeder Zeitraum gibt an, dass das Zeitlimit für den Netzwerkserver abgelaufen ist, während er auf eine Antwort wartet. |
| U | Eine PDU für Fehler "destination unreachable" (Ziel nicht erreichbar) wurde empfangen. |
| F | Quellüberlastung (Ziel zu ausgelastet). |
| M | Konnte nicht fragmentiert werden. |
| ? | Unbekannter Pakettyp. |
| u. | Paketlebensdauer überschritten. |
Ping nicht möglich
Wenn der Ping an eine IP-Adresse fehlschlägt, könnte es an einer der in diesem Abschnitt aufgeführten Ursachen liegen.
Router-Problem
Hier sind Beispiele für erfolglose Ping-Versuche, mit denen das Problem bestimmt und behoben werden kann. Dieses Beispiel wird mit diesem Diagramm zur Netzwerktopologie dargestellt:
Router-Probleme
Router1# ! interface Serial0 ip address 172.16.12.1 255.255.255.0 no fair-queue clockrate 64000 ! Router2# ! interface Serial0 ip address 10.0.2.23 255.255.255.0 no fair-queue clockrate 64000 ! interface Serial1 ip address 172.16.0.12 255.255.255.0 ! Router3# ! interface Serial0 ip address 172.16.3.34 255.255.255.0 no fair-queue ! interface Serial1 ip address 10.0.3.23 255.255.255.0 ! Router4# ! interface Serial0 ip address 172.16.4.34 255.255.255.0 no fair-queue clockrate 64000 !
Ping-Versuch von Router1 an Router4:
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
Ergebnisse:
Router1#debug ip packet IP packet debugging is on
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: Jan 20 16:00:25.603: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:27.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:29.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:31.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:33.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Success rate is 0 percent (0/5)
Da auf Router1 keine Routing-Protokolle ausgeführt werden, weiß er nicht, wohin sein Paket gesendet werden soll, und sendet die Nachricht "unroutable" (nicht routbar).
Hinzufügen einer statischen Route zu Router1:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Ergebnisse:
Router1#debug ip packet detail IP packet debugging is on (detailed) Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5) Jan 20 16:05:30.659: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:30.663: ICMP type=8, code=0 Jan 20 16:05:30.691: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:05:30.695: ICMP type=3, code=1 Jan 20 16:05:30.699: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:30.703: ICMP type=8, code=0 Jan 20 16:05:32.699: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:32.703: ICMP type=8, code=0 Jan 20 16:05:32.731: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:05:32.735: ICMP type=3, code=1 Jan 20 16:05:32.739: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:32.743: ICMP type=8, code=0
Untersuchen von Fehlern auf Router2:
Router2#debug ip packet detail IP packet debugging is on (detailed) Router2# Jan 20 16:10:41.907: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:41.911: ICMP type=8, code=0 Jan 20 16:10:41.915: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending Jan 20 16:10:41.919: ICMP type=3, code=1 Jan 20 16:10:41.947: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:41.951: ICMP type=8, code=0 Jan 20 16:10:43.943: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:43.947: ICMP type=8, code=0 Jan 20 16:10:43.951: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending Jan 20 16:10:43.955: ICMP type=3, code=1 Jan 20 16:10:43.983: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:43.987: ICMP type=8, code=0 Jan 20 16:10:45.979: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:45.983: ICMP type=8, code=0 Jan 20 16:10:45.987: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending Jan 20 16:10:45.991: ICMP type=3, code=1
Router1 hat seine Pakete korrekt an Router2 gesendet, aber Router2 kann nicht auf die Adresse 172.16.4.34 zugreifen. Router2 sendet die Nachricht "unreachable ICMP" (ICMP nicht erreichbar) an Router1 zurück.
Aktivieren von RIP (Routing Information Protocol) auf Router2 und Router3:
Router2# router rip network 172.16.0.7 network 10.0.7.23 Router3# router rip network 10.0.7.23 network 172.16.0.34
Ergebnisse:
Router1#debug ip packet IP packet debugging is on Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: Jan 20 16:16:13.367: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:15.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:17.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:19.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:21.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Success rate is 0 percent (0/5)
Router1 sendet Pakete an Router4, aber Router4 sendet keine Antwort zurück.
Mögliches Problem auf Router4:
Router4#debug ip packet IP packet debugging is on Router4# Jan 20 16:18:45.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:45.911: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:47.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:47.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:49.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:49.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:51.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:51.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:53.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:53.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable
Router 4 empfängt die ICMP-Pakete und versucht, eine Antwort an 172.16.12.1 zu geben, aber da er keine Route zu diesem Netzwerk hat, schlägt der Versuch fehl.
Hinzufügen einer statischen Route zu Router4:
Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Jetzt können beide Seiten aufeinander zugreifen:
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Schnittstelle ausgefallen
Dies ist eine Situation, in der die Schnittstelle stoppt und nicht mehr funktioniert. In diesem nächsten Beispiel wird versucht, Router4 von Router1 mit einem Ping zu erreichen:
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5)
Da das Routing korrekt ist, muss eine schrittweise Fehlerbehebung durchgeführt werden. Anpingen von Router2:
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Im vorherigen Beispiel besteht das Problem zwischen Router2 und Router3. Eine Möglichkeit ist, dass die serielle Schnittstelle auf Router3 heruntergefahren wurde:
Router3#show ip interface brief Serial0 172.16.3.34 YES manual up up Serial1 10.0.3.23 YES manual administratively down down
Dieses Problem ist einfach zu beheben:
Router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router3(config)#interface serial1 Router3(config-if)#no shutdown Router3(config-if)# Jan 20 16:20:53.900: %LINK-3-UPDOWN: Interface Serial1, changed state to up Jan 20 16:20:53.910: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
Access-list-Befehl
In diesem Szenario darf nur Telnet-Datenverkehr über die Schnittstelle Serial0 zu Router4 gelangen.
Router4(config)# access-list 100 permit tcp any any eq telnet Router4(config)#interface serial0 Router4(config-if)#ip access-group 100 in Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#access-list 100 permit ip host 172.16.12.1 host 172.16.4.34 Router1(config)#access-list 100 permit ip host 172.16.4.34 host 172.16.12.1 Router1(config)#end Router1#debug ip packet 100 IP packet debugging is on Router1#debug ip icmp ICMP packet debugging is on
Senden einer Ping-Nachricht an Router4:
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5) Jan 20 16:34:49.207: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:34:49.287: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:34:49.291: ICMP: dst (172.16.12.1) administratively prohibited unreachable rcv from 172.16.4.34 Jan 20 16:34:49.295: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:34:51.295: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:34:51.367: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:34:51.371: ICMP: dst (172.16.12.1) administratively prohibited unreachable rcv from 172.16.4.34 Jan 20 16:34:51.379: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending
Am Ende eines access-list-Befehls steht immer implizit deny all. Dies bedeutet, dass die ICMP-Pakete, die auf Router4 in die serielle 0-Schnittstelle gelangen, abgelehnt werden, und Router 4 sendet eine ICMP-Meldung "administratively verboad unreachable" (administrativ unerreichbar) an die Quelle des ursprünglichen Pakets, wie in der Debug-Meldung dargestellt. Die Lösung besteht darin, diese Zeile im access-list-Befehl hinzuzufügen:
Router4(config)#access-list 100 permit icmp any any
ARP-Problem (Address Resolution Protocol)
In diesem Szenario ist dies die Ethernet-Verbindung:
ARP-Problem (Address Resolution Protocol)
Router4#ping 172.16.100.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.100.5, timeout is 2 seconds: Jan 20 17:04:05.167: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:05.171: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:07.167: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:07.171: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:09.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:09.183: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:11.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:11.179: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:13.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:13.179: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Success rate is 0 percent (0/5) Router4#
In diesem Beispiel funktioniert der ping-Befehl aufgrund der Meldung "encapsulation failed" (Kapselung fehlgeschlagen) nicht. Dies bedeutet, dass der Router weiß, auf welcher Schnittstelle er das Paket senden muss, aber nicht weiß, wie er es tun soll. In diesem Fall müssen Sie verstehen, wie das Address Resolution Protocol (ARP) funktioniert.
ARP ist ein Protokoll, das verwendet wird, um die Layer-2-Adresse (MAC-Adresse) einer Layer-3-Adresse (IP-Adresse) zuzuordnen. Sie können dies mit dem Befehl show arp überprüfen:
Router4#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.16.100.4 - 0000.0c5d.7a0d ARPA Ethernet0 Internet 172.16.100.7 10 0060.5cf4.a955 ARPA Ethernet0
Kehren Sie zum Problem "encapsulation failed" zurück, aber aktivieren Sie diesmal den Befehl debug arp:
Router4#debug arp
ARP packet debugging is on
Router4#ping 172.16.100.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.100.5, timeout is 2 seconds:
Jan 20 17:19:43.843: IP ARP: creating incomplete entry for IP address: 172.16.100.5
interface Ethernet0
Jan 20 17:19:43.847: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:45.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:47.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:49.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:51.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Success rate is 0 percent (0/5)
Die vorherige Ausgabe zeigt, dass Router4 Pakete überträgt und an die Ethernet-Broadcast-Adresse FFFF.FFFF.FFFF sendet. Hier bedeutet 0000.0000.0000, dass Router4 nach der MAC-Adresse des Ziels 172.16.100.5 sucht. Da er die MAC-Adresse nicht kennt, während das ARP in diesem Beispiel angefordert wird, verwendet er 0000.0000.000 als Platzhalter in den von der Schnittstelle Ethernet0 gesendeten Broadcast-Frames und fragt, welche MAC-Adresse 172.16.100.5 entspricht. Wenn es keine Antwort gibt, wird die MAC-Adresse, die der IP-Adresse in der show arp-Ausgabe entspricht, als unvollständig markiert:
Router4#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.16.100.4 - 0000.0c5d.7a0d ARPA Ethernet0 Internet 172.16.100.5 0 Incomplete ARPA Internet 172.16.100.7 2 0060.5cf4.a955 ARPA Ethernet0
Nach einer vorgegebenen Zeitspanne wird dieser unvollständige Eintrag aus der ARP-Tabelle gelöscht. Solange sich die MAC-Adresse nicht in der ARP-Tabelle befindet, schlägt der Ping aufgrund von "encapsulation failed" fehl.
Verzögerung
Wenn Sie innerhalb von zwei Sekunden keine Antwort vom Remote-Ende erhalten, schlägt der Ping standardmäßig fehl:
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
In Netzwerken mit langsamer Verbindung oder langer Verzögerung reichen zwei Sekunden nicht aus. Sie können diesen Standardwert mit einem erweiterten Ping ändern:
Router1#ping Protocol [ip]: Target IP address: 172.16.0.12 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: 30 Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 30 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1458/2390/6066 ms
Weitere Informationen zum erweiterten ping-Befehl finden Sie unter Grundlegendes zu den erweiterten ping- und traceroute-Befehlen.
Im vorherigen Beispiel war der Ping erfolgreich, als das Timeout erhöht wurde.
Korrigieren der Quelladresse
Dieses Beispiel ist ein gängiges Szenario:
Korrigieren der Quelladresse
Hinzufügen einer LAN-Schnittstelle auf Router1:
Router1(config)#interface ethernet0 Router1(config-if)#ip address 10.0.0.1 255.255.255.0
Von einer Station im LAN aus können Sie Router1 anpingen. Von Router1 können Sie Router2 anpingen. Aber von einer Station im LAN aus können Sie Router2 nicht anpingen.
Von Router1 können Sie Router2 anpingen, da Sie standardmäßig die IP-Adresse der Ausgangsschnittstelle als Quelladresse in Ihrem ICMP-Paket verwenden. Router2 hat keine Informationen zu diesem neuen LAN. Wenn er auf ein Paket aus diesem Netzwerk antworten muss, weiß er nicht, wie er damit umgehen soll.
Router1#debug ip packet IP packet debugging is on
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/9 ms Router1# Jan 20 16:35:54.227: IP: s=172.16.12.1 (local), d=172.16.0.12 (Serial0), len 100, sending Jan 20 16:35:54.259: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 100, rcvd 3
Das vorherige Ausgabebeispiel funktioniert, weil die Quelladresse des gesendeten Pakets 172.16.12.1 lautet. Um ein Paket aus dem LAN zu simulieren, müssen Sie einen erweiterten Ping verwenden:
Router1#ping Protocol [ip]: Target IP address: 172.16.0.12 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 10.0.0.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: Jan 20 16:40:18.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Jan 20 16:40:20.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Jan 20 16:40:22.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Jan 20 16:40:24.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending Jan 20 16:40:26.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Success rate is 0 percent (0/5)
Diesmal lautet die Quelladresse 10.0.0.1 und funktioniert nicht. Pakete werden gesendet, aber keine Antwort empfangen. Um dieses Problem zu beheben, fügen Sie in Router2 eine Route zu 10.0.0.0 hinzu. Die grundlegende Regel ist, dass das Ping-Gerät auch wissen muss, wie die Antwort an die Quelle des Pings gesendet werden muss.
Hohe Anzahl an verworfenen Paketen in Eingangswarteschlangen
Wenn ein Paket den Router erreicht, versucht der Router, es auf der Unterbrechungsebene weiterzuleiten. Wenn keine Übereinstimmung in einer geeigneten Cache-Tabelle gefunden werden kann, wird das Paket in die Eingangswarteschlange der Eingangsschnittstelle gestellt, die verarbeitet werden soll. Einige Pakete werden immer verarbeitet, aber mit der entsprechenden Konfiguration und in stabilen Netzwerken darf die Rate der verarbeiteten Pakete die Eingangswarteschlange niemals überlasten. Wenn die Eingangswarteschlange voll ist, wird das Paket verworfen.
Obwohl die Schnittstelle aktiv ist, können Sie das Gerät aufgrund einer hohen Anzahl von verworfenen Paketen in Eingabewarteschlangen nicht anpingen. Sie können die verworfenen Pakete in Eingangswarteschlangen mit dem Befehl show interface überprüfen.
Router1#show interface Serial0/0/0
Serial0/0/0 is up, line protocol is up
MTU 1500 bytes, BW 1984 Kbit, DLY 20000 usec,
reliability 255/255, txload 69/255, rxload 43/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:02, output 00:00:00, output hang never
Last clearing of "show interface" counters 01:28:49
Input queue: 76/75/5553/0 (size/max/drops/flushes);
Total output drops: 1760
Queueing strategy: Class-based queueing
Output queue: 29/1000/64/1760 (size/max total/threshold/drops)
Conversations 7/129/256 (active/max active/max total)
Reserved Conversations 4/4 (allocated/max allocated)
Available Bandwidth 1289 kilobits/sec
!--- Output supressed
Wie aus der Ausgabe hervorgeht, ist die Anzahl der verworfenen Pakete in Eingangswarteschlangen hoch. Weitere Informationen zur Fehlerbehebung bei verworfenen Paketen in Eingangs- und Ausgangswarteschlangen finden Sie unter Troubleshoot Input Queue Drops and Output Queue Drops (Fehlerbehebung bei verworfenen Paketen in Eingangs- und Ausgangswarteschlangen).
Der Traceroute-Befehl
Der Befehl traceroute wird verwendet, um die Routen zu ermitteln, die Pakete bei der Übertragung an das Ziel tatsächlich nehmen. Das Gerät (z. B. ein Router oder ein PC) sendet eine Sequenz von UDP-Datagrammen (User Datagram Protocol) an eine ungültige Port-Adresse auf dem Remote-Host.
Es werden drei Datagramme mit jeweils einem TTL-Feldwert (Time-To-Live) von 1 gesendet. Der TTL-Wert 1 bewirkt, dass für das Datagramm eine Zeitüberschreitung auftritt, sobald es auf den ersten Router im Pfad trifft. Dieser Router antwortet dann mit einer ICMP-TEM-Nachricht (Time Exceeded Message), die angibt, dass das Datagramm abgelaufen ist.
Weitere drei UDP-Nachrichten werden jetzt gesendet, wobei der TTL-Wert auf 2 festgelegt ist, wodurch der zweite Router ICMP-TEMs zurückgibt. Dieser Prozess wird fortgesetzt, bis die Pakete das andere Ziel tatsächlich erreichen. Da diese Datagramme versuchen, auf einen ungültigen Port auf dem Zielhost zuzugreifen, werden ICMP Port Unreachable-Nachrichten zurückgegeben, die auf einen nicht erreichbaren Port hinweisen. Dieses Ereignis signalisiert dem Traceroute-Programm, dass es abgeschlossen ist.
Der Zweck besteht darin, die Quelle jeder ICMP-TEM-Nachricht aufzuzeichnen, um eine Verfolgung des Pfads zu ermöglichen, den das Paket zum Erreichen des Ziels genommen hat.
Router1#traceroute 172.16.4.34 Type escape sequence to abort. Tracing the route to 172.16.4.34 1 172.16.0.12 4 msec 4 msec 4 msec 2 10.0.3.23 20 msec 16 msec 16 msec 3 172.16.4.34 16 msec * 16 msec Jan 20 16:42:48.611: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.615: UDP src=39911, dst=33434 Jan 20 16:42:48.635: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.639: ICMP type=11, code=0 !--- ICMP Time Exceeded Message from Router2. Jan 20 16:42:48.643: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.647: UDP src=34237, dst=33435 Jan 20 16:42:48.667: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.671: ICMP type=11, code=0 Jan 20 16:42:48.675: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.679: UDP src=33420, dst=33436 Jan 20 16:42:48.699: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.703: ICMP type=11, code=0
Dies ist die erste Folge von Paketen, die mit TTL=1 gesendet wird. Der erste Router, in diesem Fall Router2 (172.16.0.12), verwirft das Paket und sendet eine ICMP-Nachricht des Typs 11 an die Quelle (172.16.12.1). Dies entspricht der Meldung "Time Exceeded" (Zeitüberschreitung).
Jan 20 16:42:48.707: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.711: UDP src=35734, dst=33437 Jan 20 16:42:48.743: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.747: ICMP type=11, code=0 !--- ICMP Time Exceeded Message from Router3. Jan 20 16:42:48.751: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.755: UDP src=36753, dst=33438 Jan 20 16:42:48.787: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.791: ICMP type=11, code=0 Jan 20 16:42:48.795: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.799: UDP src=36561, dst=33439 Jan 20 16:42:48.827: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.831: ICMP type=11, code=0
Derselbe Prozess läuft für Router3 (10.0.3.23) mit einer TTL=2 ab:
Jan 20 16:42:48.839: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
sending
Jan 20 16:42:48.843: UDP src=34327, dst=33440
Jan 20 16:42:48.887: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.891: ICMP type=3, code=3
!--- Port Unreachable message from Router4.
Jan 20 16:42:48.895: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
sending
Jan 20 16:42:48.899: UDP src=37534, dst=33441
Jan 20 16:42:51.895: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
sending
Jan 20 16:42:51.899: UDP src=37181, dst=33442
Jan 20 16:42:51.943: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:51.947: ICMP type=3, code=3
Mit einer TTL=3 wird Router4 schließlich erreicht. Diesmal sendet Router4 Router1 eine ICMP-Nachricht vom Typ 3, eine Destination Unreachable-Nachricht, und Code 3, der bedeutet, dass der Port nicht erreichbar ist, da der Port ungültig ist.
In der nächsten Tabelle sind die Zeichen aufgeführt, die in der Ausgabe des Befehls traceroute angezeigt werden können.
IP-Traceroute-Textzeichen
| Zeichen | Beschreibung |
|---|---|
| nn ms | Für jeden Knoten die Round-Trip-Zeit in Millisekunden für die angegebene Anzahl von Probes |
| * | Bei der Probe ist eine Zeitüberschreitung aufgetreten |
| A | Administrativ verboten (Beispiel: access-list) |
| F | Quellüberlastung (Ziel zu ausgelastet). |
| I | Benutzerseitig unterbrochener Test |
| U | Port nicht erreichbar |
| H | Host nicht erreichbar |
| N | Netzwerk nicht erreichbar |
| F | Protokoll nicht erreichbar |
| T | Zeitüberschreitung |
| ? | Unbekannter Pakettyp |
Leistung
Sie können die Round-Trip-Zeit (RTT) mit den Befehlen ping und traceroute ermitteln. Dies ist die Zeit, die benötigt wird, um ein Echo-Paket zu senden und eine Antwort zu erhalten. Dies kann eine ungefähre Vorstellung von der Verzögerung auf der Verbindung geben. Diese Zahlen sind jedoch nicht genau genug, um für die Leistungsbewertung verwendet zu werden.
Wenn ein Paketziel der Router selbst ist, muss dieses Paket per Process-Switching verarbeitet werden. Der Prozessor muss die Informationen aus diesem Paket verarbeiten und eine Antwort zurücksenden. Dies ist nicht das Hauptziel eines Routers. Definitionsgemäß wird ein Router zum Routen von Paketen erstellt. Ein beantworteter Ping wird als Best-Effort-Service angeboten.
Zur Veranschaulichung ein Beispiel für einen Ping von Router1 zu Router2:
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Die RTT beträgt etwa vier Millisekunden. Nachdem Sie einige process-intensive-Funktionen auf Router2 aktiviert haben, versuchen Sie, Router2 über Router1 zu pingen.
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms
Die RTT ist hier enorm angestiegen. Router2 ist ziemlich ausgelastet, und die Priorität besteht nicht darin, den Ping zu beantworten. Eine bessere Möglichkeit, die Routerleistung zu testen, ist der Datenverkehr, der über den Router geleitet wird.
Datenverkehr über den Router
Der Datenverkehr durchläuft den schnellen Switching-Pfad und wird vom Router mit der höchsten Priorität verarbeitet. Das Basisnetzwerk veranschaulicht dies:
3 Router im Basisnetzwerk
Anpingen von Router3 von Router1:
Router1#ping 10.0.3.23 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.3.23, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
Der Datenverkehr läuft über Router2 und durchläuft den schnellen Switching-Pfad. Aktivieren der process-intensive-Funktion auf Router2:
Router1#ping 10.0.3.23 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.3.23, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms
Es gibt fast keinen Unterschied. Dies liegt daran, dass die Pakete auf Router2 jetzt auf Unterbrechungsebene behandelt werden.
Verwenden des debug-Befehls
Lesen Sie den Artikel Important Information on Debug Commands (Wichtige Informationen zu Debug-Befehlen), bevor Sie debug-Befehle verwenden.
Die verschiedenen in diesem Artikel verwendeten debug-Befehle zeigen, was passiert, wenn ein ping- oder traceroute-Befehl verwendet wird. Diese Befehle können Ihnen bei der Fehlerbehebung helfen. In einer Produktionsumgebung müssen Debugs jedoch mit Vorsicht verwendet werden. Wenn Ihre CPU nicht leistungsstark ist oder wenn Sie viele Pakete haben, die per Process-Switching verarbeitet werden, kann es sein, dass sich Ihr Gerät extrem verlangsamt. Es gibt mehrere Möglichkeiten, die Auswirkungen des debug-Befehls auf den Router zu minimieren. Eine Möglichkeit besteht darin, mithilfe von Zugriffslisten den spezifischen Datenverkehr einzuschränken, den Sie überwachen möchten.
Hier ein Beispiel:
Router4#debug ip packet ?
<1-199> Access list
<1300-2699> Access list (expanded range)
detail Print more debugging detail
Router4#configure terminal
Router4(config)#access-list 150 permit ip host 172.16.12.1 host 172.16.4.34
Router4(config)#^Z
Router4#debug ip packet 150
IP packet debugging is on for access list 150
Router4#show debug
Generic IP:
IP packet debugging is on for access list 150
Router4#show access-list
Extended IP access list 150
permit ip host 172.16.12.1 host 172.16.4.34 (5 matches)
Mit dieser Konfiguration gibt Router4 nur die Debug-Nachricht aus, die mit der Zugriffsliste 150 übereinstimmt. Ein Ping von Router1 bewirkt, dass diese Meldung angezeigt wird:
Router4# Jan 20 16:51:16.911: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.003: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.095: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.187: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.279: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3
Die Antwort auf das Problem kommt nicht von Router4, da diese Pakete nicht mit der Zugriffsliste übereinstimmen. Um sie anzuzeigen, fügen Sie Folgendes hinzu:
Router4(config)#access-list 150 permit ip host 172.16.12.1 host 172.16.4.34 Router4(config)#access-list 150 permit ip host 172.16.4.34 host 172.16.12.1
Ergebnisse:
Jan 20 16:53:16.527: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.531: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.627: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.635: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.727: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.731: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.823: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.827: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.919: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.923: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending
Eine weitere Möglichkeit, die Auswirkungen des debug-Befehls zu verringern, besteht darin, die Debug-Nachrichten zu puffern und mit dem Befehl show log anzuzeigen, sobald das Debugging deaktiviert wurde:
Router4#configure terminal
Router4(config)#no logging console
Router4(config)#logging buffered 5000
Router4(config)#^Z
Router4#debug ip packet
IP packet debugging is on
Router4#ping 172.16.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/37 ms
Router4#undebug all
All possible debugging has been turned off
Router4#show log
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: disabled
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 61 messages logged
Trap logging: level informational, 59 message lines logged
Log Buffer (5000 bytes):
Jan 20 16:55:46.587: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
sending
Jan 20 16:55:46.679: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
rcvd 3
Die Befehle ping und traceroute sind hilfreiche Dienstprogramme, mit denen Sie Probleme beim Netzwerkzugriff beheben können. Sie sind auch sehr einfach zu verwenden. Diese beiden Befehle werden häufig von NetzwerktechnikerInnen verwendet.
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
04-Oct-2022 |
Rezertifizierung |
1.0 |
10-Dec-2001 |
Erstveröffentlichung |
Feedback