Applikationsanalyse auf Basis der von TCP-Übertragung

Bei der Netzanalyse bestimme ich den Zustand eines Netzwerks anhand der Anzahl der ermittelten TCP-Sendewiederholungen. Ich sehe mir dabei auf den Servern und Workstations die entsprechenden Statistiken an oder ich mache mich mit einem Analysator im Netz auf die Suche nach TCP Retransmissions.

Im Internet steht den Interessierten zwar jede Menge Informationen über die Funktionsweise des TCP-Protokolls zur Verfügung, aber über die Ursachen von TCP Retransmissions ist wenig zu finden.

Das TCP-Protokoll garantiert die Übermittlung der gesendeten Daten über das Netzwerk. Der ACK-Mechanismus stellt sicher, dass die Daten beim Empfänger ordnungsgemäß angekommen sind. Erhält der TCP-Sender nicht innerhalb von 2 x RTT (zweimal die Round Trip Time) eine Bestätigung (ACK) durch den Empfänger, werden die "verloren" gegangenen Daten unaufgefordert erneut übermittelt. Darüber hinaus beschleunigen Features wie das Selective ACK (SACK) und eine schnelle Neuübertragung diesen Prozess.

Mehrere Dinge sind für eine Sendewiederholung eines Pakets (technisch ein TCP-Segment) verantwortlich. Meist ist die Ursache für eine Sendewiederholung auf einen Paketfehler zurückzuführen. Paketfehler können jedoch auch durch eine fehlerhafte Verkabelung oder von Kabeln in der Nähe von Störquellen (Stromleitungen oder Leuchtstofflampen) verursacht werden. Eine fehlerhafte Interface-Karte kann ebenfalls Paketfehler erzeugen. Auch elektronische Störungen auf der physikalischen Schicht können zu Bitfehlern und folglich zu Paketverlusten führen.

Auf dem Data Link Layer gehört beim Ethernet ein Duplex Mismatch zu den häufigsten Ursachen von Paketfehlern. Alte Netzadapter gehen in der Regel nicht richtig mit dem Auto-Negotiation-Mechanismus um. Bei modernen Komponenten kommen die Auto-Negotiation-Probleme nicht mehr vor. Trotzdem findet man in vielen Unternehmen immer noch völlig veraltete Auto-Negotiation-Konfigurationen. Die Kombination eines Voll-Duplex- Interfaces an einem Ende der Verbindung und einem auf die automatische Duplex-Erkennung eingestellten Interfaces am anderen Ende der Verbindung kann zu einem sogenannten  Duplex-Mismatch führen. Die im Standard festgelegte Duplex-Erkennung bietet  für ein fest eingestelltes Interface (auf eine fixe Konfiguration festgelegte Schnittstelle)keine Möglichkeit, mit einem anderen Interface, das auf automatische Parameteraushandlung konfiguriert ist, über das Netzt  Konfigurationsparameter auszutauschen. Da das auf die automatische Aushandlung konfigurierte Interface keine Parameter austauschen kann, setzt es sich in den Halbduplex-Modus und aktiviert das Netz-Interface. Somit kommunizierte in unserem Fall ein Halbduplex-Interface mit einem Vollduplex-Interface über die betreffende Verbindung.

Einen solchen Duplex-Mismatch erkennt man auf dem für den Vollduplex-Betrieb eingestellten Interface an Runts, FCS- und CRC-Fehler. Auf der Halbduplex-Seite der Verbindung treten vermehrt Late Collisions auf. Ein Duplex-Mismatch führt zwangsläufig zu Paketverlusten und die Anzahl der Paketverluste steigt kontinuierlich mit der Netzlast an.

Wir wissen, dass auf unseren Interfaces bestimmte Fehler auftreten, aber wir wissen nicht, wann die Fehlerraten zu hoch werden. Verloren gegangene Pakete haben einen signifikanten Einfluss auf den TCP Goodput (korrekt übermittelte Nutzdaten). Ein modernes Netzwerk-Link weist typischerweise eine Bitfehlerrate (BER) von weniger als 10-10 auf. Diese Werte werden heute auf Glasfaser- und Kupferstrecken erreicht. Bei der Übermittlung über Satellitenverbindungen kann man von solchen guten Werten nur träumen. Solche Verbindungen erreichen eine Bitfehlerrate von10-7.

Solche Zahlenwerte kann natürlich nur ein Fachmann interpretieren, in die Praxis umgesetzt bedeuten solche BER-Werte folgendes:

Ist ein zu übermittelndes Paket 10.000 Bits lang (1200 Byte) und weist das Übertragungsmedium einen BER von 10-10 auf, dann tritt ein Fehler pro 1 Million Pakete auf. Dabei ist jedoch zu beachten, dass  auf der Ebene 2  ein Bitfehler gleichzeitig zu einem Prüfsummenfehler und dadurch zu einem Verlust des gesamten Pakets führt. In den Analyse- und Managementsystemen werden die Verluste auf der Ebene 2 jedoch immer als Paketverluste (beispielsweise 0.000001 oder 0,0001 Prozent Paketverluste) dargestellt. Bei einer durchschnittlichen Paketgröße von 1000 Bits beträgt die Packet Error Rate genau ein Zehntel (oder 0,00001 Prozent) dieses Wertes. Dieser Wert stellt auch die Kennzahl für eine ordnungsgemäß funktionierende Verbindung dar.

Generiert ein Netzmanagementsystem bei der Überschreitung eines Schwellenwerts für einen bestimmten Interface-Fehler einen Alarm, dann muss man genau wissen, was dieser Schwellwert bedeutet. Ich setze in der Regel auf einer NMS-Plattform den Alarmierungsschwellwert auf 0,001 Prozent (10-5 Packet Error Rate). Dieser Wert entspricht einem BER von 10-9. Leider ermöglichen viele NMS-Plattformen nur die Definition einer Genauigkeit bei der Paketverlustrate von einer oder zwei Dezimalstellen. Dadurch muss man unter Umständen mit zu hohen Werten (beispielsweise 0,01 oder 0,1 Prozent) leben. In diesem Fall muss man das Messintervall für die Ermittlung von Paketfehlern auf einen Tag oder eine Woche ausweiten.

Hat man die Schwellwerte auf dem Netzmanagement- oder Analysesystem konfiguriert, wird man feststellen, dass Duplex-Konflikte zu wesentlich höheren Paketfehlerraten (als die von mir vorgeschlagenen Werte) führen. Ich habe Netze erlebt, in denen pro Tag mehr als 1.000.000 (ja, eine Million) Paketfehler auftraten. In diesen Netzen ergaben sich bis zu 30 Prozent Paketverluste. Die am Netz angeschlossenen Systeme versuchten erfolglos immer wieder ihre Daten zu übertragen. Die Fehlersuche in Netzen mit hohen Paketverlusten lässt sich schrittweise realisieren, indem die einzelnen Netzschnittstellen individuell untersucht und die  Probleme beseitigt werden. Im Laufe der Zeit reduziert man die Netzwerkfehler und erhöht damit gleichzeitig den Netzdurchsatz und verbessert die Produktivität der Mitarbeiter.   (mat)