Eine Dateikopie durch den Tunnel stockt für eine Sekunde, läuft weiter, und die VPN-Protokolle zeigen nichts. Die Anwendung gibt dem Netzwerk die Schuld, das Netzwerk der Anwendung, und der Switch-Port ist seit elf Monaten aktiv. Dieser Durchgang beginnt bei der Pause und arbeitet sich nach außen zur physischen Verbindung vor: was der Port tatsächlich tut, was die Gegenseite tut und was die Zähler getan haben, während Sie zusahen. Es lohnt sich, bevor irgendjemand eine Duplex-Einstellung anfasst.

Bei der Pause anfangen, nicht beim Port

Beschreiben Sie das Symptom so, dass es prüfbar ist. Ein Stocken von etwa einer Sekunde während einer Massenübertragung ist ein anderes Problem als eine Verbindung, die zurückgesetzt wird, und eine Pause einmal pro Stunde ist etwas anderes als eine alle paar Sekunden. Notieren Sie Arbeitslast, Richtung und das ungefähre Intervall.

Reproduzieren Sie es dann, während Sie die Schnittstelle beobachten. Ein physisches Problem zeigt sich als Bewegung in den Zählern während der betroffenen Arbeitslast, und ein Problem, das überhaupt keine Zählerbewegung erzeugt, liegt wahrscheinlich oberhalb der Sicherungsschicht. Beobachten Sie eine Minute, nicht eine Sekunde, denn diese Fehler brauchen oft anhaltenden Verkehr, bevor sie auftreten. Überwachung im Leerlauf beweist nichts über eine Verbindung, die sich nur unter Last falsch verhält.

Das ist wichtig, weil Duplex-Mismatches eine Signatur haben: Fehler, die nur unter Last auftreten, in Richtung des Verkehrs, während kleine Pings und interaktive Sitzungen einwandfrei bleiben. Wenn auch Leerlaufverkehr scheitert, suchen Sie zuerst woanders.

Den Betriebsmodus an beiden Enden lesen

Die gespeicherte Konfiguration ist nicht der Betriebszustand. Ein Port kann für Autonegotiation konfiguriert sein und bei Halbduplex landen, oder auf eine feste Geschwindigkeit konfiguriert sein, der die Gegenseite nie zugestimmt hat. Lesen Sie, was die Verbindung aktuell auf beiden Seiten tut.

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

Notieren Sie Geschwindigkeit, Duplex und ob Autonegotiation aktiv ist, und holen Sie dann dieselben drei Fakten vom angrenzenden Switch oder Provider-Port. Ein Ende allein sagt nichts, denn der Mismatch ist eine Beziehung und keine Einstellung. Stellen Sie beide Zeilen nebeneinander ins Ticket, mit der Uhrzeit, zu der Sie sie gelesen haben. Die Hälfte des Werts der Übung besteht darin, beide Messungen an einem Ort zu haben.

Wenn Sie die Gegenseite nicht lesen können, können Sie das nicht diagnostizieren. Bitten Sie den Eigentümer um Betriebsmodus und Zähler oder organisieren Sie Zugang, bevor Sie anfangen, Ihre Seite zu ändern.

Wie der 10/100-Halbduplex-Fall aussieht

Auf 10/100-Kupferstrecken kann ein autonegotiierender Endpunkt die Geschwindigkeit eines fest gesetzten Partners erkennen, ohne dessen Duplex-Einstellung zu erfahren. Die Parallelerkennung bestimmt die Geschwindigkeit aus dem Signal, und der Duplex wird angenommen statt ausgehandelt, sodass eine Seite bei Halbduplex landen kann, während die andere mit Vollduplex läuft.

Ciscos Anleitung zur Autonegotiation erklärt genau diesen Fall. Sie ist kein Argument dafür, die Aushandlung überall abzuschalten, und sie sagt nichts Nützliches über Gigabit-Kupfer, wo der Duplex fest ist und Autonegotiation nötig ist, damit die Verbindung überhaupt zustande kommt.

Der beobachtbare Beleg ist eine Mischung aus Fehlern, die nur in einer Richtung existieren: FCS- oder CRC-Fehler auf der Vollduplex-Seite, Kollisionen oder späte Kollisionen auf der Halbduplex-Seite und ein Durchsatz, der unter Last zusammenbricht, während die Latenz im Leerlauf normal bleibt. Diese Asymmetrie ist die Signatur. Eine Verbindung, die einfach überbucht ist, verschlechtert sich in beide Richtungen und zu jeder Zeit.

Beide Enden gemeinsam ändern, mit einem Rückweg

Eine Duplex-Korrektur ist eine abgestimmte Änderung, keine lokale. Ihre Seite zu erzwingen, ohne dass die Gegenseite zustimmt, ist der Weg, auf dem eine funktionierende Verbindung zu einer kaputten wird, und dass die CLI den Befehl akzeptiert, beweist nur, dass die Syntax gültig war.

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

Bevor Sie so etwas ausführen, bestätigen Sie, dass die Plattform die Kombination unterstützt und dass die Gegenseite im selben Zeitfenster geändert wird. Behalten Sie einen unabhängigen Weg zur Administration des Geräts, denn der Port, den Sie gleich ändern, kann derjenige sein, der Ihre Managementsitzung trägt.

Auf vielen modernen Verbindungen ist die richtige Antwort, die Autonegotiation an beiden Enden aktiv zu lassen, statt etwas zu erzwingen. Erzwingen ist ein Mittel gegen einen bestimmten Mismatch auf einer bestimmten Technologie, keine allgemeine Verbesserung. Besonders Gigabit-Kupfer braucht Autonegotiation, damit die Verbindung überhaupt zustande kommt, daher überträgt sich der Rat für 10/100 nicht.

Bestätigen, dass sich die Zähler zum Besseren bewegt haben

Lesen Sie nach der Änderung den Betriebszustand an beiden Enden erneut und bestätigen Sie, dass sie übereinstimmen. Fahren Sie dann dieselbe Arbeitslast, die die Pause erzeugt hat, und vergleichen Sie Zählerdifferenzen statt Lebenszeit-Summen, denn eine Summe, die sich seit einem Jahr ansammelt, kann Ihnen nicht sagen, was in den letzten zehn Minuten passiert ist.

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

Eine Verbindung ohne neue Fehler unter derselben Last ist der Beleg, der Ihnen fehlte. Eine Verbindung, die weiterhin Fehler wirft, oder eine, bei der sich die Zähler gar nicht bewegt haben, schickt Sie zur nächsten Grenze statt tiefer in die Duplex-Diskussion. Beide Ergebnisse sind Fortschritt, und das ist mehr, als die Konfigurationsdatei Ihnen geben kann. Überspringen Sie die zweite Messung nicht, nur weil die erste richtig aussah.

Schreiben Sie die Zahlen vorher und nachher mit Zeitstempeln ins Ticket. Genau dieser Eintrag macht aus «das VPN fühlt sich besser an» etwas, worauf der nächste Ingenieur aufbauen kann.

Ähnliche Artikel