Firewall Performance Testing with Xena VulcanBay

In this concrete test case we used a Xena VulcanBay with 2x 40 Gbps QSFP+ interfaces to test some next-generation firewalls regarding their performance. Specifically, we were interested in the following test scenarios:

  • Pure throughput
  • High number of connections (session load)
  • Use of NAT
  • Realistic traffic
  • Longer testing periods during which we “pushed” new firewall rules to detect potential throughput breaches

In this article we want to show how we used the Xena VulcanBay including its management, the VulcanManager, and a Cisco Nexus Switch to connect the firewall clusters. We list our test scenarios and give some hints about potential stumbling blocks.

For our tests we had a Xena VulcanBay Vul-28PE-40G with firmware version 3.6.0, licenses for both 40 G interfaces and the full 28 Packet Engines available. The VulcanManager ran on version Since we only used one single VulcanBay (and not several at distributed locations), the only admin user was able to distribute the full 28 Packet Engines equally on these two ports.

For tests with up to 80 G throughput two QSFP+ modules (left) as well as the distribution of the packet engines on these ports (right) were sufficient.


We used a single Cisco Nexus switch with sufficient QSFP+ modules and corresponding throughput to connect the VulcanBay to the respective firewall clusters. Since we had connected all firewall clusters as well as VulcanBay to this switch at the same time, and had always used the same IPv4/IPv6 address ranges for the tests, we were able to decide which firewall manufacturer we wanted to test purely with the “shutdown / no shutdown” of individual interfaces. Thus the complete laboratory was controllable from a distance. Very practical for the typical case of a home office employee. Furthermore, it was so easy to connect VulcanBay “to itself” in order to get meaningful reference values for all tests. For this purpose, both 40 G interfaces to VulcanBay were temporarily configured in the same VLAN.

With two lines each for client and server, all firewall clusters were connected to a central switch. Also the VulcanBay from Neox Networks.

There are switches with QSFP+ modules, which are however designed as 4x 10 G and *not* as 1x 40 G. For the connection of the VulcanBay with its 40 G interfaces, the latter is unavoidable.

Thanks to modern QSFP+ slots with 40 G interfaces, a duplex throughput of 80 Gbit/s can be achieved with just two connections.

IP Subnets

In our case we wanted to test different firewalls in Layer 3 mode. In order to integrate this “Device Under Test” (DUT) routing we created appropriate subnets – for the outdated IPv4 protocol as well as for IPv6. The IP subnets simulated by VulcanBay are then directly attached to the firewall. In the case of a /16 IPv4 network, exactly this /16 network must also be configured at the firewall. Especially important is the default gateway, for example 10.0.0..1 for the client IPv4 network. If you additionally use the option “Use ARP” (right side), you do not have to worry about the displayed MAC addresses. The VulcanBay resolves these itself.

The address range must be adjusted so that the tests performed are not equivalent to MAC flooding.

The same applies to IPv6. Here the network is not entered in the usual slash notation, but simply the gateway and the address range are determined. Via “Use NDP” the VulcanBay automatically resolves the Layer 2 MAC address to the Layer 3 IPv6 address.

The “Use Gateway” tells VulcanBay that an intermediate router/firewall should be used for the tests.

MAC Flooding! Depending on the test scenarios used, VulcanBay may simulate millions of IPv4/IPv6 addresses in the client or server segment. This is a pure flood of MAC addresses for every intermediate switch or firewall. Common high-end weights can hold a maximum of 128 k MAC addresses in their MAC address table. If you leave the default range of 16 million (!) IPv4 addresses, or 1.8 x 10^19 IPv6 addresses set by Xena Networks by default, any test results are meaningless. Therefore we strictly recommend to reduce the address ranges from the beginning to realistic values, as you can see in the screenshot above (yellow marked: 65 k addresses).

For reference values, the VulcanBay was also “connected to itself” for all tests. While IPv4 allowed using the same “subnets” networks with different address ranges, IPv6 required subnets within the *same* /64 prefix.


1) Pure throughput: In the first test scenario, we were purely concerned with the throughput of the firewalls. For this we chose the “Pattern” scenario, once for IPv4 and once for IPv6, which automatically sets the ratio to 50-50. In the settings we have additionally selected “Bidirectional” to push through data in both directions, i.e. duplex, in both cases. So we could reach the maximum throughput of 80 G with the 2x 40 G interfaces. In order to distribute the bandwidth over several sessions (which in real life is the more realistic test case), we selected 1000 users, who should establish connections from 100 source ports to 10 servers each. Makes 1 million sessions each for IPv4 and IPv6. With a ramp-up time of 5 seconds, i.e. a smooth increase of the connections instead of the immediate full load, the pure test ran through 120 seconds afterwards, before it also had a ramp-down time of 5 seconds.

Test scenario “Pattern” with a 50-50 distribution of IPv4 and IPv6. The “Load Profile” (right) shows the users to be simulated using the time axis.

During the test, the VulcanManager already displays some useful data, such as TCP Connections or Layer 1 throughput. By means of the graphics in the upper area, one gets a good impression at a glance. In the following screenshot you can see that the number of active connections is less than half of the planned one (bad), while Layer 5-7 Goodput has an unattractive kink at the beginning of the test. Both problems turned out to be errors in the IPv6 implementation of the tested device.

While theoretically 2 million sessions at 80 G throughput should have passed the firewall, less than half of them got through cleanly.

The graphic “Active Sessions” does not show the actual active sessions, but the number of simulated users in the Live View during the test as well as in the later PDF report. While the graph is correct for the 2000 users, there were actually 2 million sessions during the test.

2) High number of connections (session load): Also for IPv4 and IPv6, 20 million parallel TCP sessions were established and maintained during this test. Not only the sum of the sessions was relevant, but also the short ramp-up time of only 30 seconds, which corresponded to a setup rate of 667,000 connections per second! The sessions were left standing for 60 seconds, but without transferring any data. Over a further 30 seconds they were terminated again, typical for TCP via FIN-ACK. The aim was that the firewalls to be tested would firstly allow the connections to pass through cleanly and secondly they could also dismantle them cleanly (and thus free up their memory).

Before each test we deleted the MAC address table on the switch as well as the session, ARP and NDP caches on the firewalls. So every test was done from zero to zero.

3) NAT scenarios: The same test as under 1) was used, with the only difference that the IPv4 connections from the client network to the server network were provided with a source NAT on the firewalls. The goal was to find out if this would cause a performance degradation of the firewalls.

4) Realistic Traffic: With a predefined “Datacenter Mix” we were able to simulate the flow of two HTTPS, SMB2, LDAP and AFS (via UDP and TCP) connections for several thousand users with just a few clicks. This was not about a full load test of the firewalls, but about the set-up and dismantling speeds as well as the application detections. Depending on whether the app IDs of the firewalls were activated or deactivated, there were major differences here.

5) 10 minutes of continuous fire with commits: This somewhat more specific test consisted of scenarios 1 and 4, i.e. full load (1) with constant session setup and shutdown (4) at the same time. This ran constantly for 10 minutes, while we installed another 500 rules on each firewall. Here we wanted to find out if this process creates a measurable kink in throughput on the firewalls, which was partly the case.

Test results

At the end of each test, VulcanManager displays the Statistics and Reporting page with all possible details. By “Create Report” you can create a PDF, which contains besides all details also information about the selected test scenario as well as information about the tested device. The challenge is to distinguish the relevant numbers from the less relevant ones and place them in the right context to get meaningful results. During our comparisons of different Next-Generation Firewalls we restricted ourselves to the “Layer 1 steady throughput (bps)” for the throughput test, or the “Successful TCP Connections” for the connection test. Compared to the reference values at which the VulcanBay was connected to itself, this already yielded meaningful comparable results that could be easily displayed both in table form and graphically.

The Statistics and Reporting page provides a rough overview (middle) and the possibility to read test values from all OSI layers and the selected test scenarios (links, fold-out tabs).

Detail of a PDF report with all details.

The various existing “Application Mix” scenarios of Xena Networks do not serve the direct comparison of firewall performance values, but the targeted generation of network traffic. This way, application detections can be checked or other scenarios executed in parallel can be “stressed” a little more.

Further Features

Note that VulcanManager has some other interesting features that we did not use in this case study, such as TLS Traffic (for testing TLS interception) and Packet Replay (for testing custom and more specific scenarios extracted from uploaded PCAPs). Also we have not used many application or protocol oriented test scenarios like Dropbox, eBay, LinkedIn or HTTPS, IMAP, NFS. This is due to our testing purposes, which were strongly focused on pure throughput and number of sessions.


The VulcanBay from XENA Networks is the ideal test device for comparing various next-generation firewalls. Within a very short time we had configured and tested various test scenarios. Only the abundance of test results was initially overwhelming. The trick was to concentrate on the relevant information.

Up to 14x Wireshark Performance Increase – Napatech Link™ Capture Software for Napatech SmartNIC

Solution Description


Wireshark is a widely-used network protocol analyzer allowing users to see what is happening on their networks at a microscopic level. It is the de facto standard across many commercial and non-profit enterprises, government agencies, and educational institutions for troubleshooting and protocol analysis.

Wireshark has a rich feature set including deep inspection of hundreds of protocols, live capture and offline analysis. However, as capable as Wireshark is at inspecting and analyzing network protocols, it will only be as effective as its implementation.

The ability to capture and analyze traffic at lossless rates is of the utmost importance for Wireshark to be successful. To decode all traffic, it is a fundamental requirement that Wireshark “sees everything”. If any traffic is missed, full protocol analysis is not possible. And if the capture server is overburdened and too slow to handle the incoming packet rate, packets are discarded, and information lost forever.

But examining the contents of every network packet is extremely CPU-intensive, especially for a multi-gigabit traffic load. And this is the limiting factor in Wireshark performance: the packet processing on the CPU.

In addressing this challenge, Napatech has created a hardware acceleration solution, based on the Napatech Link™ Capture Software, that alleviates the load on the CPU and thereby greatly increases Wireshark capture perfor- mance.

Key Solution Features


  • Lossless capture and protocol decode for up to 13 Gbps on a single thread for traffic analysis, inspection and detection
  • Onboard packet buffering during micro-burst or PCI Express bus congestion scenarios
  • Advanced host memory buffer management enabling ultra-high CPU cache performance
  • Packet classification, match/action filtering and zero-copy forwarding
  • Intelligent and flexible load distribution to as many as 64 queues improving CPU cache performance by always delivering the same flows to the same cores

The Napatech difference


The Napatech Link™ Capture Software dramatically increases capture and protocol analysis, allowing network engineers to utilize the full power of Wireshark to understand network traffic, find anomalies, and diagnose network issues at incredible speeds. The solution offloads processing and analysis of networking traffic from the application software, while ensuring optimal use of the standard server’s resources leading to effective Wireshark acceleration.

Outstanding lossless performance


Optimized to capture all network traffic at full line rate, with almost no CPU load on the host server, the solution demonstrates enormous lossless performance advantages for Wireshark: up to 14x lossless capture and decode performance compared to a standard network interface card (NIC).

Turning acceleration into value

These performance advantages ultimately allow you to:

  • Maximize your server performance by improving CPU utilization
  • Minimize your TCO by reducing number of servers, thus optimizing rack space, power, cooling and operational expenses
  • Diminish your time-to-resolution, thereby enabling greatly increased efficiency

Test configuration


The outstanding improvements achieved with this solution were demonstrated by comparing Wireshark performance running on a Dell PowerEdge R740 with a standard 40G NIC card and the Napatech NT200 SmartNIC with Link™ Capture Software. Test configuration: dual-socket Dell R740 with Intel® Xeon® Gold 6138 2.0 GHz, 128GB RAM running Ubuntu 14.04 LTS.

Lossless throughput tests


For the lossless throughput test, traffic was sent at fixed rates and packet sizes and throughput was measured as the rate at which Wireshark is able to receive and analyze the packets.

Additional testing for “back-to-back frames” was applied as described in the RFC 2544 benchmarking methodology to send a burst of frames with minimum inter-frame gaps to the Device Under Test (DUT) and count the number of frames received/forwarded by the DUT. The back-to-back value is defined as the number of frames in the longest burst that the DUT can handle without the loss of any frames. With same- size capture buffer configurations, the Napatech SmartNIC delivers 60 times higher back-to-back frame performance. When required for highly bursty traffic patterns, the Napatech solution can allocate significantly larger host buffers, providing hundreds of times higher back-to-back capture performance.

Napatech Link™ Capture Software


The stunning benchmarks for Wireshark were achieved by deploying Napatech’s Reconfigurable Computing Platform, based on FPGA-based Link™ Capture Software and Napatech SmartNIC hardware.

Napatech’s Reconfigurable Computing Platform flexibly offloads, accelerates and secures open, standard, high-volume and low-cost server platforms allowing them to meet the performance requirements for networking, communications and cybersecurity applications.



Wireshark, one of the industry’s foremost network protocol analyzers, is an ideal example of the type of critical enterprise applications that can achieve better performance through hardware acceleration with the Napatech LinkTM Capture Software.

Wireshark can be compiled with native support for hardware acceleration based on the Intel hardware and Napatech software. Instructions specific to building Wireshark with support for Napatech are listed in the Installation Quick Guide available at the Napatech Documentation Portal.

Ethernet Pakete lügen nicht – nun ja, zumindest in den meisten Fällen.

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.

Wie Sie Einstellungsprobleme bei TCP-Verbindungen diagnostizieren können

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.

Für fortgeschrittene Benutzer von PerformanceVision

Wir haben den Filter so festgelegt, dass nur einseitige Flows zu sehen sind, wodurch größtenteils ‘SYN’ Probleme angezeigt werden, aber Sie könnten auch andere Arten von Flows erhalten. Um lediglich die ‘SYN’ ohne Verbindungen zu ermitteln, werden Sie einenbenutzerdefinierten Filter verwenden müssen:

syn.count > 0 and ct.count = 0

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.

Fortgeschrittene Funktionen von PerformanceVision

Die Netzwerklatenz – RTT (Round Trip Time) – dies kann Ihnen einen weiteren Hinweis dafür geben, dass das Problem auf der Netzwerkseite liegt. PV stellt das RTT in der Metrik der Netzwerkleistung zur Verfügung.

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


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:

Wie Sie Microbursts mit Savvius Omnipeek analysieren können

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.