Paketverlust mit MTR finden – und richtig lesen

Installation

apt install -y mtr-tiny     # Debian
dnf install -y mtr          # AlmaLinux

Ordnungsgemäß ausführen

mtr -rwbc 200 <destination>

• -r Report-Modus, so beendet er sich mit etwas, das du einfügen kannst
• -w breite Ausgabe, damit lange Hostnamen überleben
• -b Name und Adresse für jeden Hop anzeigen
• -c 200 zweihundert Zyklen, etwa dreieinhalb Minuten, und der Unterschied zwischen Beweis und Anekdote

Zehn Pakete beweisen gar nichts. Wenn ein Lauf mit zehn Zyklen Verlust zeigt, führe zweihundert aus, bevor du Schlüsse daraus ziehst.

Zuerst den letzten Hop auswerten

Router behandeln Pakete an sich selbst mit niedriger Priorität. Ein Transit-Router, der hunderte Gigabit transportiert, beantwortet deine abgelaufenen TTL-Sonden, wenn er einen freien Zyklus hat, und verwirft sie, wenn nicht – das zeigt Verlust in der Mitte deines Reports, während jedes Paket, das dich tatsächlich interessiert, intakt ankommt.

Zwei Regeln decken die meisten Reports ab:

1. Verlust bei Hop sieben, der bei Hop acht und danach fehlt, ist ein Rate-Limit. Ignoriere ihn.
2. Verlust, der bei Hop sieben beginnt und bis zum Ziel anhält, ist real, und der Hop, wo er beginnt, ist der Ort, an dem du suchen solltest.

Latenz verhält sich genauso. Ein Hop, der achtzig Millisekunden hinzufügt und dann den Verkehr mit dem vorherigen Wert an den nächsten Hop übergibt, antwortet langsam, leitet aber nicht langsam weiter.

ICMP ist nicht dein Verkehr

Wenn der Dienst auf TCP läuft, teste auf TCP:

mtr -rwbc 200 --tcp --port 443 <destination>

Netze, die ICMP stark limitieren, lassen TCP oft unberührt durch. Der umgekehrte Fall ist es wert, entdeckt zu werden, bevor du jemandem die Schuld gibst: eine Firewall, die Ping freudig beantwortet, aber den Port blockt, den deine Benutzer tatsächlich erreichen wollen.

Beide Richtungen, jedes Mal

Routing ist öfter asymmetrisch als nicht. Der Pfad von dir zu uns ist nicht der Pfad von uns zu dir, und ein Report von einer Seite beschreibt genau eine davon. Führe MTR von der Instanz zum Client und vom Client zur Instanz aus und füge beide bei. Unsere Hälfte des Pfads kann auch ohne Shell von überall aus über den Looking Glass untersucht werden.

Mit den TCP-Zählern untermauern

MTR beschreibt den Pfad. Die Socket-Statistiken beschreiben die Konsequenz:

ss -ti state established
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Eine Wiederholungsrate über etwa einem Prozent, bei einer Verbindung, die sauber sein sollte, bestätigt den Report. Null Wiederholungen zusammen mit einem MTR voller Verlust bedeutet, dass du auf ein Rate-Limit schaust und nichts anderes.

Was du uns senden sollst

• Beide MTR-Reports, zweihundert Zyklen, als Text statt als Screenshot
• Ziel, Transport und Port
• Zeitstempel mit Zeitzone und ob der Verlust konstant oder in Schüben auftritt
• Die Instanz-ID

Ungefähr die Hälfte davon löst sich zu einem ratenlimitierten mittleren Hop auf, und wir sagen das in der ersten Antwort. Den Rest können wir normalerweise innerhalb einer Stunde umleiten: Verlust in unserem eigenen Netz ist unser Problem, und Verlust in einem Transitpfad ist eine Frage, deinen Verkehr auf einen anderen zu verlegen.