In diesem konkreten Testfall haben wir einen Xena VulcanBay mit 2x 40 Gbps QSFP+ Interfaces verwendet, um einige Next-Generation Firewalls bezüglich ihrer Performance zu testen. Konkret waren wir an folgenden Testszenarien interessiert:

• Reiner Durchsatz (Throughput)
• Hohe Anzahl von Verbindungen (Session Load)
• Einsatz von NAT
• Realistischer Traffic
• Längere Testzeiträume, währenddessen wir neue Firewallregeln “gepusht” haben, um potentielle Einbrüche im Durchsatz feststellen zu können

In diesem Beitrag wollen wir zeigen, wie wir den Xena VulcanBay inkl. dessen Management, dem VulcanManager, sowie einen Cisco Nexus Switch zum Verbinden der Firewall-Cluster eingesetzt haben. Wir listen unsere Testszenarien auf und geben ein paar Hinweise zu potentiellen Stolpersteinen.

Für unsere Tests hatten wir einen Xena VulcanBay Vul-28PE-40G mit Firmware Version 3.6.0, Lizenzen für die beiden 40 G Interfaces sowie die vollen 28 Packet Engines zur Verfügung. Der VulcanManager lief auf Version 2.1.23.0. Da wir nur einen einzelnen VulcanBay (und nicht mehrere an verteilten Standorten) verwendet haben, konnte der einzige Admin-User die vollen 28 Packet Engines auf diese beiden Ports gleichermaßen verteilen.

Für Tests mit bis zu 80 G Durchsatz reichten zwei QSFP+ Module (links) sowie die Verteilung der Packet Engines auf eben diese Ports (rechts).

Für den Anschluss des VulcanBays an die jeweiligen Firewall-Cluster haben wir einen einzelnen Cisco Nexus Switch mit genügend QSFP+ Modulen und entsprechendem Durchsatz verwendet. Da wir alle Firewall-Cluster als auch den VulcanBay gleichzeitig an diesen Switch angeschlossen hatten, und für die Tests stets die gleichen IPv4/IPv6 Adressbereiche genommen hatten, konnten wir rein mit dem “shutdown / no shutdown” einzelner Interfaces darüber entscheiden, welchen Firewallhersteller wir nun testen wollten. Somit war das komplette Labor aus der Ferne steuerbar. Sehr praktisch für den typischen Fall eines Homeoffice Mitarbeiters. Außerdem war es so einfach möglich, den VulcanBay auch “mit sich selbst” zu verbinden, um aussagekräftige Referenzwerte aller Tests zu bekommen. Hierfür wurden temporär beide 40 G Interface zum VulcanBay in das gleiche VLAN konfiguriert.

Mit jeweils zwei Leitungen für Client und Server wurden alle Firewall Cluster an einen zentralen Switch gekoppelt. Ebenso der VulcanBay von Neox Networks.

Dank moderner QSFP+ Slots mit 40 G Interfaces erreicht man mit nur zwei Anschlüssen einen Duplex Durchsatz von 80 Gbit/s.

In unserem Fall wollten wir verschiedene Firewalls im Layer 3 Modus testen. Um dieses “Device Under Test” (DUT) routingtechnisch einzubinden haben wir entsprechende Subnetze angelegt – sowohl für das veraltete IPv4 Protokoll als auch für IPv6. Die vom VulcanBay simulierten IP Subnetze liegen nachher an der Firewall direkt an. Im Falle eines /16er IPv4 Netztes muss also genau dieses /16 Netz auch an der Firewall konfiguriert werden. Wichtig ist vor allem der Default Gateway, beispielsweise 10.0.0..1 für das Client IPv4 Netz. Verwendet man zusätzlich die Option “Use ARP” (rechte Seite), muss man sich um die eingeblendeten MAC Adressen nicht kümmern. Der VulcanBay löst diese selbst auf.

Der Adressbereich muss zwingend angepasst werden, damit die durchgeführten Tests nicht einem MAC Flooding gleichkommen.

Bei IPv6 verhält es sich gleichermaßen. Hier wird das Netzwerk nicht in der sonst üblichen Slash-Notation eingegeben, sondern einfach nur der Gateway und der Address Range bestimmt. Per “Use NDP” löst auch hier der VulcanBay die Layer 2 MAC-Adresse zur Layer 3 IPv6-Adresse selbstständig auf.

Per “Use Gateway” teil man dem VulcanBay mit, dass ein dazwischenliegender Router/Firewall für die Tests verwendet werden soll.

1) Reiner Durchsatz (Throughput): In dem ersten Testszenario ging es uns rein um den Durchsatz der Firewalls. Hierfür haben wir das Szenario “Pattern” gewählt, einmal für IPv4 und einmal für IPv6, was automatisch die Ratio auf 50-50 legt. In den Einstellungen haben wir zusätzlich “Bidirectional” ausgewählt um in beiden Fällen Daten in beide Richtungen, also Duplex, durchzuschieben. So konnten wir mit den 2x 40 G Interfaces den maximalen Durchsatz von vollen 80 G erreichen. Um die Bandbreite über mehrere Sessions zu verteilen (was im echten Leben der realistischere Testfall ist), wählten wir 1000 User aus, welche jeweils von 100 Source Ports zu 10 Servern Verbindungen aufbauen sollten. Macht für IPv4 und IPv6 jeweils 1 Million Sessions. Bei einer Ramp-Up Time von 5 Sekunden, also einem sanften Anstieg der Verbindungen anstelle der sofortigen vollen Last, lief der reine Test danach 120 Sekunden durch, bevor er ebenfalls eine Ramp-Down Time von 5 Sekunden hatte.

Testszenario “Pattern” mit einer 50-50 Verteilung von IPv4 und IPv6. Das “Load Profile” (rechts) zeigt die zu simulierenden User anhand der Zeitachse.

Während des Tests zeigt der VulcanManager bereits einige nützliche Daten an, wie beispielsweise die TCP Connections oder den Layer 1 Durchsatz. Anhand der Grafiken im oberen Bereicht bekommt man auf einen Blick einen guten Eindruck. Im folgenden Screenshot lässt sich so erkennen, dass die Anzahl der aktiven Verbindungen weniger als die Hälfte der geplanten schafft (schlecht), während der Layer 5-7 Goodput einen unschönen Knick zu Beginn des Tests hat. Beide Probleme haben sich im Nachgang als Fehler bei der IPv6 Implementation des getesteten Geräts herausgestellt.

Während theoretisch 2 Millionen Sessions bei 80 G Durchsatz die Firewall hätten passieren sollen, ist hier weniger als die Hälfte sauber durchgekommen.

2) Hohe Anzahl von Verbindungen (Session Load): Ebenfalls für IPv4 und IPv6 wurden bei diesem Test 20 Millionen parallele TCP Sitzungen aufgebaut und aufrechterhalten. Nicht nur die Summe der Sessions war relevant, sondern vor allem die kurze Ramp-Up Zeit von nur 30 Sekunden, was einem Aufbaurate von 667.000 Verbindungen pro Sekunde entsprach! Für 60 Sekunden wurden die Sessions stehen gelassen, jedoch ohne Daten zu transferieren. Über weitere 30 Sekunden wurden sie, TCP-typisch per FIN-ACK, wieder abgebaut. Ziel war es, dass die zu testenden Firewalls erstens die Verbindungen alle sauber durchließen und sie zweitens auch wieder sauber aubbauen (und somit ihren Speicher freigeben) konnten.

3) NAT Szenarien: Hierbei wurde genau der gleiche Test wie unter 1) verwendet, mit dem einzigen Unterschied, dass die IPv4 Verbindungen vom Client- zum Servernetz mit einem Source-NAT auf den Firewalls versehen wurden. Ziel war es herauszufinden, ob dies eine Leistungsverringerung bei den Firewalls verursacht.

4) Realistischer Traffic: Per vordefiniertem “Datacenter Mix” konnten wir mit wenigen Klicks den Ablauf von zwei HTTPS, SMB2, LDAP und AFS (über UDP und TCP) Verbindungen für mehrere Tausend Nutzer simulieren. Hierbei ging es nicht um einen vollen Lasttest der Firewalls, sondern um die Auf- und Abbaugeschwindigkeiten sowie die Applikationserkennungen. Je nachdem, ob die App-IDs der Firewalls aktiviert oder deaktiviert waren, gab es hier große Unterschiede.

5) 10 Minuten Dauerfeuer mit Commits: Dieser etwas speziellere Tests bestand aus den Szenarien 1 und 4, also volle Last (1) bei gleichzeitig konstantem Session Auf- und Abbau (4). Dies lief für 10 Minuten konstant durch, während wir weitere 500 Regeln auf die jeweilige Firewall installiert haben. Hierbei wollten wir herausfinden, ob dieser Prozess auf den Firewalls einen messbaren Knick in dem Durchsatz erzeugt, was teilweise auch der Fall war.

Am Ende eines jeden Tests zeigt der VulcanManager die “Statistics and Reporting” Seite mit allen erdenklichen Details an. Per “Create Report” lässt man sich ein PDF erstellen, was neben allen Details auch Informationen über das gewählte Testszenario sowie Angaben zu dem getesteten Gerät beinhält. Die Herausforderung besteht darin, die relevanten von den weniger relevanten Zahlen zu unterscheiden und sie in den richtigen Kontext zu stellen um letztendlich aussagekräftige Ergebnisse zu bekommen. Während unserer Vergleiche von verschiedenen Next-Generation Firewalls beschränkten wir uns beispielsweise rein auf den “Layer 1 steady throughput (bps)” für den Durchsatz-Test, oder die “Successful TCP Connections” für den Verbindungs-Test. Verglichen mit den Referenzwerten bei denen der VulcanBay mit sich selbst verbunden war, gab dies bereits sinnvoll vergleichbare Ergebnisse, die sich sowohl tabellarisch als auch grafisch einfach darstellen ließen.

Die Statistics and Reporting Seite gibt neben einem groben Überblick (Mitte) die Möglichkeit, Testwerte aus allen OSI-Schichten und der gewählten Testszenarios auszulesen (Links, aufklappbare Reiter).

Ausschnitt eines PDF Reports mit allen Details.

Beachten Sie, dass der VulcanManager einige weitere interessante Funktionen hat, die wir in dieser Fallstudie nicht verwendet haben, wie TLS Traffic (zum Testen von TLS-Interception) und Packet Replay (zum Testen eigener und spezifischerer Szenarien, die aus hochgeladenen PCAPs extrahiert werden). Auch haben wir nicht viele anwendungs- oder protokollorientierte Testszenarien wie Dropbox, eBay, LinkedIn oder HTTPS, IMAP, NFS genutzt. Dies ist auf unsere Testzwecke zurückzuführen, die stark auf den reinen Durchsatz und Anzahl der Sessions fokussiert waren.

Der VulcanBay von XENA Networks ist das ideale Testgerät für die Vergleiche diverser Next-Generation Firewalls. Innerhalb kürzester Zeit hatten wir diverse Testszenarien konfiguriert und getestet. Lediglich die Fülle an Testergebnissen war anfänglich überfordernd. Die Kunst bestand darin, sich gezielt auf die relevanten Informationen zu konzentrieren.

Wireshark ist ein weit verbreiteter Netzwerkprotokollanalysator, mit dem Benutzer auf mikroskopischer Ebene sehen können, was in ihren Netzwerken passiert. Er ist der De-facto-Standard bei vielen kommerziellen und gemeinnützigen Unternehmen, Regierungsbehörden und Bildungseinrichtungen für die Fehlersuche und Protokollanalyse.

Wireshark verfügt über einen umfangreichen Funktionsumfang, welcher eine gründliche Inspektion von Hunderten von Protokollen, Live-Capture und Offline-Analyse umfasst. So leistungsfähig Wireshark bei der Inspektion und Analyse von Netzwerkprotokollen auch ist, es wird nur so effektiv sein wie seine Implementierung.

Die Fähigkeit, Datenverkehr verlustfrei aufzuzeichnen und zu analysieren, ist von größter Bedeutung für den Erfolg von Wireshark. Um den gesamten Verkehr auszuwerten, ist es eine grundlegende Anforderung, dass Wireshark “alles sieht”. Sollten einzelne Datenpakete nicht erfasst werden, ist eine vollständige Protokollanalyse nicht möglich. Und wenn der Capture-Server überlastet und zu langsam ist, um die eingehende Paketrate zu verarbeiten, werden Pakete verworfen und die darin enthaltenen Informationen gehen für immer verloren.

Aber die Untersuchung des Inhalts jedes Netzwerkpakets ist extrem CPU-intensiv, insbesondere bei einer Multi-Gigabit Netzwerkauslastung. Und das ist der limitierende Faktor in der Wireshark-Performance: die Paketverarbeitung mittels CPU.

Um dieser Herausforderung zu begegnen, hat Napatech eine Hardwarebeschleunigungslösung auf Basis der Napatech Link™ Capture Software entwickelt, welche die CPU entlastet und damit die Capture Performance von Wireshark deutlich erhöht.

• Verlustfreie Erfassung und Protokolldekodierung für bis zu 13 Gbit/s auf einem einzigen Thread zur Verkehrsanalyse, Inspektion und Erkennung
• Onboard-Paketpufferung während Micro-Burst- oder PCI-Express-Busüberlastungsszenarien
• Erweiterte Hostspeicher-Pufferverwaltung für extrem hohe CPU-Cacheleistung
• Paketklassifizierung, Match-/Aktionsfilterung und Null-Kopie-Weiterleitung
• Intelligente und flexible Lastverteilung auf bis zu 64 Queues, die die CPU-Cache-Leistung verbessert, indem sie immer die gleichen Abläufe an die gleichen Kerne liefert

Die Napatech Link™ Capture Software erhöht die Capture Performance und Protokollanalyse drastisch und ermöglicht es Netzwerkingenieuren, die volle Leistung von Wireshark zu nutzen, um den Netzwerkverkehr zu verstehen, Anomalien zu finden und Netzwerkprobleme mit unglaublicher Geschwindigkeit zu diagnostizieren. Die Lösung entlastet die Anwendungssoftware von der Verarbeitung und Analyse des Netzwerkverkehrs und sorgt gleichzeitig für eine optimale Nutzung der Ressourcen der Hardware, was zu einer effektiveren Nutzung von Wireshark führt.

Optimiert für die Erfassung des gesamten Netzwerkverkehrs bei voller Auslastung der Netzwerkleitung und nahezu ohne CPU-Belastung des Hostservers, weist die Lösung enormeLeistungsvorteile für Wireshark auf: bis zu 14-fache verlustfreie Aufzeichnungs- und Dekodierleistung im Vergleich zu einer Standard-Netzwerkschnittstellenkarte (NIC).

Diese Leistungsvorteile ermöglichen Ihnen letztendlich folgendes:

• Maximieren Sie Ihre Serverleistung, indem Sie die CPU-Auslastung verbessern
• Minimieren Sie Ihre Gesamtbetriebskosten, indem Sie die Anzahl der Server reduzieren und so den Rackspace, Stromverbrauch, Kühlung und die Betriebskosten optimieren
• Verkürzen Sie Ihre Time-to-Resolution und ermöglichen Sie so eine deutlich höhere Effizienz

Die herausragenden Verbesserungen, die mit dieser Lösung erzielt wurden, wurden durch den Vergleich der Wireshark-Leistung auf einem Dell PowerEdge R740 mit einer Standard 40G NIC-Karte und der Napatech NT200 SmartNIC mit Link™ Capture Software demonstriert. Testkonfiguration: Dual-Sockel Dell R740 mit Intel® Xeon® Gold 6138 2,0 GHz, 128GB RAM mit Ubuntu 14.04 LTS.

Für den verlustfreien Durchsatztest wurde Datenverkehr mit festen Raten und Paketgrößen gesendet und der Durchsatz als die Rate gemessen, mit der Wireshark die Pakete empfangen und analysieren kann.

Zusätzliche Tests für “Back-to-Back-Frames” wurden wie in der RFC 2544 Benchmarking-Methodik beschrieben durchgeführt, um einen Burst von Frames mit minimalem Inter-Frame-Gap an das „Device Under Test“ (DUT) zu senden und die Anzahl der vom DUT empfangenen/weitergeleiteten Frames zu zählen. Der Back-to-Back-Wert ist definiert als die Anzahl der Frames im längsten Burst, die das DUT ohne den Verlust von Frames verarbeiten kann. Mit gleich großen Capture-Pufferkonfigurationen bietet die Napatech SmartNIC eine 60-mal höhere Back-to-Back-Frame-Leistung. Bei Bedarf für stark gebündelte Datenverkehrsmuster kann die Napatech-Lösung deutlich größere Host-Puffer zuweisen, die eine hundertmal höhere Back-to-Back-Capture Performance bieten.

Die atemberaubenden Benchmarks für Wireshark wurden durch den Einsatz der Reconfigurable Computing Platform von Napatech erreicht, die auf FPGA-basierter Link™ Capture Software und Napatech SmartNIC Hardware basiert.

Die Reconfigurable Computing Platform von Napatech entlastet, beschleunigt und sichert flexibel offene, standardisierte, hochvolumige und kostengünstige Serverplattformen, so dass sie die Leistungsanforderungen für Netzwerk-, Kommunikations- und Cybersicherheitsanwendungen erfüllen können.

Wireshark, einer der führenden Netzwerkprotokollanalysatoren der Branche, ist ein ideales Beispiel für die Art von kritischen Unternehmensanwendungen, die durch Hardwarebeschleunigung mit der Napatech LinkTM Capture Software eine bessere Leistung erzielen können.

Wireshark kann mit nativer Unterstützung für Hardwarebeschleunigung auf Basis der Intel-Hardware und Napatech-Software kompiliert werden. Spezifische Anweisungen zur Implementierung von Wireshark mit Unterstützung für Napatech finden Sie in der Installations-Kurzanleitung, die im Napatech-Dokumentationsportal verfügbar ist.

Sie sagen die Wahrheit, sofern sie nicht falsch erfasst wurden. In diesen Fällen können Pakete in der Tat fett gedruckte Lügen erzählen.

Beim Durchsuchen von Trace-Dateien können wir in den Paketen auf Symptome stoßen, bei denen so mancher überrascht die Stirn runzeln würde. Dies sind Ereignisse, die auf der Oberfläche seltsam erscheinen und sogar unsere Fehlerbehebung für eine Zeit ablenken können. Einige dieser Probleme haben tatsächlich Netzwerk Analysten stundenlang irregeleitet, wenn nicht sogar Tage, wodurch sie Problemen und Ereignissen nachgejagt haben, die einfach nicht im Netzwerk existieren.

Die meisten dieser Beispiele können einfach vermieden werden, indem die Pakete von einem Netzwerk Test Access Point (TAP) aus erfasst werden, anstatt auf dem Rechner, auf dem der Verkehr erzeugt wird. Mit einem Netzwerk TAP können Sie die Netzwerkdaten transparent und unverfälscht erfassen und sehen was wirklich über die Leitung übertragen wird.

Sehr große Pakete

In den meisten Fällen sollten Pakete nicht größer als das Ethernet-Maximum von 1518 Bytes sein, oder das was für die Link-MTU festgelegt wurde. Dies gilt jedoch nur dann, wenn wir nicht mit 802. 1Q-Tags verwenden oder uns in einer Jumbo Frame Umgebung befinden.

Wie ist es möglich Pakete zu haben, die größer sind als das Ethernet-Maximum? Einfach ausgedrückt, wir erfassen sie, bevor sie von der NIC segmentiert werden. Viele TCP/IP-Stacks verwenden heutzutage TCP Segmentation Offload, welche die Last der Segmentierung von Paketen an die NIC delegiert. Der WinPcap- oder Libpcap-Treiber erfasst die Pakete, bevor dieser Vorgang stattfindet, sodass einige der Pakete viel zu groß erscheinen können, um legitim zu sein. Wenn die gleiche Aktivität auf dem Netzwerk erfasst wurde, würden diese großen Frames für den Transport in mehrere kleinere segmentiert.

Zero Delta Zeiten

Zero Delta Zeiten bedeutet, dass es keine gemessene Zeit zwischen den Paketen gibt. Wenn diese Pakete in das Erfassungsgerät gelangen, erhalten sie einen Zeitstempel und eine messbare Delta Zeit. Der Zeitstempel für den Eintritt auf dem Erfassungsgerät konnte nicht mit dem Paketaufkommen mithalten. Würden diese Pakete hingegen mit einem externen Tap-Server erfasst, könnten wir wahrscheinlich eine fehlerfreie Zeitstempelung erhalten.

Vorherige Pakete nicht erfasst

Diese Warnung wird angezeigt, weil Wireshark eine Lücke im TCP-Datenstrom bemerkt hat. Es kann anhand der sequenzierten Zahlen feststellen, dass ein Paket fehlt. Manchmal ist dies aufgrund des Upstream-Paketverlusts berechtigt. Allerdings kann es auch ein Symptom sein, dass der Analysator oder SPAN das Paket fallen gelassen hat, weil es nicht mit der Belastung mithalten konnte.

Nach dieser Warnung sollten Sie nach einer Reihe von doppelten ACK-Paketen suchen, anstatt eines defekten Pakets. Dies deutet darauf hin, dass ein Paket tatsächlich

verloren gegangen ist und erneut übertragen werden muss. Wenn Sie keine erneute Übertragung oder defekte Pakete sehen, konnte der Analyzer oder SPAN wahrscheinlich nicht mit dem Datenstrom mithalten. Das Paket war tatsächlich im Netzwerk, aber wir haben es nicht gesehen.

TCP ACKed unbemerkte Segmente

In diesem Fall wird eine Bestätigung für ein Datenpaket angezeigt, das nicht erfasst wurde. Das Datenpaket hat eventuell einen anderen Weg genommen, oder das Erfassungsgerät hat es einfach nicht wahrgenommen.

Vor Kurzem habe ich diese Ereignisse bei Trace-Dateien gesehen, die von Switches, Routern und Firewalls erfasst wurden. Da die Erfassung von Datenverkehr eine niedrigere Priorität als eine Weiterleitung hat (Gott sei Dank!), kann das Gerät schlichtweg einige der Frames im Datenstrom übersehen. Da wir die Bestätigung gesehen haben, wissen wir, dass das Paket es zu seinem Bestimmungsort geschafft hat.

Zum größten Teil sagen Pakete die Wahrheit. Sie können uns zur Hauptursache unserer Netzwerk- und Anwendungsprobleme führen. Da sie solche klaren und detaillierten Daten präsentieren, ist es sehr wichtig, dass wir sie so nah am Netzwerk wie möglich aufzeichnen. Das bedeutet, dass wir sie während der Übertragung erfassen müssen, und nicht auf dem Server selbst. Dies hilft uns dabei, keine Zeit mit falschen Negativwerten zu verschwenden.

Wenn Sie mehr über die Berücksichtigungen von Netzwerkvisualisierungen für Fachleute erfahren möchten, dann laden Sie unsere kostenlose Informationsschrift herunter, TAP vs SPAN.

https://www.garlandtechnology.com/tap_vs_span_lp

Was kann bei einem TCP-Handshake schief gehen?

Hier ist der erster Artikel einer Serie, die alle Informationen enthält, die Sie zur Behebung von Leistungsproblemen von Anwendungen benötigen, welche auf dem TCP-Protokoll basieren.

Schauen wir uns an, wie TCP-Sessions aufgebaut werden … und was schief gehen kann!

Das TCP-Protokoll ist ein verbindungsorientiertes Protokoll, was bedeutet, dass eine Verbindung aufgebaut und aufrechterhalten wird, bis die Anwendungsprogramme an jedem Ende den Austausch von Nachrichten abgeschlossen haben. TCP arbeitet mit dem Internet Protocol (IP).

TCP bietet eine zuverlässige, geordnete und fehlerfreie Übertragung. Um dies zu tun, besitzt TCP einige Funktionen, wie zum Beispiel Handshake, Reset, Fin, Ack, Push-Pakete und andere Arten von Flags, um die Verbindung aufrechtzuerhalten und keine Informationen zu verlieren.

TCP wird mit vielen funktionellen Protokollen verwendet, wie beispielsweise HTTP. Daher ist es wichtig zu wissen, wie TCP-Probleme diagnostiziert werden können. In dieser Artikelserie werden wir diese TCP-Metainformationen erläutern und erklären, warum sie für eine Fehlerbehebung wichtig sind und wie sie mit PerformanceVision (PV) ganz leicht gemessen werden können.

Wie wird eine Session gestartet? TCP-Handshake und Verbindungszeit

Eine TCP-Verbindung, die auch als 3-Wege-Handshake bezeichnet wird, erfolgt über SYN, SYN + ACK und ACK-Pakete. Aus diesem Handshake können wir eine Leistungsmetrik mit dem Namen Connection Time (CT) ermitteln, die zusammenfasst, wie schnelle eine Session zwischen einem Client und einem Server über ein Netzwerk aufgebaut werden kann. Weitere Informationen finden Sie in diesem hervorragendem Artikel auf Wikipedia.

Abb.1 – Wie TCP Handshakes analysiert werden

Die drei Schritte eines TCP-Handshakes sind:

1. Das ‘SYN’ ist das erste Paket, das von einem Client an einen Server gesendet wird, es verlangt buchstäblich von einem Server, eine Verbindung mit ihm aufzubauen.

2. Wenn es möglich ist, antwortet der Server mit einem "SYN + ACK", was bedeutet, "Ich haben Ihre ‘SYN’ erhalten und ich bin damit EINVERSTANDEN"

3. Schließlich sendet der Client ein ‘ACK’, um die Verbindung zu bestätigen.

Wie TCP-Verbindungsfehler diagnostiziert werden

1 – SYN ohne Verbindungen

Die erste Sache, die Sie mit PV leicht diagnostizieren können, lautet: "Können meine Clients eine Verbindung zu meinen Servern herstellen?" Gehen Sie im PV-Menü zu Applikation – → Clients, wählen die Registerkarte TCP und setzen den Filter mit dem Namen “Nur einseitigen Fluss". Dadurch sehen wir nur den Verkehr vom Client zum Server und keine Antwort vom Server.

Abb.2 – Nur auf einseitige Flows filtern

Dies bedeutet, dass Sie nur die Top-Client-IPs mit nur einem Fluss vom Client und ohne Antwort sehen möchten.

Abb.3 – PV hat einseitige Flows gefunden und diese sortiert

Wie Sie auf den obigen Ergebnissen sehen können, gibt es mehrere IPs, die eine Verbindung zu einem Server (SYN> 0) fordern, aber keine Verbindung zu ihnen herstellen können (Connections = 0).

Hier sind häufige Fehlerfälle:

• Eine Firewall verweigert diese Verbindungen – Sie können dieselbe Anfrage auf Client Zones (im selben Menü) anwenden, um festzustellen, ob sich die IPs in derselben Zone befinden.
• Der Server existiert nicht mehr oder ist nicht verfügbar – dies geschieht häufig, wenn eine Server-IP geändert wird, aber einige Clients auch weiterhin die alte IP anfragen.

2 – Schlechte Verbindungsraten

In einer perfekten Welt sollten Sie 1 ‘SYN’ pro TCP-Verbindung erhalten. PV stellt eine Metrik zur Verfügung, um diese Verbindungseffizienz zu sehen, was durch eine ‘SYN’ pro Verbindungsrate (dies entspricht der Anzahl der SYN-Pakete, die mit der Anzahl der TCP-Sitzungen verglichen werden, die eingerichtet wurden) dargestellt wird. Diese Metrik befindet sich in den "Details" Tabellen und kann über die Registerkarte "TCP" geöffnet werden. Sie können auch die zeitliche Entwicklung über Anwendung → benutzerdefinierte Diagramme grafisch darstellen.

Abb.4 – PV benutzerdefinierte SYN/Conn Tabellen

Eine schlechte “SYN”-Effizienz kann manchmal auch durch ein Netzwerkproblem ausgelöst werden. Somit wird die Fehlverbindung durch einen Paketverlust oder Kontingenz verursacht. Sie können diese Vermutung überprüfen, indem Sie die Verbindungszeit betrachten. Wenn diese niedrig bleibt und sich auf mehrere Hosts auswirkt, dann ist es wahrscheinlich ein Netzwerkproblem.

Wenn hingegen die Verbindungszeit hoch ist, aber das Problem beim Server liegt, ist dieser überlastet und kann nicht auf alle Clientanfragen antworten. Wenn schließlich die ‘SYN’-Rate sehr groß ist, dann könnten Sie Sicherheitsprobleme haben, wie zum Beispiel einen DDOS-Angriff.

Abb.5 – Eine Fehlerdiagnose von Verbindungen durch Verbindungszeiten und SYN-Raten

Fazit

In diesem ersten Artikel sahen wir eine kurze Darstellung der TCP-Leistungsmetriken und wie das TCP-Protokoll die Verbindungen mit SYN/SYN + ACK/ACK-Paketen verarbeitet. Wir sehen auch einige häufige Fehlerfälle, die leicht mit PerformanceVision diagnostiziert werden können.

Um diese Art von Problemen zu beheben, verwendeten wir die Page Top Clients, Top Client Zones und Custom Charts. Um einen Schritt weiter zu gehen, haben wir "Advanced Filter: Unilateral Flows" verwendet, um Flows ohne Antworten zu filtern.Wir haben zudem mehrere Metriken vorgestellt: die Anzahl der ‘SYN’ und ‘Handshakes’ (Verbindungen), die SYN-Effizienz und die Verbindungszeit. In nächsten Artikel werden wir einen Blick darauf werfen, wie Sie eine Verbindung mit Reset- und Fin-Paketen beenden können.

In der Zwischenzeit; falls Sie es ausprobieren möchten, können Sie einfach unsere Evaluation Virtual Appliance herunterladen:

Ein Microburst ist eine lokale und plötzlich auftretende Fallbö (Downdraft) innerhalb eines Gewitters, die in der Regel einen Durchmesser von 4 km besitzt, was meistens jedoch viel geringer ist. Mikrobrüche können zu erheblichen Schäden an der Oberfläche führen und in einigen Fällen sogar lebensbedrohlich sein.

In Computernetzwerken wird ein Microburst als kurzzeitiger Andrang von Daten definiert, der typischerweise nur Millisekunden dauert, was jedoch die Verbindung überlastet (Ethernet, Gigabit, 10 Gigabit usw.). Ein Mikroburst ist ein ernsthaftes Bedenken für jedes Netzwerk, denn auch eine kurzfristige Überlastung des Netzwerks bedeutet, dass einige Benutzer keinen Zugriff auf das Netzwerk haben werden. Da der Industriestandard für die Messung der Netzwerknutzung in Bit pro Sekunde (bps) angezeigt wird, bleiben Mikrobursts oft unentdeckt, weil sie im Verlauf der Messung ausgeglichen werden. In den meisten Fällen melden herkömmliche Netzwerküberwachungssysteme eine solche Überlastung nicht, weil diese nicht mehr als eine volle Sekunde vorhanden sind. Die Erfahrung des Endbenutzers kann deutlich eingeschränkt werden, wenn zu viel Netzwerkverkehr aufkommt oder Leistungsengpässe entstehen, die durch einen langsamen Datendurchlauf oder Verbindungsausfall verursacht wurden.

Um einen Microburst zu identifizieren, ist eine genaue Messung des Netzwerkverkehrs auf einem Link mit einer Mikrosekunden-Granularität sowie eine Visualisierung in Millisekunden erforderlich. Hier ist ein praktisches Beispiel für die Identifizierung eines Microbursts.

In diesem Beispiel befindet sich der Messpunkt auf einem TAP, der in einen 10-Gbit/s Link einer Rechenzentrumsverbindung eingefügt wird. Wir haben 45 Sekunden des Netzwerkverkehrs mit einem Savvius Omnipliance TL gemessen. Das Expertensystem von Omnipeek alarmiert sofort auf Unregelmäßigkeiten auf den OSI-Schichten 2 bis 7. Diese Warnungen können auf der Basis einer der verfügbaren Spalten sortiert werden, z. B. durch Anzahl, Schichten usw. In diesem Fall sortieren wir nach Anzahl und sind dadurch in der Lage TCP-Wiederübertragungen, "Nicht reagierende" Peer Alerts, langsame Bestätigungen usw.

Abbildung 1: Omnipeek Expertensystem mit Strömungen, kategorisiert nach Protokollen/Anwendungen und Expertenereignissen, die nach Anzahl der Vorkommen sortiert wurden.

Abbildung 2: Eine Grafik der Gesamtauslastung mit sekundengenauer Auflösung zusammen mit den meistgenutzten Anwendungen.

Wenn die Netzwerkauslastung unter Verwendung der typischen bps dargestellt wird, wie dies in Bild 2 der Fall ist, dann beträgt die maximale Vollduplex Spitze 2,54 Gbit/s, was bei einer Verbindung mit 10-Gbit/s und einer Vollduplexkapazität von 20 Gbps als nicht besorgniserregend gilt (senden und empfangen – 10 Gbit/s in jede Richtung).

Eine Sache, die wir in der Zusammenfassung des Compass Expert Events bemerkt haben, ist, dass es eine ziemlich große Anzahl von Ereignissen gibt, die mit langsamen Netzwerkproblemen in Verbindung stehen, insbesondere bei einer Messung von 45 Sekunden. Compass kann das Auftreten von Expert Events grafisch darstellen, wodurch deutlich wird, dass es eine Gemeinsamkeit in dem Neigungsverhältnis zwischen Expert Events und der gesamten Netzwerkauslastung gibt:

Abbildung 3: Die Compass-Funktion von Omnipeek kann das Vorkommen von Expert Events darstellen.

Da die Anzahl von langsamen Netzwerkereignissen recht umfangreich ist, lassen Sie uns zurück zum Nutzungsdiagramm gehen, um die Spitzen etwas näher zu untersuchen. Wir können eine tiefer gehende Analyse durchführen, um dadurch eine Detailgenauigkeit in Millisekunden zu sehen, wobei wir mehrere Spitzen mit bis zu 9.845 Mbit pro Millisekunde feststellen konnten. Umgerechnet auf Sekunden (einfach multipliziert mit 1000), wäre dies 9.845 Gbps, und sollte dies in eine Richtung verlaufen, dann wird dies unseren 10 Gig Link vollständig auslasten.

Abbildung 4: Netzauslastung in Millisekunden-Granularität mit mehreren Spitzen von bis zu 10 Mbit pro Millisekunde

Interessanterweise wurde in Abbildung 4 das obere Protokoll in CIFS umgewandelt. Was ist also passiert?

Abbildung 5: Die übliche Ausnutzung durch TCP-Verkehr ist in Lila dargestellt, wohingegen die CIFS-Spitzen braun gekennzeichnet wurden.

Bei einer normalen Ausnutzung von bis zu 6 Mbit pro Millisekunde an TCP-Verkehr, können CIFS-Spitzen von bis zu 6 Mbit pro Millisekunde die Ausnutzung sogar auf 12 Mbit pro Millisekunde steigern, was die Kapazität eines 10 Gbit/s Links in eine Richtung gänzlich übersteigt. In einer solchen Situation sind die Switches nicht mehr in der Lage den Datenverkehr zu puffern, bis die Bursts verschwunden sind, was dazu führt, dass Pakete verloren gehen und letztendlich TCP-Neuübertragungen verursacht werden, was die Expert Events eindeutig darlegen. Savvius Omnipeek bietet eine sehr intuitive und kostengünstige Möglichkeit, um zu überprüfen, ob tatsächlich Mikrobursts in Ihrem Netzwerk auftreten, aber auch wann, wo und wie sehr die Netzwerkleistung darunter leidet. Wenn Sie noch heute eine kostenlose und 30-tägige Testversion von Omnipeek ausprobieren möchten, dann besuchen Sie einfach unsere Webseite.