Author Archiv: Patrick Nixdorf

Die Auswirkung von Paketverlusten auf ein IDS Deployment

Auf der SuriCon 2019 präsentierten Eric Leblond und Peter Manev – beide wichtige Mitarbeiter der Suricata-Community – wichtige Testergebnisse und betonten die Auswirkungen von Paketverlusten. Lassen Sie uns ein wenig tiefer in die Bedeutung von Zero Packetloss bei einer IDS-Bereitstellung einsteigen.

Die Auswirkungen von Paketverlusten auf einer Vielzahl von Netzwerkanalysegeräten sind je nach Funktion des Analysegerätes sehr unterschiedlich. Die Messgenauigkeit von Geräten zur Überwachung der Netzwerk- und/oder Anwendungsleistung wird beeinträchtigt, wenn Pakete vom Netzwerksensor gedroppt werden. Im Falle eines Cybersicherheitsgeräts, wie z.B. eines Suricata-basierten Intrusion Detection Systems (IDS), werden verpasste Attacken direkt durch den Verlust von Paketen beeinflusst. Dies gilt auch für die Dateiextraktion.

Die Auswirkung von Paketverlusten auf die Generierung von Intrusion Alerts

Egal wie gut die IDS-Regel ist, wenn nicht alle Pakete für eine bestimmte Session an das IDS geliefert werden, können Alarme verpasst werden. Dies ist hauptsächlich darauf zurückzuführen, wie ein IDS eine Session verarbeitet. Die gegebenen Pakete, die innerhalb der Session verworfen werden, bestimmen, ob das IDS genug Daten hat, um einen Alarm zu generieren. In vielen Fällen verwirft das IDS die gesamte Sitzung, wenn Schlüsselpakete fehlen. Ein verpasster Alarm könnte bedeuten, dass ein Eindringversuch unentdeckt blieb.

Zur Messung der versäumten Alarme wurde die folgende Methodik angewandt:

  • Traffic-Quelle ist eine PCAP-Datei, die den tatsächlichen Netzwerkverkehr mit böswilligen Aktivitäten enthält
  • Die PCAP-Datei wird verarbeitet, um einen bestimmten zufälligen Paketverlust zu simulieren
  • Suricata-Alarme werden für die originale PCAP-Datei mit einer modifizierten Datei verglichen

Beispielhafte Zahlen:

  • 10% verpasste Alarme mit 3% Paketverlust
  • 50% verpasste Alarme mit 25% Paketverlust

Die Auswirkung von Paketverlusten auf die IDS-Datei-Extraktion

Teil einer erfolgreichen IDS-Strategie ist es, auch die Dateiextraktion zu automatisieren. Die meisten IDS-Engines unterstützen die Protokolle HTTP, SMTP, FTP, NFS und SMB. Der Dateiextraktor läuft über den Protokoll-Parser, der das Dekomprimieren und Entpacken der Anfrage und/oder der Antwortdaten übernimmt, falls erforderlich. Der Verlust eines einzelnen Pakets für einen Stream, welcher eine bestimmte Datei beinhaltet, führt in den meisten Fällen zum Scheitern der Dateiextraktion.

Beispielhafte Zahlen:

  • 10% fehlgeschlagene Dateiextraktion mit 4% Paketverlust
  • 50% fehlgeschlagene Dateiextraktion mit 5,5% Paketverlust

Zusammenfassend zeigen die Testergebnisse, wie wichtig Zero Packetloss für einen erfolgreichen IDS-Einsatz sind. FPGA-SmartNIC-Funktionen wie On-Board-Burst-Pufferung, DMA und optimierte PCI-Express-Performance minimieren oder eliminieren den Paketverlust in einem serverbasierten Standard-IDS vollständig.

50% Datenreduktion durch integrierte Deduplizierung

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!

Firewall Performance Testing mit Xena VulcanBay

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).

Verkabelung

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.

Es gibt Switche mit QSFP+ Modulen, welche allerdings als 4x 10 G ausgeführt sind und *nicht* als 1x 40 G. Für den Anschluss des VulcanBay mit seinen 40 G Interfacen ist letzteres unumgänglich.

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

IP Subnets

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.

MAC Flooding! Je nach verwendeten Test Szenarios simuliert der VulcanBay mitunter Millionen von IPv4/IPv6 Adressen im Client oder Server Segment. Dies ist für jeden dazwischenliegenden Switch oder Firewall eine reine Flut von MAC Adressen. Gängige High-End Swichte können maximal 128 k MAC Adressen in ihrer MAC-Address-Table halten. Belässt man die von Xena Networks per default eingestellt Range von 16 Millionen (!) IPv4 Adressen, bzw. 1,8 x 10^19 IPv6 Adressen sind hernach jedwede Testergebnisse nichts aussagend. Daher strikt die Empfehlung, die Address Ranges von vornherein auf realitische Werte zu verkleinern, wie in dem Screenshot oben zu sehen ist (gelb markiert: 65 k Adressen).

Für Referenzwerte wurde der VulcanBay für alle Tests auch “mit sich selbst” verbunden. Während man bei IPv4 die gleichen “Subnets” Netze mit den unterschiedlichen Adressbereichen weiterverwenden konnte, waren bei IPv6 Subnetze innerhalb des *gleichen* /64 Präfix nötig.

Testcases

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.

Die Grafik “Active Sessions” zeigt sowohl in dem Live-View während des Tests als auch in dem späteren PDF Bericht nicht die tatsächlichen aktiven Sessions, sondern die Anzahl der simulierten User an. Während die Grafik für die 2000 User zwar stimmt, waren es während des Tests tatsächlich 2 Millionen Sessions.

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.

Vor jedem Test haben wir sowohl die MAC-Address-Table auf dem Switch, als auch die Session, ARP und NDP Caches auf den Firewalls gelöscht. Somit wurde jeder Test aufs Neue von Null auf durchgeführt.

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.

Testergebnisse

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.

Die vielfältig vorhandenen “Application Mix” Szenarien von Xena Networks dienen nicht dem direkten Vergleich von Firewall Performance Werten, sondern dem gezielten Generieren von Netzwerkverkehr. So können damit Applikationserkennungen überprüft werden oder andere parallel ausgeführte Szenarien etwas mehr “gestresst” werden.

Weitere Features

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.

Fazit

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.

Bis zu 14x Leistungssteigerung durch Wireshark – Napatech Link™ Capture Software für Napatech SmartNIC

Lösungsbeschreibung

 

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.

Wichtigste Lösungsmerkmale

 

  • 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

Der Napatech-Unterschied

 

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.

Hervorragende verlustfreie Leistung

 

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).

Aus Beschleunigung wird Wert

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

Testkonfiguration

 

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.

Verlustfreie Durchsatzprüfungen

 

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.

Napatech Link™ Capture Software

 

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

 

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.