tcpdump zeigt 64-KB-Pakete: Offload und Aufzeichnungspunkt

Eine Aufzeichnung auf einem Host kann ein Paket von 64 KB auf einer Schnittstelle mit MTU 1420 zeigen, und die naheliegende Schlussfolgerung ist, dass der Tunnel seine Größenbegrenzung ignoriert hat. Diese Schlussfolgerung ist meist falsch. Aufzeichnungspunkte auf dem Host liegen innerhalb des Verarbeitungspfads, in dem Segmentierung, Aggregation und Prüfsummenarbeit noch nicht stattgefunden haben können. Lesen Sie die Position des Beobachters, bevor Sie die Paketgröße lesen.

Wo Sie aufzeichnen, ändert, was Sie sehen

Transmit-Offload lässt den Stack eine große Einheit an das Netzwerkgerät übergeben, das sie später in drahtgroße Stücke schneidet. Empfangsaggregation macht auf dem Weg nach innen das Gegenteil und fügt Segmente zusammen, bevor ein Beobachter auf der Hostseite sie sieht. Eine Aufzeichnung erfasst daher die interne Sicht des Hosts an diesem Punkt, nicht unbedingt die Frames auf der Strecke. Beide Mechanismen hängen vom Gerät und vom Pfad ab.

ethtool -k eth0 | grep -E 'tso|gso|gro'

Zeichnen Sie an einem zweiten Punkt auf, idealerweise an einem unabhängigen Empfänger oder an einem Spiegel, bevor Sie die Größe als Fehler behandeln. Erscheint die große Einheit nur auf dem sendenden Host, hat die Strecke sie vielleicht nie getragen. Zwei Beobachtungspunkte sind stärker als eine Datei, besonders wenn die Frage lautet, was die Maschine tatsächlich verlassen hat.

Trennen Sie die innere und die äußere Schnittstelle

Ein Tunnel fügt seine eigene Schnittstelle hinzu, und die äußere und die innere Sicht unterscheiden sich in Kapselung und in Verarbeitung. Eine Aufzeichnung auf dem Tunnelgerät zeigt das innere Paket; eine Aufzeichnung auf dem physischen Adapter zeigt das äußere. Größe, Adressen und Prüfsummenzustand können sich zwischen beiden aus Gründen unterscheiden, die nichts mit einem Fehler zu tun haben.

Halten Sie fest, welche Schnittstelle welche Datei erzeugt hat. Eine auf dem Tunnelgerät gesehene Größe beschreibt das innere Paket, nicht den Frame, den der Adapter schließlich gesendet hat. Beides in einer Analyse zu vermischen, macht aus einem normalen Kapselungsunterschied ein Rätsel.

Eine Prüfsummenwarnung ist ebenfalls positionsabhängig

Eine Aufzeichnung auf der Sendeseite kann ein Prüfsummenfeld zeigen, bevor die Hardware es füllt, was eine Warnung erzeugt, die kein Empfänger je sehen würde. Das ist ein anderer Beleg als ein entfernter Host, der ein beschädigtes Paket zurückweist. Richtung und Aufzeichnungspunkt entscheiden, welches der beiden Sie haben.

Wenn eine tatsächliche Übertragung scheitert, vergleichen Sie Beobachtungen an einem Empfänger oder an einem anderen Punkt des Pfads. Bewahren Sie Richtung, Schnittstelle und Kapselungsschicht mit der Aufzeichnung auf, denn ein Screenshot ohne sie lässt sich später nicht deuten.

Schalten Sie Offload nur als kontrollierten Test ab

Das Abschalten von Offload verändert Leistung und Paketverarbeitung, ist also nicht die erste Reaktion auf eine seltsame Größenanzeige. Wenn Sie es testen, ändern Sie eine Einstellung und halten Sie zuerst den Ausgangszustand fest. Ein Lauf, der auch MTU, Firewallregeln und das Clientprofil ändert, kann das Ergebnis nicht dem Offload zuschreiben. Stellen Sie die Einstellung danach wieder her.

ethtool -K eth0 tso off gro off
ping -M do -s 1400 example.com

Ein echter Stillstand bei einer großen Übertragung ist eine eigene Frage zur Pfad-MTU und zum Feedback, das die Anwendung erhält. Eine aggregierte Einheit des Hosts beweist weder eine Größenbegrenzung weiter stromabwärts noch widerlegt sie eine, und ein niedriger CPU-Anteil benennt Offload nicht als Ursache.

Das nützliche Ergebnis ist ein erklärter Aufzeichnungspunkt plus eine reproduzierbare Anwendungsbeobachtung. Sind beide getrennt, kann eine MTU-Änderung eine echte Einschränkung treffen statt die Form eines internen Puffers.