Paketverlust lesen, bevor das Kabel schuld ist

Zwei Prozent Verlust über einen langen Ping-Lauf wirken wie eine Zahl, auf die man reagieren kann, und das sind sie selten. Sie sagt nicht, wo die Antworten verloren gingen, ob sie gemeinsam verloren gingen oder wie eine bestimmte Anwendung dieses Intervall erlebte. Gleichmäßig über eine Minute verteilter Verlust und Verlust, der sich in einem einzigen Austausch ballt, führen bei gleichem Prozentwert zu sehr unterschiedlichen Ergebnissen.

Vergleichen Sie drei Messungen, statt einer zu vertrauen: was die Sonde sah, was die Interface-Zähler taten und worauf die Anwendung tatsächlich wartete.

Was ein Ping-Prozentwert tatsächlich misst

Eine Echo-Sonde prüft eine Richtung eines Protokolls mit einer Paketgröße, mit welcher Rate Sie auch immer gewählt haben. Ein Tunnel, der einen großen Upload trägt, tut etwas völlig anderes, und eine Verbindung, die kleine Sonden verwirft, ist nicht zwangsläufig die Verbindung, die der Übertragung schadet. Der Prozentwert zerstört außerdem die Zeitinformation, auf die es am meisten ankommt, denn zehn verlorene Antworten in einem Schwall sind nicht dasselbe wie zehn verlorene Antworten mit einer Stunde Abstand. Er kann Ihnen auch nicht sagen, welche Seite des Tunnels etwas verworfen hat.

Behalten Sie das Sondenergebnis als Hinweis auf den Pfad. Suchen Sie dann das Timing und die Grenze, die es erzeugt haben.

Vergleichen Sie Zählerdifferenzen, keine Lebenszeitsummen

Nehmen Sie zeitgestempelte Messwerte vor und nach dem Zeitfenster auf, in dem das Symptom auftrat, an beiden Endpunkten und an jedem Switch-Port, den Sie kontrollieren. Notieren Sie das Verkehrsvolumen zusammen mit Fehlern, Verwerfen und Linkzustandsänderungen, denn eine Summe ungleich null, die sich über Monate angesammelt hat, beschreibt Geschichte und nicht diesen Vorfall. Ein Zähler, der sich während der Blockade um drei bewegte, ist eine andere Beobachtung als ein Zähler, der drei Tausend anzeigt und sich nie verändert hat.

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

Pakete, die wegen Empfangsfehlern verworfen werden, und Pakete, die aus anderen Gründen verworfen werden, leben in getrennten Zählern, und dieser Unterschied ändert das weitere Vorgehen. Fehlerzähler zeigen auf die physische Schicht oder die Treiberschicht, während Warteschlangendruck und Richtlinien-Verwerfungen irgendwo darüber zeigen. Bewahren Sie auch Richtung und Interface-Namen auf, denn ein Anstieg der Empfangsfehler auf einem Uplink und ein Tunnel-Paketzähler sind nicht austauschbar.

Wenn ein Treiber detaillierte physische Zähler bereitstellt, lesen Sie sie über die Dokumentation dieses Adapters. Jedem Feld namens „drop“ bei zwei Herstellern eine einzige Bedeutung zuzuschreiben, ist der Weg, auf dem eine normale Abrechnungseigenheit zur Hardware-Diagnose wird.

Wie ein verlorenes Segment zu einer langen Wartezeit wird

Eine Anwendung kann nach dem Verlust eines Segments weit länger als eine Roundtrip-Zeit warten. TCP schätzt die Roundtrip-Zeit, berechnet daraus einen Retransmissionstimer und zieht sich zurück, wenn auch eine Retransmission scheitert, sodass ein einzelnes verlorenes Segment im falschen Moment eine Anfrage für ein merkliches Intervall blockieren kann. Dieser Mechanismus ist in RFC 6298 spezifiziert, und er erklärt, warum eine Verlustrate, die trivial aussieht, dennoch spürbar sein kann.

Nicht jede Pause ist jedoch ein Retransmissionstimeout. Dieselbe Wartezeit kann von der Namensauflösung, einem langsamen Server oder einer Anwendung kommen, die ihre eigene Anfrage nach einem Fehler wiederholt. Trennen Sie diese Fälle, indem Sie den fehlgeschlagenen Vorgang mit Transportbeobachtungen und mit den Sitzungsereignissen des Tunnels abgleichen. Eine Unterbrechung auf dem Datenpfad ohne Neuverbindung ist ein anderes Ereignis als ein frischer Handshake und ein Austausch von Anmeldedaten.

Wo die Aufzeichnung erlaubt ist, halten Sie sie eng. Sie brauchen die Antwort, ob die erwarteten Pakete oder Bestätigungen an einer bestimmten Grenze aufhören, nicht die Tatsache, dass irgendwo in einer geschäftigen Spur eine Retransmission existiert.

Ändern Sie eine Grenze, ohne die anderen zu bewegen

Wenn die Beweise auf eine lokale Verbindung deuten, ersetzen Sie ein zugelassenes Kabel oder einen Port als kontrollierten Vergleich und lassen Sie alles andere unangetastet. Halten Sie Endpunkt, Anwendung und Last vergleichbar und ändern Sie pro Versuch genau eine Grenze. Ein kabelgebundenes Notebook mit einem drahtlosen zu vergleichen, während Sie auch Ausgänge und Protokolle wechseln, sagt Ihnen nichts, was Sie zurechnen können.

Saubere lokale Zähler bescheinigen den Rest des Pfads nicht. Sie begrenzen den Teil, den Sie sehen, und der ehrliche Bericht nennt die Grenzen, die beobachtet wurden, und die, die es nicht wurden. Was Sie am Ende wollen, ist die Aussage, dass sich eine Beobachtung änderte, als ein Eingriff geschah, nicht eine Anekdote über ein schlechtes Kabel, die zur allgemeinen Regel erhoben wurde.