Ermitteln der Ursache für die erneute TCP-Übertragung in einem LAN

25

Hallo Bewohner von Server Fault

Ich habe ein irritierendes Problem mit einem LAN von ungefähr 100 Computern, 2 Windows-Domänenservern und 12 VoIP-Telefonen. Seit ihrer Installation vor ungefähr einem Jahr stellen wir jede Woche fest, dass sich ein VoIP-Telefon zurücksetzt - gelegentlich während eines Anrufs. Gleichzeitig treten auf Computern häufig Anzeichen für einen vorübergehenden Verbindungsverlust auf: Einfrieren des Explorers beim Zugriff auf Netzwerkfreigaben, Fehler in unserer Verwaltungssoftware aufgrund eines Verbindungsverlusts zum Datenbankserver.

Ich habe eine Wireshark-Überwachung der Verbindung zwischen der VoIP-PBX und dem Rest des Netzwerks durchgeführt. Wireshark nimmt eine Ansammlung von erneut übertragenen TCP-Paketen auf, wenn wir einen Neustart des Telefons aufzeichnen. Das Wireshark-Protokoll zeigt ungefähr 2 Cluster von Neuübertragungen pro Tag an, die von 5 Paketen bis zu Hunderten reichen. Diese befinden sich in jedem Cluster hauptsächlich zwischen der TK-Anlage und einigen VoIP-Telefonen, sind jedoch nicht immer gleich eingestellt. Häufig werden Neuübertragungen gleichzeitig an Telefone gesendet, die an denselben Switch angeschlossen sind. Manchmal werden Neuübertragungen jedoch auch gleichzeitig an Telefone an entgegengesetzten Enden des Netzwerks gesendet. Bei der Weiterleitung von TCP-Datenverkehr kommt es normalerweise zu einigen gleichzeitigen Neuübertragungen, beispielsweise zwischen Client-Computern und den Dateiservern.

Die Spitzenwerte bei erneuten Übertragungen und Zurücksetzen des Telefons korrelieren nicht gut mit einer hohen Netzwerkbelastung. Sie scheinen tagsüber etwas häufiger aufzutreten, aber meistens abends, wenn der Verkehr abnehmen sollte. Sie treten relativ oft spät in der Nacht auf, wenn die meisten Computer ausgeschaltet sind und der Datenverkehr am geringsten sein sollte.

Haben Sie Ideen, die Ihnen bei der Diagnose der Ursache solcher Probleme helfen könnten? Eine Sache, die ich noch nicht ausprobiert habe, aber sollte, ist die Aktualisierung der Firmware aller Switches.

networking tcp voip

— Surreal
quelle

1

Welches Modell wechselt? Wie sehen Prozessor-, Speicher- usw. Statistiken aus? Sind Sie in einer Broadcast-Domain? Wie nahe kommt der maximale Durchsatz im Netzwerk?

— Zypher

Welches VoIP-Protokoll verwenden Sie? Verwenden Sie auch UDP oder TCP?

— Chris S

Alle Schalter sind 3Com: Baseline 2924 - PWR Plus (3CBLSG24PWR) x 2, 4200 (3C17304A) x 3, 4200 (3C17304) x 2, 2824-SPF Plus (3C16487), 2250 plus (3C16476CS). Ich glaube nicht, dass sie Angaben zu Prozessor oder Speicher machen, aber ich würde mich sehr freuen, wenn ich etwas anderes erfahren würde. Ja, wir sind in einer Broadcast-Domain. Ich weiß nichts über den Durchsatz, ich werde mich darum kümmern, ihn zu messen.

— Surreal

17

TCP-Neuübertragungen sind normalerweise auf eine Überlastung des Netzwerks zurückzuführen. Suchen Sie zum Zeitpunkt des Problems nach einer großen Anzahl von Broadcast-Paketen. Wenn der Prozentsatz des Broadcast-Verkehrs in Ihrer Erfassung über 3% des gesamten erfassten Verkehrs liegt, liegt definitiv eine Überlastung vor. Suchen Sie im Netzwerk nach Broadcasts der physischen Schicht (ARP) und der Netzwerkschicht (Namensauflösung). Wenn Sie ein hohes Broadcast-Verkehrsaufkommen feststellen, können Sie es anhand der Erfassungsdaten zur Quelle zurückverfolgen.

— Joeqwerty
quelle

9

Darüber hinaus sind die TCP-Neuübertragungen nicht die Ursache für Ihr Problem, sondern ein Symptom für das Problem.

— Joeqwerty

Ich hätte erwähnen sollen, dass ich mir die UDP-Broadcasts angesehen habe und sie nicht mit den Neuübertragungen korrelierten. Einige der Neuübertragungsereignisse stimmen mit Spitzen in UDP-Broadcasts überein, die meisten jedoch nicht. Ich habe noch einmal nachgesehen und festgestellt, dass UDP-Broadcasts nicht mehr als 1,5% des Datenverkehrs (ca. 350 Pakete) in einem 10-Minuten-Zeitsegment ausmachen, und dieses Niveau zu erreichen ist selten. Ich hatte mir jedoch keine Ethernet-Sendungen angesehen. Ich führe jetzt ein Skript aus, um alle meine Wireshark-Protokolle zu filtern. Ist die Faustregel von 3% für UDP-Broadcasts und Ethernet-Broadcasts einzeln oder kombiniert?

— Surreal

1

Die 3% sind keine Faustregel. Es ist das, was mir gesagt wurde und was ich in meiner eigenen Umgebung gesehen habe. Ich habe Zahlen im Bereich von 10 bis 20% gehört, aber ich habe festgestellt, dass es normalerweise Probleme verursacht, wenn es 3 bis 5% überschreitet. Sie müssen sich den gesamten Broadcast-Verkehr ansehen: Ethernet-, Netzwerk- und Multicast-Broadcasts, da sie alle zu Überlastungen führen können. Grundsätzlich handelt es sich bei jedem Datenverkehr, der an alle Switch-Ports gesendet wird, um Datenverkehr, der analysiert und reduziert oder beseitigt werden muss.

— Joeqwerty

Ich habe immer noch kein hübsches Diagramm zusammengestellt, um über einen langen Zeitraum nach einer guten Korrelation zu suchen, aber Ethernet-Sendungen sehen recht vielversprechend aus. Ein Protokoll mit erneuter Übertragung wies knapp über 3% Sendungen auf, ein anderes etwa 6%. Ich habe zumindest ein Problem gefunden: Ein alter Server gibt einen konstanten Strom von kostenlosen ARP-Paketen aus.

— Surreal

1

Ich fand die übermäßigen ARP-Einträge mit dem Wireshark-Filter von arp- und um nur die gesendeten zu sehen, mit einem Filter voneth.addr==ff:ff:ff:ff:ff:ff

— mlhDev

2

Wenn Sie Verkehrsstatistiken für Ihre Switches erstellen, können Sie feststellen, dass Sie in bestimmten Zeiträumen über oder nahezu überlastet sind. Dies kann zu erneuten Versuchen führen, wenn die Antworten nicht innerhalb des anfänglichen Zeitlimits (häufig 3 Sekunden) zurückkommen. Dies erhöht die Überlastung vorübergehend, bis die Mechanismen zur Reduzierung der Überlastung greifen.

Suchen Sie nach Personen, die Streaming-Medien verwenden, da diese die Bandbreite schnell aufsaugen können.

Möglicherweise können Sie das Problem für die Telefone durch Traffic-Shaping abmildern. Dadurch wird das Problem nur auf andere Benutzer übertragen.

— BillThor
quelle

2

Klingt für mich wie eine Spanning Tree-Schleife oder ein Broadcast-Sturm, besonders wenn die Neuübertragungen und die Probleme auf demselben Switch lokalisiert sind (was sich unterscheidet). Wie lauten die Portstatus auf Ihrem L2-Gerät, wenn dies passiert? Wahrscheinlich ein schlechter Switch oder eine schlechte Root-Bridge-Priorität? Interessantes Problem.

— McJeff
quelle

Vielen Dank, dass Sie mich veranlasst haben, mich über Bäume zu informieren, über die ich peinlich unwissend bin. Ich glaube jedoch nicht, dass es sich um eine Spanning Tree-Schleife handeln könnte, da wir keine redundanten Verbindungen in unserem Netzwerk haben (möglicherweise ein Problem an sich). Mit "Portstatus auf Ihrem L2-Gerät" meine ich, welche Ports die Switches aufgrund des Spanning Tree-Algorithmus aktiviert haben. Wir haben keine Root-Bridge manuell konfiguriert. Wäre es eine gute Idee, dies zu tun?

— Surreal

Sich mit STP vertraut zu machen ist eine gute Idee, aber wenn Sie sicher sind, dass Sie keine redundanten Links haben, wird STP nicht das Problem sein.

— Joeqwerty

Ja, wenn Sie keine redundanten Links haben, wäre das kein Problem. Mit Hafenstaaten meine ich ja, welche sind vorwärts / blockiert / lernend.

— McJeff

2

Sie haben das Problem wahrscheinlich gelöst, seit es so lange her ist, aber im Grunde müssen Sie "Port Fast" für die Ports aktivieren, die Endpunkte haben (VoIP-Telefone, Workstations, Server). Ein Telefon kann PDUs senden. Wenn dieser Typ also neu startet, kommt es zu einer STP-Konvergenz. Dadurch wird die FDB-Tabelle geleert und alle Geräte durchlaufen den 4/5-STP-Spaß. Indem sie Ports mit Endpunkt in "Port Fast" setzen, überspringen sie das Warten und gehen direkt in den Weiterleitungsmodus.

— Barak s.
quelle

1

Hoffentlich befinden sich Ihre Telefone in einem anderen Subnetz und VLAN als die anderen Computer?

— Greg Askew
quelle

Nein, sie befinden sich im selben IP-Subnetz, und ich bin mir ziemlich sicher, dass auch dasselbe VLAN vorhanden ist. Ist das ein ernstes Problem? Es klingt auf jeden Fall so, als wäre es eine gute Idee. Ich kann sehen, es würde die Broadcast-Domänen für Telefone und alles andere trennen. Hätte es noch andere Vorteile?

— Surreal

Ja, ich würde die Telefone definitiv in ein dediziertes VLAN stellen.

— Greg Askew

1

Es könnte sich auch um ein defektes Gerät handeln, beispielsweise um einen defekten Schalter. Korrelieren die erneuten Übertragungen mit Telefonen / Computern auf einem bestimmten Switch oder Teil des Netzwerks?

Nur um meine Antwort ein wenig zu erweitern. Nicht alle Schalter sind gleich, auch wenn sie dieselben Spezifikationen haben. Einige sind in der Lage, eine viel höhere Last zu bewältigen als andere, weil sie schnellere Prozessoren im Inneren haben. Es kann sein, dass Ihre Schalter nicht ganz auf dem neuesten Stand sind.

Ich würde damit beginnen, einige Ihrer schwierigsten VOIP-Telefone an ihren eigenen physischen Schalter anzuschließen und zu prüfen, ob die Zurücksetzungen auf diesen fortgesetzt werden. Wenn es verschwindet, sind Sie auf dem Weg, es sehr bald zu lösen.

— Matt
quelle

Ich wünschte, sie hätten es getan. Es scheint das größte Problem mit Geräten zu geben, die an zwei Switches angeschlossen sind, die sich an entgegengesetzten Enden des Netzwerks befinden. Es gibt jedoch auch erhebliche Neuübertragungen an Telefone in anderen Teilen des Netzwerks.

— Surreal