Was verursacht doppelte ACK-Datensätze?

19

Wir überprüfen Wireshark-Erfassungen von einigen Client-Computern, auf denen mehrere doppelte ACK-Datensätze angezeigt werden, die dann eine erneute Übertragung und Pakete außerhalb der Reihenfolge auslösen.

Diese werden im folgenden Screenshot gezeigt. .26 ist Client und .252 ist Server.

Bildbeschreibung hier eingeben

Was verursacht die doppelten ACK-Datensätze?

Mehr Hintergrund, wenn es hilft:

Wir untersuchen Bedenken hinsichtlich des Netzwerkdurchsatzes an einem bestimmten Clientstandort. Das aus Sicht der Benutzeroberfläche wahrgenommene Problem besteht darin, dass Daten trotz einer nicht ausgelasteten 1-Gbit / s-WAN-Verbindung nur langsam übertragen werden.

Fast alle Client-Computer haben dasselbe Problem, das auf mehr als 20 Computern getestet wurde. Wir haben zwei Maschinen gefunden, die das Problem nicht haben. Wir sind dabei zu identifizieren, was sich in ihrer Konfiguration unterscheidet. Wir haben festgestellt, dass wir auf den beiden Rechnern, auf denen das Problem nicht auftritt, höchstens einen doppelten ACK-Datensatz gesehen haben. Die Computer, auf denen das Problem auftritt, haben normalerweise drei doppelte ACK-Einträge. Ein bemerkenswerter Unterschied ist, dass die Computer, die einwandfrei funktionieren, zu Mitgliedern des Netzwerkbetriebsteams gehören und alle anderen Computer für "normale" Mitarbeiter bestimmt sind. Die Maschinen sollten Standard sein, aber die Netzwerkadministratoren könnten Änderungen an ihren lokalen Systemen vorgenommen haben, was ein weiterer Aspekt ist, den wir untersuchen.

Wir haben versucht, die TcpMaxDupAcks- Einstellung auf dem Server zu ändern , aber der Wert, den wir wirklich benötigen, ist 5 und der gültige Bereich ist nur 1-3.

Server ist Windows Server 2003. Clients sind alle von Unternehmen verwalteten Windows XP. Auf allen Clients, einschließlich der beiden funktionierenden, ist Symantec Anti-Virus installiert.

Dies ist die einzige Client-Site von Hunderten, die dieses Problem aufweist.

pathping zeigt 56ms RTT und konsistenten 0/100 Paketverlust auch von den problematischen Rechnern.

Vielen Dank,

Sam

Sam
quelle
Welche Art von Routing-Switching-Hardware befindet sich zwischen den beiden Endpunkten?
SpacemanSpiff
@SpacemanSpiff, es gibt einen Cisco ASR 1006-Router.
Sam
Befinden sich das IT-Personal und die Kunden auf derselben Vermittlungseinrichtung? Können Sie eine ihrer Maschinen in den IT-Bereich bringen und feststellen, dass das Problem behoben ist?
SpacemanSpiff

Antworten:

25

Hinweis: Ich gehe davon aus, dass dieses Capture auf dem Clientcomputer aufgenommen wurde.

Eine kurze Zusammenfassung zur TCP-Sequenzierung: TCP liefert zuverlässig Ströme von Bytes zwischen zwei Anwendungen. "Zuverlässig" bedeutet in diesem Fall unter anderem, dass TCP garantiert, dass Daten, die nicht in Ordnung sind, niemals an eine hörende Anwendung geliefert werden.

Ordnungsgemäße, zuverlässige Zustellung wird durch die Verwendung von Sequenznummern realisiert. Jedem Paket in jedem Stream wird eine 32-Bit-Sequenznummer zugewiesen (denken Sie daran, dass TCP effektiv zwei unabhängige Datenströme ist, A-> B und B-> A). Wenn A eine ACK an B sendet, ist der Wert im ACK-Feld die nächste Sequenznummer, die A von B erwartet.

Anscheinend ist mindestens ein TCP-Segment verloren gegangen, das vom Server an den Client gesendet wurde. Die drei aufeinanderfolgenden doppelten ACKs sind ein Versuch des Clients, eine schnelle Neuübertragung auszulösen . Wenn ein TCP-Absender drei doppelte Bestätigungen für dasselbe Datenelement empfängt (dh vier Bestätigungen für dasselbe Segment, bei denen es sich nicht um das zuletzt gesendete Datenelement handelt), kann davon ausgegangen werden, dass das Segment unmittelbar nach dem Abbruch des zu bestätigenden Segments verloren gegangen ist im Netzwerk und führt zu einer sofortigen Neuübertragung.

In diesem Fall kommt die erneute Übertragung durch und wird von Wireshark als fehlerhaft identifiziert.

Wie von joeqwerty erwähnt , wird der Paketverlust am häufigsten durch Überlastung verursacht. Es kann auch eine Folge von CRC- oder anderen Fehlern auf einer Verbindung sein, die auf eine fehlerhafte Schnittstellenkarte, ein loses Kabel usw. zurückzuführen sind. Ich würde die Statistiken aller Verbindungen entlang des Pfads überprüfen, um festzustellen, ob sie stark ausgelastet sind und / oder treten viele Fehler auf.

Wenn Sie keine offensichtlichen Kandidaten sehen können, führen Sie an mehreren Punkten des Pfades gleichzeitig Paketerfassungen durch, um zu ermitteln, wo der Verlust auftritt.

Welche Art von WAN-Verbindung wird hier verwendet? Ist es eine Standleitung? MPLS VPN-Verbindung? IPsec VPN über das öffentliche Internet? Etwas anderes?

Murali Suriar
quelle
Danke für deine Kommentare. Sie haben Recht, die Paketerfassung erfolgt vom Client. Wenn ich verstehe, was Sie sagen, sind die doppelten ACKs nicht das, was der Client falsch macht, sondern der Auslöser dafür, dass er keinen anderen Datensatz erhalten hat (den nach den ACKs). Ist das korrekt? Welche Dinge kann ich auf dem Client-PC untersuchen, die dies verursachen würden? Wenn es sich nicht um ein Client-PC-Problem handelt, warum wird es auf einigen Clients ständig angezeigt und auf anderen nicht?
Sam
Das WAN ist eine "Zwei-Punkt-zu-Punkt-Verbindung" zwischen drei Standorten an der Ostküste und im mittleren Westen der USA.
Sam
Das ist richtig; Die DUPACKs sind ein Symptom für Paketverlust. Um herauszufinden, warum das Problem bei einigen Clients und nicht bei anderen auftritt, müssen Sie herausfinden, was die betroffenen Clients gemeinsam haben. Sind sie alle im selben Büro? Gemeinsame Netzwerkinfrastruktur durchlaufen? (Ein Schalter oder eine Verbindung?). Eine Sache, die es sich zu tun lohnt, ist, auf jedem der betroffenen Computer mtr(oder pathpingunter Windows) zu prüfen, ob auf dem Weg zum Server gemeinsame Hops auftreten, bei denen anscheinend Paketverluste auftreten. Verfügen Sie über ein Netzwerküberwachungssystem, mit dem Sie Switch-Port-Daten anzeigen können?
Murali Suriar
4

Stellen Sie sich einen Packet Dump als eines der Symptome vor, während Sie herausfinden, wo das Problem liegt. Wenn jemand mit Brustschmerzen in die Arztpraxis kommt, wird der Arzt keine drei Stunden damit verbringen, die Art des Problems zu untersuchen der Schmerz. Er verbringt ungefähr zwei Minuten damit und weiß dann, dass 95% der Ursachen entweder Sodbrennen oder Angina sind. Wenn Sie doppelte ACKs sehen, bohren Sie auf die gleiche Weise nicht sofort Ratten in die Unkräuter der Spur .

Nachdem die Verbindung hergestellt wurde, ist die langsame TCP-Leistung nicht immer auf Probleme mit dem Transitnetzwerk zurückzuführen. Manchmal ist dies das Ergebnis von Server-CPU- oder Festplatteneinschränkungen ... und gelegentlich aufgrund eines Problems auf einem Client-PC. Ich habe meinen Schwanz wochenlang in das Unkraut der Wireshark-Spuren gegraben, um das Problem mit mtr oder anderen Host-Metriken wie CPU- und Festplatten-E / A relativ schnell aufzugeben und zu finden .

Ihre erste Aufgabe besteht darin, zu prüfen, ob es sich um ein Netzwerkproblem oder ein Problem auf Hostebene handelt. Konzentrieren Sie sich auf das Senden realen Verkehr über das Netzwerk und beweisen , ob Sie Warteschlangen / lösenden / Nachbestellung Anmerkung 1 es; Das ist immer die Quintessenz für ein potenzielles Netzwerkproblem wie dieses .

Ich würde pingüber einen längeren Zeitraum (normalerweise eine Stunde für mich) eine Stichprobe zwischen dem Client und dem Server durchführen, während das Durchsatzproblem auftritt. Sie können dafür die Freeware mtr oder ping plotter verwenden . Wenn Sie ständig Pakete an einem Hop verlieren und alle Hops danach mindestens so viel verlieren , liegt ein potenzieller Netzwerkverdächtiger vor. Denken Sie daran, dass die ICMP-Ratenbeschränkung bei einigen Geräten dazu führen kann, dass sie Pakete verlieren. Aus diesem Grund möchten Sie nach einem Trend suchen, der von diesem Hop ausgeht, und den folgenden.


Hinweis 1 Wenn Sie Traffic nachbestellen, wird dies im Experten- Infofeld von wireshark relativ schnell angezeigt

Mike Pennington
quelle
Stimmen Sie zu, dass es kein guter Ansatz ist, das Netzwerk standardmäßig zu beschuldigen. Die Instrumentierung im gesamten Stack ist immer eine gute Übung. In diesem Fall scheinen jedoch die Segmente DUPACKs, Out-of-Order und Retransmitted auf einen Netzwerkverlust zwischen den beiden Endpunkten hinzuweisen.
Murali Suriar
@ Murali Suriar, lassen Sie uns mit Ihrer Behauptung gehen (die eine gute Chance hat, richtig zu liegen) ... und wie geht es weiter? Sie müssen herausfinden, warum es zu Paketverlusten kommt. Wir IT-Leute haben uns auf mysteriöse Weise in wiresharkden Punkt verliebt, in den wir gerne viel zu lange auf das Mikroskop schauen. Der Punkt, den ich anspreche, ist, einen kurzen Blick darauf zu pcapwerfen. Danach ist es besser, Zyklen für die Instrumentierung von Paketverlust, CPU-Zyklen und Festplatten-E / A zu verwenden, als tief in die Annalen von TCP einzutauchen. Es gibt eine Zeit, um das zu tun, aber normalerweise ist es nicht in dieser Phase der Analyse.
Mike Pennington
@Mike war einverstanden, weshalb ich als ersten Schritt vorgeschlagen habe, nach Informationen zu Fehlern / Auslastung für Geräte entlang des Pfades zu suchen. Ich bin kein großer Fan von ICMP-basierter Diagnose, außer der Erreichbarkeit. Wie Sie sagen, können Ratenbeschränkungen und falsch konfigurierte ACLs / Firewalls die Zuverlässigkeit beeinträchtigen. In einem Unternehmensnetzwerk (wie es sich anhört) kann MTR Sie jedoch häufig in die richtige Richtung lenken. Das andere Problem bei MTR ist, dass es oft nur auf ein Problem hinweist. Es ist durchaus möglich, dass es auf dem Pfad mehrere Fehler gibt , die Sie erst finden können, wenn Sie den ersten beheben.
Murali Suriar
Wir sind nicht anderer Meinung, ICMP mit TTL-Stepping ist kein Allheilmittel und es kann mehrere Fehler geben. Trotz aller Mängel bei Firewalls und Load-Balancern ist ICMP die beste Ferndiagnose, die wir haben, es sei denn, Sie können instrumentierte TCP / UDP-Sitzungen auf Host-Ebene an den betreffenden Anwendungsports ausführen ... selbst dann können Sie nur sagen Diese Buchse sendet viel erneut ... aber warum? In 70% der mtrFälle ziehe ich mich zurück oder es ist ein Problem. In den letzten 15 Jahren habe ich Probleme auf die gleiche Weise gelöst. Sobald ich mich auf ein bestimmtes Gerät konzentriert habe, können wir uns die Drop-Counter ansehen
Mike Pennington,
1
@Sam: Nur ein Punkt zur Fehlerbehebung bei Netzwerkproblemen: Jedes Netzwerk hat "Probleme". Entscheidend ist, ob diese Probleme zu Leistungs- und / oder Konnektivitätsproblemen führen. In jedem Netzwerk finden Sie doppelte ACKs, TCP-Neuübertragungen, Broadcasts, fehlerhafte Protokolle usw. Sie sollten sich auf das Volumen der doppelten ACKs und die Hosts konzentrieren, die am Senden der doppelten ACKs beteiligt sind, um festzustellen, ob dies wirklich ein Symptom für ein größeres Problem oder nur für die natürliche Funktionsweise des Netzwerks ist. Wenn ich 5 doppelte ACKs von 1.000 Paketen sehe, werde ich nicht noch einmal darüber nachdenken.
Joeqwerty
3

Wenn viele [TCP-Segment der wieder zusammengesetzten PDU] ohne ACKs angezeigt werden - ich würde sagen, dass diese ACKs aufgrund des Verhaltens der selektiven Bestätigung (auch bekannt als SACK) wahrscheinlich als [TCP-Dup-ACK ...] angezeigt werden .

Beispiel:

  • Client sendet Datenteile (..., 0,1,2,3,4,5,6, ...)

  • Server bestätigt (0), dann empfangen (2,4,3), dann (5), dann (6) und nie erhalten (1)

In obigem Szenario kann der Server zu Recht festlegen, dass zuerst (2-4) und dann (2-5) und dann (2-6) Bereiche bestätigt werden. Beim Bilden des Pakets "(AB) range ack" muss der Server den zuletzt bestätigten Teil (0) im TCP-Header angeben. Wireshark markiert die Range-Acks (SACKs) als [TCP Dup ACK ...], da alle diese Range-Acks denselben Wert für den zuletzt bestätigten Teil im TCP-Header haben (Ack = 872619 in Ihrem Fall).

dubrov
quelle
1

Doppelte ACKs in Kombination mit langsamer Netzwerkleistung sind für mich ein Problem mit einer Netzwerküberlastung. Sehen Sie sich das Volumen und die Rate des Broadcast-Verkehrs im Netzwerk an. Achten Sie darauf, Broadcasts auf der physischen Ebene und auf der Netzwerkebene sowie Multicasts zu betrachten.

Joeqwerty
quelle