Ein fehlender Ping ist ein Hinweis, keine Diagnose.

Der Browser lädt eine Website, doch auf einen Ping antwortet ihr Server nicht. Ist das ein Widerspruch? Nein: Der Browser spricht mit einem Webdienst; Ping bittet das Zielsystem um eine bestimmte Kontrollantwort. Eine Firewall darf diese beiden Nachrichtenarten unterschiedlich behandeln. Umgekehrt kann ein Rechner auf Ping antworten, während sein Webdienst gestoppt ist. Wer diese Ebenen auseinanderhält, kann einen Ausfall gezielter untersuchen und vermeidet vorschnelle Änderungen an funktionierenden Systemen.

ICMP übermittelt Kontrollinformationen zur IP-Kommunikation. IP selbst verspricht keine erfolgreiche Zustellung. Ein Router kann ein Paket beispielsweise wegen eines abgelaufenen Weiterleitungszählers verwerfen. ICMP gibt ihm eine Möglichkeit, den Absender darüber zu informieren. Es ist weder ein Reparaturdienst für verlorene Pakete noch ein universelles Fehlerprotokoll mit garantierter Antwort. Die Meldung kann ebenfalls verloren gehen oder gefiltert werden. Die Grundform beschreibt RFC 792; für heutige IPv4-Router ergänzt RFC 1812, Abschnitt 4.3 die Verarbeitung.

Für den Paketweg helfen die vorhandenen Artikel über Routing und das OSI- und TCP/IP-Modell. Hier betrachten wir, welche Rückmeldungen ein Absender beobachten kann und was daraus tatsächlich folgt.

ICMPv4 und ICMPv6 sprechen über IP.

ICMPv4 wird in einem IPv4-Paket transportiert; dessen Protocol-Feld enthält den Wert 1. Bei ICMPv6 bezeichnet der Next-Header-Wert 58 die Kontrollnachricht. Diese Zahlen sind keine Portnummern. Ein ICMP-Header unterscheidet Nachrichten durch Type und Code. Echo-Nachrichten haben zusätzlich einen Identifier und eine Sequenznummer, damit Anfrage und Antwort zugeordnet werden können. Das sind weiterhin keine TCP- oder UDP-Ports.

Für IPv4 heißt die Echo-Anfrage Type 8, ihre Antwort Type 0. IPv6 verwendet Type 128 beziehungsweise 129. Ein erreichbarer Endpunkt, der Echo-Anfragen annimmt, erzeugt zu einer Anfrage eine passende Echo-Antwort. Die mitgeschickten Nutzdaten helfen beim Zuordnen und Prüfen. Zwischen Anfrage und Antwort besteht aber keine TCP-Verbindung. Es gibt keinen Verbindungsaufbau und keine allgemeine ICMP-Wiederholung verlorener Echo-Pakete.

ICMPv6 ist ein integraler Bestandteil von IPv6. Seine Fehlernachrichten sind in RFC 4443 beschrieben. Weitere ICMPv6-Nachrichten tragen beispielsweise Neighbor Solicitation und Neighbor Advertisement. Sie gehören zur Neighbor Discovery nach RFC 4861, die unter anderem Nachbaradressen auf dem lokalen Link ermittelt. Deshalb ist „alles ICMPv6 sperren“ wesentlich mehr als das Abschalten von Ping. Die Einzelheiten stehen im IPv6-Artikel.

Fehlermeldungen nennen einen Grund.

Destination Unreachable bedeutet, dass die meldende Stelle die Zustellung unter den gegebenen Bedingungen nicht durchführen kann. Type und Code unterscheiden Gründe: Eine fehlende Route ist etwas anderes als ein administratives Verbot oder ein nicht erreichbarer UDP-Port. Die Fehlernachricht enthält Teile des auslösenden Pakets, damit das empfangende System sie zuordnen kann. Auch wenn darin ein UDP-Header mit Portnummern zitiert wird, bekommt ICMP dadurch keine eigenen Ports.

Time Exceeded kann das Ablaufen des Weiterleitungszählers melden. Sowohl IPv4 als auch IPv6 kennen außerdem einen entsprechenden Grund bei abgelaufener Fragment-Wiederzusammensetzung. In unseren Diagrammen geht es ausschließlich um das Weiterleitungslimit. Parameter Problem meldet Probleme mit bestimmten Headerinformationen. Nicht jeder Fehler erzeugt eine Antwort: Regeln verhindern etwa unbegrenzte Fehlerketten durch Antworten auf weitere Fehler. ICMP ist damit eine begrenzte Rückmeldung und keine vollständige Aufzeichnung jedes verworfenen Pakets.

Drei Router: Die Anfrage und ihre Antwort sind zwei Pakete.

Unser bewusst vereinfachtes Labornetz besteht aus Rechner A, drei Routern R1 bis R3 und Server B. A hat die private Adresse 192.168.10.20; B trägt die Dokumentationsadresse 203.0.113.80. Das ist ein erfundenes Lehrszenario, kein getesteter Internetpfad. Alle erforderlichen Routen und Rückrouten sind vorhanden, Echo ist erlaubt, NAT und Tunnel fehlen. Eine IPv4-Echo-Anfrage beginnt mit TTL 64.

Echo über drei RouterA sendet eine Echo-Anfrage mit TTL 64. R1 leitet mit 63 weiter, R2 mit 62 und R3 mit 61. B empfängt die Anfrage und erzeugt eine neue Echo-Antwort mit eigenem Weiterleitungslimit. Der Rückweg muss ebenfalls funktionieren.Simulierter IPv4-HinwegA · 192.168.10.20Echo Request · TTL 64R1 · TTL 64 → 63R2 · TTL 63 → 62R3 · TTL 62 → 61B · 203.0.113.80Empfängt mit TTL 61B erzeugt einen Echo Reply.Neues Paket · eigener ZählerRückroute zu A erforderlich
Jeder weiterleitende Router verringert die TTL. B muss die TTL der Anfrage nicht für seine Antwort übernehmen. Im IPv6-Beispiel wäre das entsprechende Feld das Hop Limit.

Die IPv4-TTL heißt historisch Time to Live. Für die hier betrachtete Weiterleitung wirkt sie als Begrenzung der Routerdurchläufe: Ein Router reduziert sie mindestens um eins. Er darf ein Paket nicht mit abgelaufenem Wert weiterleiten. IPv6 benennt die Aufgabe direkter als Hop Limit; jeder weiterleitende Knoten verringert den Wert um eins. Ein gewöhnlicher Layer-2-Switch verbraucht dabei keinen zusätzlichen IP-Hop. Näheres regeln RFC 1812, Abschnitt 5.3.1 und RFC 8200, Abschnitt 3.

Für die Rückantwort braucht B eine passende Route zu A. Deren Weg kann von der Hinrichtung abweichen. Eine Anfrage kann deshalb am Ziel ankommen, obwohl der Absender niemals eine Antwort sieht. Die Ankunft allein reicht für einen erfolgreichen Ping nicht aus. Auch die lokale Zuordnung und die rechtzeitige Rückkehr müssen stimmen.

Mit TTL 2 endet dieselbe Anfrage bei R2.

Nun startet A im gleichen Lehrnetz mit TTL 2. R1 empfängt den Wert 2 und leitet mit 1 weiter. R2 darf das Paket nach dem nächsten Herabsetzen nicht weitergeben. Er verwirft es und erzeugt unter den vorgesehenen Bedingungen eine ICMP-Time-Exceeded-Meldung an A. B bekommt diese Echo-Anfrage nicht. Die Meldung ist eine neue Nachricht des Routers und kein Echo Reply des Servers.

TTL läuft am zweiten Router abA startet mit TTL 2. R1 reduziert auf 1. R2 verwirft die Anfrage beim Ablauf und sendet ICMP Time Exceeded an A. R3 und B erhalten die Anfrage nicht. Bei IPv6 ist das entsprechende Verhalten Hop-Limit-Ablauf mit ICMPv6 Time Exceeded.Simulierte Probe · TTL 2A sendet · TTL 2R1 · TTL 2 → 1R2 · Limit abgelaufenAnfrage verwerfenTime Exceeded → AR3 · keine Anfrage erhaltenB · keine Anfrage erhaltenDie Fehlermeldung ist neu.Sie benötigt eine Rückroute.ICMP besitzt keine Ports.
Die Route besteht weiterhin aus drei Routern. Die Probe erreicht nur zwei davon. R3 und B erscheinen als Text und sind absichtlich nicht mit einem Datenpfeil verbunden.

Ein größerer Startwert ist keine Reparatur für jede Störung. Er erlaubt nur mehr Weiterleitungsschritte. Eine Routingschleife bleibt eine Schleife, eine fehlende Route fehlt weiterhin und eine gesperrte Nachricht bleibt gesperrt. Der Zähler begrenzt vor allem, wie lange ein Paket in einem fehlerhaften Weiterleitungsweg kreisen kann.

Ping misst eine vollständige Hin-und-zurück-Reise.

Ping sendet Echo-Anfragen und wartet auf passende Antworten. Die Round Trip Time, kurz RTT, reicht vom Absenden bis zur empfangenen Antwort. Sie enthält Hinweg, Verarbeitung am Ziel und Rückweg. Ein RTT-Wert von 24 Millisekunden bedeutet daher nicht, dass der Hinweg exakt 12 Millisekunden dauerte. Unterschiedliche Wege, Warteschlangen und die Verarbeitung der Kontrollnachricht können die Verteilung verändern.

Simuliertes Ergebnis, keine ausgeführte Messung:
Ziel: 203.0.113.80
Anfrage 1: Antwort nach 24 ms
Anfrage 2: Antwort nach 26 ms
Anfrage 3: Zeitüberschreitung
Anfrage 4: Antwort nach 25 ms
Gesendet: 4 · Antworten: 3 · ohne Antwort: 25 %

Hier blieb eine von vier Anfragen ohne rechtzeitig zugeordnete Antwort. Die angezeigten 25 Prozent beschreiben diese kleine Stichprobe. Sie beweisen weder dauerhaften Verlust in dieser Größenordnung noch einen bestimmten defekten Router. Möglich sind Verlust der Anfrage, Verlust der Antwort, Filterung oder eine Antwort nach Ende des Wartefensters. Aus drei erfolgreichen Antworten lässt sich ebenfalls keine belastbare Aussage über den gesamten Tagesbetrieb ableiten.

Notiere bei einer Diagnose deshalb Zieladresse, IP-Version, Zeitpunkt, Anzahl, Paketgröße und Wartezeit. Ein per Name gewähltes Ziel kann über DNS mehrere Adressen liefern; IPv4 und IPv6 können ganz verschiedene Wege nehmen. Schon ein Wechsel der ausgewählten Adresse macht zwei vermeintlich gleiche Tests nur eingeschränkt vergleichbar. Die Namensauflösung ist im DNS-Artikel erklärt.

Traceroute provoziert Antworten mit unterschiedlichen Limits.

Traceroute sendet mehrere eigenständige Proben. Zunächst reicht ihr Weiterleitungslimit bis zum ersten Router, danach bis zum zweiten und so weiter. Die empfangenen Time-Exceeded-Antworten lassen erkennen, welche Geräte auf diese Proben reagieren. Das Programm verfolgt also nicht ein einziges Paket beim Wandern durchs Netz. Jede angezeigte RTT gehört zur Reise einer Probe bis zur antwortenden Stelle und zurück.

Simulierter Verlauf über R1, R2 und R3:
Hop 1   R1             1 ms   1 ms   2 ms
Hop 2   *              *      *      *
Hop 3   R3            14 ms  13 ms  15 ms
Hop 4   Ziel B        24 ms  25 ms  24 ms

R2 ist in diesem Beispiel vorhanden und leitet Daten weiter, beantwortet die Proben aber nicht sichtbar. Die Sterne bedeuten lediglich, dass innerhalb des Wartefensters keine zugeordnete Antwort einging. Wenn spätere Hops antworten, ist die Behauptung „bei Hop 2 bricht die Verbindung ab“ durch dieses Ergebnis gerade nicht gedeckt. Ein Router kann Kontrollantworten niedriger priorisieren oder begrenzen, obwohl sein Weiterleitungspfad normal arbeitet.

Das Verfahren hängt von den Proben ab.

ICMP-basierte Verfahren senden Echo Requests. Zwischengeräte antworten beim Limitablauf mit Time Exceeded; am erreichten Ziel kann ein Echo Reply den Abschluss anzeigen. Die offizielle Windows-Dokumentation zu tracert beschreibt diesen ICMP-basierten Ablauf. Andere Systeme bieten je nach Implementierung ebenfalls eine ICMP-Variante an.

UDP-basierte Verfahren senden UDP-Datagramme, häufig an voraussichtlich unbenutzte Zielports. Die Router melden den Limitablauf weiterhin mit ICMP. Am Ziel kann ein ICMP Port Unreachable anzeigen, dass die Probe angekommen ist und dort kein passender UDP-Empfänger existiert. Das Portfeld gehört zum UDP-Datagramm; die zurückkommende ICMP-Fehlermeldung besitzt weiterhin keinen Port.

TCP-basierte Verfahren verwenden etwa SYN-Proben an einen bestimmten Dienstport. Am Ziel kann je nach Zustand SYN/ACK oder RST zurückkommen; unterwegs wird der Limitablauf wieder durch ICMP sichtbar. Das Ergebnis testet dann bestimmte Bedingungen für TCP-Verkehr. Es ersetzt weder einen vollständigen TLS-Handshake noch einen HTTP-Request. Die Varianten unterscheiden sich in ihrer Behandlung durch Filter und Lastverteilung. Die Probenart gehört deshalb zum Diagnoseprotokoll.

Die offizielle FreeBSD-Handbuchseite zu traceroute dokumentiert beispielsweise UDP sowie auswählbare andere Probenarten. Die Befehlsoptionen unterscheiden sich zwischen Betriebssystemen und installierten Programmen. Dieser Artikel führt keine Befehle aus und benötigt keine Netzwerkpakete. Die Namen dienen der Einordnung vorhandener Diagnoseausgaben. In einer eigenen, freigegebenen Umgebung sollte man vor Verwendung die lokale Hilfe lesen, Probenzahl und Wartezeit begrenzen und die gewählte IP-Version festhalten. Ein TCP-Verfahren darf nicht stillschweigend in eine Portsuche über viele Ziele übergehen.

Filtern beeinflusst Diagnose und Nutzdatenverkehr.

Eine Firewall kann Echo Requests verwerfen und HTTPS erlauben. Sie kann auch Antworten nur innerhalb bestehender Zustände zulassen. Router begrenzen die Rate selbst erzeugter ICMP-Meldungen, um ihre Kontrollverarbeitung zu schützen. Viele unbeantwortete Traceroute-Proben an einem Zwischenhop können deshalb ein Limit der Antworten anzeigen, während späteres Nutzdatenverkehrsaufkommen unbeeinträchtigt bleibt. Zusätzliche Proben verbessern dann nicht zwangsläufig die Erkenntnis.

Auch beantwortete Kontrollnachrichten sind nicht automatisch vertrauenswürdig. Fehlernachrichten müssen zum betreffenden Verkehr passen und plausibel verarbeitet werden. Aus einer isolierten Meldung folgt keine Erlaubnis, pauschal alle Sicherheitsregeln zu entfernen. Die sinnvolle Frage lautet: Welche benötigte Nachrichtenart muss für diesen Kommunikationsweg zugelassen und korrekt zugeordnet werden?

Path MTU Discovery braucht passende Rückmeldungen.

Ein Pfad kann auf einem späteren Link eine kleinere maximale IP-Paketgröße erlauben. Bei klassischer IPv4 Path MTU Discovery sendet der Absender mit gesetztem Don't-Fragment-Bit. Kann ein Router ein solches Paket nicht passend weiterleiten, meldet er per ICMP Destination Unreachable „Fragmentation needed“ mit Größeninformation. Der Absender kann danach kleinere Pakete senden. RFC 1191 beschreibt diesen Mechanismus.

IPv6-Router fragmentieren weitergeleitete Pakete nicht. Für einen zu kleinen Ausgangslink gibt es ICMPv6 Packet Too Big. Der Absender berücksichtigt die gemeldete MTU; die IPv6-Pfadermittlung beschreibt RFC 8201. Werden solche Meldungen pauschal blockiert, können kleine Nachrichten funktionieren, während größere Übertragungen hängen. Ein erfolgreicher kleiner Ping schließt ein Größenproblem daher nicht aus.

Ergänzend kann die Paketisierungsschicht mit bestätigten Proben geeignete Größen ermitteln. RFC 8899 beschreibt DPLPMTUD für Datagrammtransporte. Solche Verfahren mindern die Abhängigkeit von ICMP-Rückmeldungen, machen die pauschale Sperre essenzieller ICMPv6-Funktionen aber nicht sinnvoll. Diagnose, Größenanpassung und lokale Nachbarerkennung bleiben unterschiedliche Aufgaben.

Der Webserver antwortet nicht: vier Hypothesen prüfen.

Angenommen, der Administrator erhält beim Ping auf die simulierte Serveradresse keine Antwort. Keine Route: Schon der lokale Rechner oder ein Router findet keinen passenden Ausgang. Eine lokale Routingtabelle oder eine zugeordnete Unreachable-Meldung kann Hinweise liefern. ICMP-Filterung: Anfrage oder Antwort wird verworfen; der Webdienst kann trotzdem erreichbar sein.

Host nicht erreichbar: Das Zielsystem ist ausgeschaltet, sein Link ist unterbrochen oder die lokale Zustellung beim letzten Router scheitert. Fehlende Rückroute: Die Anfrage kommt an, aber die Antwort findet keinen erlaubten Rückweg. Diese vier Fälle können dieselbe sichtbare Zeitüberschreitung erzeugen. Eine einzelne Ausgabe kann sie nicht sicher unterscheiden.

Für eine nachvollziehbare Untersuchung verbindet man vorhandene Beobachtungen: Ist die lokale Konfiguration plausibel? Welche Route wäre vorgesehen? Funktioniert derselbe Dienst über die tatsächlich verwendete Adresse? Gibt es am Ziel oder Gateway passende Protokolleinträge? Für lokale Ansichten und die Unterscheidung zwischen Netzwerk und Dienst hilft Linux-Server administrieren. Eine bestehende SSH-Sitzung oder ein erfolgreicher HTTP-Abruf liefert andere Evidenz als Echo.

Typische Fehlschlüsse lassen sich damit klar benennen: „Ping geht, also ist HTTPS gesund“ überspringt TCP oder QUIC, TLS und HTTP. „Ein Stern zeigt einen ausgefallenen Router“ ignoriert Filter und Rate Limits. „Die Differenz zweier Hop-RTTs ist die Leitungslaufzeit dazwischen“ ignoriert verschiedene Proben und Rückwege. „Jede im alten ICMP-RFC genannte Nachricht ist heute empfohlen“ ignoriert spätere Aktualisierungen: Source Quench wurde durch RFC 6633 verworfen; weitere historische Typen behandelt RFC 6918.

Zwei Ausgaben richtig einordnen.

Aufgabe 1: Eine Probe startet vor R1 mit Hop Limit 3 und soll über R1, R2 und R3 zu B gelangen. Welcher Router verwirft sie? Empfängt B diese Probe? Welche Nachricht kann A erhalten?

Lösung: Das Limit an jedem Router verfolgen

R1 leitet mit 2 weiter, R2 mit 1. R3 stellt beim nächsten Herabsetzen den Ablauf fest und verwirft die Probe. B erhält sie nicht. R3 kann ICMPv6 Time Exceeded, Code 0, an A senden. Auch diese neue Nachricht benötigt einen funktionierenden Rückweg. Bei Rate Limit oder Filterung kann A stattdessen nur eine Zeitüberschreitung sehen. Für die Ankunft bei B reicht in diesem einfachen Drei-Router-Szenario ein Startwert von 4.

Aufgabe 2: Ping bleibt ohne Antwort. Im Browser lädt derselbe Webdienst über dieselbe IP-Adresse. Traceroute zeigt bei Hop 2 Sterne, danach zwei antwortende Hops. Welche Aussagen sind belegt? Was müsste zusätzlich geprüft werden, wenn nur große Downloads hängen?

Lösung: Beobachtung von Ursache trennen

Belegt ist, dass der Webabruf zu diesem Zeitpunkt funktioniert und bestimmte Diagnoseantworten fehlen. Ein generell unerreichbarer Server oder ein vollständiger Weiterleitungsabbruch bei Hop 2 passt nicht zu diesen Beobachtungen. ICMP-Filter und Rate Limits bleiben mögliche Erklärungen, sind aber noch nicht bewiesen. Bei größenabhängigen Problemen gehören die Pfad-MTU, passende ICMP-Fehlermeldungen und die verwendete Paketisierung in die Untersuchung. Ein kleiner Echo-Test kann diese Fehlerklasse nicht ausschließen.

Als Nächstes zeigt TCP, UDP und QUIC, welche Zusagen der Transport einer Anwendung bietet. Im vollständigen Webseitenaufruf werden Kontroll-, Transport- und Anwendungsebene zusammengeführt.

Quellen und fachlicher Stand.

Technisch geprüft am . Alle Netze, Ausgaben und Diagramme sind eigene Lehrbeispiele. Es wurden keine Diagnosepakete gesendet. RFC-Status und Errata wurden beim RFC Editor geprüft; gemeldete, noch unbestätigte Errata werden nicht als gültige Normänderung behandelt.