Leistungsresistenz ist die Fähigkeit, die Leistung Ihres kommerziellen oder selbstgebauten Geräts in jeder Rechenzentrumsumgebung zu gewährleisten. Mit anderen Worten, um sicherzustellen, dass Ihre Performance-Überwachung, Cybersicherheits- oder Forensik-Appliance widerstandsfähig gegen häufige Probleme im Rechenzentrum ist, wie z.B. schlecht konfigurierte Netzwerke, Unfähigkeit, den gewünschten Verbindungstyp anzugeben, Zeitsynchronisation, Leistung, Platz usw.

In diesem Blog werden wir uns mit der Deduplizierung befassen und wie die Unterstützung der Deduplizierung in Ihrer SmartNIC die Leistungsresistenz sicherstellt, wenn Rechenzentrumsumgebungen nicht richtig konfiguriert sind – speziell Router und Switch SPAN-Ports.

Nehmen wir das Schlimmste an

Bei der Entwicklung einer Appliance zur Analyse von Netzwerkdaten für die Überwachung von Leistung, Cybersicherheit oder Forensik ist es selbstverständlich anzunehmen, dass die Umgebungen, in denen Ihre Appliance eingesetzt wird, korrekt konfiguriert sind und den Best Practices entsprechen. Es ist auch anzunehmen, dass Sie den Zugang und die Konnektivität erhalten können, die Sie benötigen. Warum sollte sich jemand die Mühe machen, für ein kommerzielles Gerät zu bezahlen oder gar die Entwicklung eines Gerätes im eigenen Haus zu finanzieren, wenn er nicht auch dafür sorgen würde, dass die Umwelt den Mindestanforderungen entspricht?

Leider ist es nicht immer so, wie viele Veteranen der Geräte-Reihen Ihnen sagen werden. Denn nicht immer ist das für den Einsatz der Appliance verantwortliche Team das für den Betrieb des Rechenzentrums verantwortliche Team. Geräte sind nicht die erste Priorität. Was also in der Praxis passiert, ist, dass das Team, das die Appliance einsetzt, angewiesen wird, die Appliance an einem bestimmten Ort mit spezifischer Konnektivität zu installieren, und das ist alles. Möglicherweise bevorzugen Sie es, einen TAP zu verwenden, der jedoch möglicherweise nicht verfügbar ist, so dass Sie einen Switched Port Analyzer (SPAN)-Port von einem Switch oder Router für den Zugriff auf Netzwerkdaten verwenden müssen.

Während dies akzeptabel erscheinen mag, kann es zu einem unerwarteten und unerwünschten Verhalten führen, das für die grauen Haare auf den Köpfen von Veteranen verantwortlich ist! Ein Beispiel für dieses unerwünschte Verhalten sind doppelte Netzwerkpakete.

Wie entstehen doppelte Pakete?

Im Idealfall möchten Sie bei der Durchführung von Netzwerküberwachung und -analyse mit einem Fingertipp direkten Zugriff auf die Echtzeitdaten erhalten. Wie wir jedoch bereits erwähnt haben, kann man das nicht immer vorschreiben und muss sich manchmal mit der Konnektivität zu einem SPAN-Port begnügen.

Der Unterschied zwischen einem TAP und einem SPAN-Port besteht darin, dass ein TAP eine physikalische Vorrichtung ist, die in der Mitte der Kommunikationsverbindung installiert ist, so dass der gesamte Datenverkehr durch den TAP läuft und auf das Gerät kopiert wird. Umgekehrt empfängt ein SPAN-Port an einem Switch oder Router Kopien aller Daten, die den Switch passieren, die dann über den SPAN-Port dem Gerät zur Verfügung gestellt werden können.

Bei richtiger Konfiguration funktioniert ein SPAN-Port einwandfrei. Moderne Router und Switches sind besser geworden, um sicherzustellen, dass die von den SPAN-Ports bereitgestellten Daten zuverlässig sind. SPAN-Ports können jedoch so konfiguriert werden, dass sie zu doppelten Paketen führen. In einigen Fällen, in denen SPAN-Ports falsch konfiguriert sind, können bis zu 50% der vom SPAN-Port bereitgestellten Pakete Duplikate sein.

Also, wie passiert das? Was Sie in Bezug auf SPAN-Ports verstehen müssen, ist, dass, wenn ein Paket in den Switch an einem Eingangsport eintritt, eine Kopie erstellt wird – und wenn es den Switch an einem Ausgangsport verlässt, wird eine weitere Kopie erstellt. In diesem Fall sind Duplikate unvermeidlich. Es ist jedoch möglich, den SPAN so zu konfigurieren, dass er nur Kopien beim Eintritt oder Austritt aus dem Switch erstellt, um Duplikate zu vermeiden.

Dennoch ist es nicht ungewöhnlich, in einer Rechenzentrumsumgebung anzukommen, in der SPAN-Ports falsch konfiguriert sind und niemand die Berechtigung hat, die Konfiguration am Switch oder Router zu ändern. Mit anderen Worten, es wird Duplikate geben und man muss damit leben!

Was sind die Auswirkungen von Duplikaten?

Duplikate können viele Probleme verursachen. Das offensichtliche Problem ist, dass die doppelte Datenmenge die doppelte Menge an Rechenleistung, Speicher, Leistung usw. erfordert. Das Hauptproblem sind jedoch False Positives: Fehler, die nicht wirklich Fehler sind, oder Bedrohungen, die nicht wirklich Bedrohungen sind. Eine gängige Art und Weise, wie Duplikate die Analyse beeinflussen, ist eine Zunahme von TCP-Out-of-Order- oder Retransmissionswarnungen. Das Debuggen dieser Probleme nimmt viel Zeit in Anspruch, in der Regel Zeit, die ein überlastetes, unterbesetztes Netzwerkbetriebs- oder Sicherheitsteam nicht hat. Darüber hinaus ist jede Analyse, die auf der Grundlage dieser Informationen durchgeführt wird, wahrscheinlich nicht zuverlässig, so dass dies das Problem nur verschärft.

Wie man Resilienz erreicht

Mit der über eine SmartNIC in die Appliance integrierten Deduplizierung ist es möglich, bis zu 99,99% der von SPAN-Ports erzeugten doppelten Pakete zu erkennen. Ähnliche Funktionen sind bei Packet Brokern verfügbar, jedoch gegen eine beträchtliche zusätzliche Lizenzgebühr. Bei Napatech SmartNICs ist dies nur eine von mehreren leistungsstarken Funktionen, die ohne Aufpreis angeboten werden.

Die Lösung ist ideal für Situationen, in denen das Gerät direkt an einen SPAN-Anschluss angeschlossen wird, wodurch die Anzahl der Schäden, die durch Duplikate entstehen können, drastisch reduziert wird. Es bedeutet aber auch, dass die Appliance widerstandsfähig gegen SPAN-Fehlkonfigurationen oder andere Probleme der Netzwerkarchitektur ist, die zu Duplikaten führen können – ohne sich auf andere kostspielige Lösungen, wie z.B. Packet Broker, zu verlassen, um die notwendige Funktionalität zur Verfügung zu stellen und die Lösung zu komplettieren.

Die Herausforderung: mehr als 50% Kopien

Doppelte Pakete sind eine große Belastung für die heutigen Netzwerküberwachungs- und Sicherheitsanwendungen. Im schlimmsten Fall sind mehr als 50% des empfangenen Datenverkehrs reine Replikation. Dies führt nicht nur zu einem zu hohen Anspruch in Bezug auf Bandbreite, Rechenleistung, Speicherkapazität und Gesamteffizienz. Es stellt auch eine große Belastung für die Betriebs- und Sicherheitsteams dar, da sie am Ende wertvolle Zeit mit der Jagd auf False-Negatives verschwenden. Napatechs intelligente Deduplizierungsfunktionen lösen dies, indem sie doppelte Pakete identifizieren und verwerfen, was eine Reduzierung der Anwendungsdatenlast um bis zu 50% ermöglicht.

Fehlkonfigurierte SPAN-Ports

Für passive Überwachungs- und Sicherheitsanwendungen können doppelte Pakete mehr als 50% des gesamten Datenverkehrs ausmachen. Dies ist zum Teil auf TAP- und Aggregationslösungen zurückzuführen, die Pakete von mehreren Punkten im Netzwerk sammeln – und zum Teil auf falsch konfigurierte SPAN-Ports, ein viel zu häufiges Problem in den heutigen Rechenzentren.

Lösung: intelligente Deduplizierung

Mit der über ein SmartNIC in der Anwendung integrierten Deduplizierung ist es möglich, alle doppelten Pakete zu erkennen. Durch die Analyse und den Vergleich eingehender Pakete mit zuvor empfangenen/gespeicherten Daten verwerfen Deduplizierungsalgorithmen alle Duplikate, was die Belastung des Systems verringert und die Leistung erheblich optimiert.

Signifikante Kostenvorteile

Durch das Hinzufügen von Deduplizierung in der Hardware über ein Napatech SmartNIC können auf verschiedenen Ebenen erhebliche Kostenvorteile erzielt werden:

1. Auf dem Leistungsniveau
   Für die überwiegende Mehrheit der Capture-Implementierungen spart die Deduplizierung drastisch Systemressourcen. Durch die effiziente entfernen redundanter Kopien kann die Deduplizierung die Verarbeitungslast, den PCIe-Transfer, den Systemspeicher und den Festplattenspeicherbedarf um bis zu 50% reduzieren.
2. Auf operativer Ebene
   Auf operativer Ebene ist das Hauptproblem bei doppelten Paketen, dass sie den Überblick verzerren. Aber mit Deduplizierung vermeiden Betriebs- und Sicherheitsteams, wertvolle Zeit mit der Untersuchung von Fehlalarmen zu verschwenden.
3. Auf Anwendungsebene
   Ähnliche Funktionen sind bei Network Packet Brokern verfügbar, oftmals jedoch gegen eine beträchtliche zusätzliche Lizenzgebühr. Auf Napatech SmartNICs ist die Deduplizierung nur eine von mehreren leistungsstarken Funktionen, die ohne Aufpreis angeboten werden.

Wichtige Merkmale

• Deduplizierung in Hardware bis zu 2x100G
• Deduplizierungsschlüssel, der als Hash über konfigurierbare Abschnitte des Frames berechnet wird.
• Dynamische Header-Informationen (z.B. TTL) können aus der Schlüsselberechnung ausgeblendet werden.
• Die Deduplizierung kann pro Netzwerkport oder Netzwerkportgruppe aktiviert / deaktiviert werden.
• Konfigurierbare Aktion pro Portgruppe: Duplikate verwerfen oder übergeben / Doppelte Zähler pro Portgruppe
• Konfigurierbares Deduplizierungsfenster: 10 Mikrosekunden – 2 Sekunden

Möchten Sie die Datenduplizierung um bis zu 50% reduzieren? Kontaktieren Sie uns noch heute!

Einführung von Flow-Formaten und deren Unterschieden

Es gibt mehrere Flow-Formate. Worin bestehen die Unterschiede? Welche werden von Flowmon unterstützt? Überprüfen Sie den Beitrag, um die Antworten zu sehen.

Flow Monitoring hat sich zur weit verbreiteten Methode zur Traffic-Überwachung in Hochgeschwindigkeitsnetzen entwickelt. Es gibt mehrere Standards für das Flow-Format und es kann schwierig sein, den richtigen für Ihre Bedürfnisse zu wählen. In diesem Artikel werden wir die gängigsten Flow-Formate durchgehen und einen grundlegenden Überblick über ihre Geschichte und Unterschiede geben.

Historie des Flow Monitoring

Die Geschichte der Flow Monitoring geht auf das Jahr 1996 zurück, als das NetFlow-Protokoll von Cisco Systems patentiert wurde. Flow-Daten stellen einen einzelnen Paketfluss im Netzwerk mit der gleichen 5-Tupel-Identifikation dar, die sich aus Quell-IP-Adresse, Ziel-IP-Adresse, Quell-Port, Ziel-Port, Ziel-Port und Protokoll zusammensetzt. Basierend darauf werden Pakete zu Flow Records aggregiert, die die Menge der übertragenen Daten, die Anzahl der Pakete und andere Informationen aus der Netzwerk- und Transportschicht sammeln. Ein typischer Flow-Monitoring-Aufbau besteht aus drei Hauptkomponenten:

Flow Exporter – Erstellen von Flow-Datensätzen durch Aggregation von Paketinformationen und exportieren der Datensätze an einen oder mehrere Flow-Kollektoren (z.B. Flowmon Probe).

Flow Collector – sammelt und speichert die Flow-Daten (z.B. Flowmon Collector).

Analyseapplikation – ermöglicht die Visualisierung und Analyse der empfangenen Flow-Daten (z.B. Flowmon Monitoring Center – native Applikation des Flowmon Collectors).

Cisco hat das Protokoll ursprünglich für seine Produkte entwickelt. Andere Hersteller haben einen solchen Ansatz verfolgt und mehr oder weniger ähnliche proprietäre Flow-Datenformate entwickelt.

Cisco standards

NetFlow v5

Die erste weit verbreitete Version war NetFlow v5, die 2006 verfügbar wurde. NetFlow v5 ist nach wie vor die häufigste Version und wird von einer Vielzahl von Routern und Switches unterstützt. Sie erfüllt jedoch nicht mehr die Anforderungen an ein genaues Flow Monitoring, da sie IPv6-Verkehr, MAC-Adressen, VLANs oder andere Erweiterungsfelder nicht unterstützt.

NetFlow v9

NetFlow v9 brachte mehrere zusätzliche Verbesserungen. Das Wichtigste ist die Unterstützung von Vorlagen, die eine flexible Definition des Flow-Exports ermöglichen und sicherstellen, dass NetFlow an die Unterstützung neuer Protokolle angepasst werden kann. Weitere Verbesserungen sind die Unterstützung von IPv6, Virtual Local Area Networks (VLANs), Multiprotocol Label Switching (MPLS) und anderen Funktionen. NetFlow v9 wird von den meisten der aktuellen Cisco-Router und -Switches unterstützt.

Flexible NetFlow

Cisco arbeitet weiterhin an der Verbesserung der NetFlow-Technologie. Die nächste Generation heißt Flexible NetFlow und erweitert NetFlow v9 weiter. Was Flexible NetFlow exportieren kann, ist in hohem Maße anpassbar, so dass Kunden fast alles exportieren können, was über den Router läuft.

Andere Hersteller

jFlow, NetStream, cflowd

Alle oben genannten Standards ähneln dem ursprünglichen Cisco NetFlow-Standard. jFlow wurde von Juniper Networks, NetStream von Huawei und cflowd von Alcatel-Lucent entwickelt.

Unabhängiger Standard

IPFIX

Der Vorschlag für das IPFIX-Protokoll (Internet Protocol Flow Information eXport) wurde 2008 von der IETF veröffentlicht. IPFIX ist von NetFlow v9 abgeleitet und sollte als universelles Protokoll für den Export von Flussinformationen aus Netzwerkgeräten an einen Kollektor oder ein Netzwerkmanagementsystem dienen. IPFIX ist flexibler als NetFlow und ermöglicht, die Flow-Daten um zusätzliche Informationen über den Netzwerkverkehr zu erweitern. Als Beispiel bereichern unsere Flowmon IPFIX-Erweiterungen die IPFIX-Flowdaten mit Metadaten des Application Layer Protokolls, Netzwerkleistungsstatistiken und anderen Informationen.

In der Cisco-Welt wird IPFIX üblicherweise als NetFlow v10 bezeichnet und bietet verschiedene Erweiterungen ähnlich wie Flowmon.

Verwandte Standards

NSEL

NSEL (NetFlow Security Event Logging) ermöglicht den Export von Flow-Daten aus Cisco’s ASA-Familie von Sicherheitsgeräten. Es hat ein ähnliches Format wie NetFlow, erfordert aber eine andere Interpretation und hat unterschiedliche Anwendungsfälle – der Zweck von NSEL ist es, Firewall-Ereignisse und Protokolle über NetFlow zu verfolgen. Leider kam es manchmal vor, dass die Leute durch die Terminologie verwirrt wurden und NSEL als kompatibel mit NetFlow betrachteten. Tatsächlich gibt es mit NSEL nicht genügend Informationen, um Verkehrskarten bereitzustellen oder detaillierte Drill-Downs und Fehlersuche zu unterstützen.

sFlow

Im Gegensatz zu NetFlow basiert sFlow auf Stichproben. Ein sFlow-Agent erhält Verkehrsstatistiken mit sFlow-Sampling, kapselt sie in sFlow-Pakete, die dann an den Collector gesendet werden. sFlow bietet zwei Sampling-Modi – Flow und Counter Sampling:

Flow Sampling, bei dem der sFlow-Agent Pakete in eine Richtung oder beide Richtungen auf einer Schnittstelle basierend auf dem Sampling-Verhältnis abtastet und die Pakete analysiert, um Informationen über den Inhalt der Paketdaten zu erhalten.

Counter Sampling, bei dem der sFlow-Agent periodisch Verkehrsstatistiken über eine Schnittstelle erhält.

Flow Sampling konzentriert sich auf Verkehrsdetails, um das Verkehrsverhalten im Netzwerk zu überwachen und zu analysieren, während Counter Sampling sich auf allgemeine Verkehrsstatistiken konzentriert.

Aufgrund von Paket-Sampling ist es jedoch nicht möglich, eine genaue Darstellung des Datenverkehrs zu erhalten und einige Daten werden verpasst. Daher kann die Sampling-Funktion die Verwendung von Flow-Daten in Fällen wie der Erkennung von Netzwerkanomalien einschränken. Andererseits kann sFlow für Top-Statistiken oder die Erkennung von DDoS-Angriffen verwendet werden. Cisco hat eine sehr ähnliche Technologie wie sFlow eingeführt, die den Namen NetFlow Lite trägt.

Welche Formate unterstützt Flowmon?

Unsere eigenständige Probe ermöglicht den Export von Strömungsdaten im NetFlow v5/v9 und IPFIX-Format. Zusätzlich kann die Sonde die Flowmon IPFIX-Erweiterung verwenden, die es ermöglicht, die Flowdaten mit zusätzlichen Informationen wie Netzwerkleistungsstatistiken (z.B. Round-Trip Time, Server Response Time und Jitter) und Informationen aus den Anwendungsprotokollen (HTTP, DNS, DHCP, SMB, E-Mail, MSSQL und andere) zu erweitern.

Der Flowmon Collector kann Netzwerkverkehrsstatistiken aus verschiedenen Quellen und Flow-Standards verarbeiten, einschließlich:

• NetFlow v5/v9
• IPFIX
• NetStream
• jFlow
• cflowd
• sFlow, NetFlow Lite

Fazit: Welches Flow-Format sollte verwendet werden?

Flowmon unterstützt die gängigsten Flow-Formate. Obwohl das Format, das Sie verwenden können, von Ihrer Netzwerkinfrastruktur abhängt, empfehlen wir Ihnen aufgrund unserer Erfahrung bei der Implementierung leistungsstarker Netzwerküberwachungsgeräte dringend die Verwendung von NetFlow v9/IPFIX-Exportformaten, da sie die genauesten und umfassendsten Informationen liefern.

Die Einführung von DevOps und Agile hat den Lebenszyklus der Anwendungsentwicklung verkürzt und vereinfacht. Mit zunehmender Fokussierung auf die Schnelligkeit der Markteinführung steigt jedoch das Risiko, dass die Anwendung hinter ihren Zielen zurückbleibt. Dieses Risiko wird noch verstärkt, wenn die Anwendung – wie die meisten heute – von verteilten Netzwerken abhängig ist.

Vernetzte Anwendungen sind das Herzstück unseres Handelns. Von CRM bis Social Networking, von der Bestellung eines Taxis bis zum Geldtransfer haben sie unser Geschäfts- und Privatleben verändert. Militär, Gesundheitswesen und Rettungsdienste verlassen sich auf Apps, um Leben zu retten. Apps stärken unser persönliches, berufliches und öffentliches Leben, also müssen sie einfach funktionieren.

Application Risk Management (AppRM) ist ein neuer Prozess, der Softwarearchitekten, Entwicklern und Testern hilft, sicherzustellen, dass sie die Risiken während des gesamten Lebenszyklus der Anwendungsentwicklung und -bereitstellung richtig eingeschätzt und verwaltet haben. Es ist ein Prozess zur Identifizierung, Qualifizierung und Minderung potenzieller Fehler und Leistungsprobleme, von der Entwicklung bis zur Bereitstellung – vom Design bis zum Start der Anwendung.

AppRM ermöglicht es Entwicklern und Testern, alle mit der Anwendungsleistung verbundenen Risiken vorherzusagen und zu verwalten, wodurch Kosten und Markteinführungszeit durch frühzeitiges Erkennen von Schwachstellen und Risiken, insbesondere bei externen Faktoren, reduziert werden. So muss beispielsweise eine Anwendung, egal wie elegant sie gestaltet ist – egal wie gut sie in der Sicherheit und im Komfort des Prüflabors abschneidet – mit den Problemen des Betriebs über reale Netzwerke fertig werden, weshalb Systemarchitekten zunehmend einen neuen Ansatz für dieses spezielle Anwendungs-Risikomanagement verfolgen. Network Profiling und Virtual Test Networks sind eine leistungsstarke neue Art des Testens, die den intelligenten Weg bietet, die Risiken der Bereitstellung von Anwendungen in potenziell ungünstigen Netzwerkumgebungen zu managen.

Application Risk Management hat eine einfache Idee im Kern: Um die potenziellen Risiken zu beseitigen, indem man versteht, wie eine App in jeder Phase des Entwicklungsprozesses funktioniert, wie z.B. das Verständnis, wie sie in der realen vernetzten Umgebung funktioniert – Seine Anwender wissen, dass sie öffentliche Netzwerke nicht verbessern können, aber sie können die Toleranz und Widerstandsfähigkeit der App verbessern. Letztendlich müssen sie zunächst wissen, an welchem Punkt die App wahrscheinlich ausfällt.

In einem Umfeld, in dem das Risiko einer fehlgeschlagenen Anwendungseinführung oder -migration Einnahmen, Markenreputation, Arbeitsplätze oder sogar Leben kosten könnte, sollte die effektive Bewertung und Bewältigung dieses Risikos integraler Bestandteil jedes Entwicklungsprozesses sein und als solcher stärker in den Mittelpunkt gerückt werden.

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.