Zeitgemäße Transformation des Netzwerkbetriebs mit angereicherten Flow-Daten

Die digitale Transformation von Unternehmen weltweit hat zu einer allgegenwärtigen Konnektivität und einem schnellen Datenaustausch mit massiven Produktivitätssteigerungen geführt. Die Netzwerkinfrastruktur spielt eine so grundlegende Rolle, dass die Gewährleistung ihrer Zuverlässigkeit und Sicherheit für jedes Unternehmen heute von entscheidender Bedeutung ist.

Doch Netzwerke werden immer abstrakter, interpretiert in Metaphern wie einer „Public Cloud“, in der wir nicht einmal mehr in Form von Switches oder Routern denken, geschweige denn, wie man sie von Hand konfiguriert. Die Anbieter von Netzwerkgeräten machen die Vernetzung nahtlos, und so verlagert sich das Know-how der Ingenieure langsam vom Wissen um die Verwendung eines Schraubendrehers hin zur Sicherung eines Netzwerks mit Zehntausenden von IoT-Geräten.

SDN, NFV und Virtualisierung gehen Hand in Hand mit diesem Trend – so können Unternehmen ihre Ressourcen auf das Kerngeschäft konzentrieren, anstatt das Netzwerk zu verwalten. Dies führt zu einer Bandbreitenexplosion in Unternehmensnetzwerken, die die traditionellen Ansätze der Netzwerküberwachung als primitives Werkzeug erscheinen lässt. Flowmon hat diese alten Konzepte überdacht und versucht nun, die Mauern niederzureißen, die den Fortschritt begrenzen.

In diesem Technical Reading geht es um unsere Überzeugung, dass die Zusammenführung von Flow- und Packet-Level-Transparenz zu einer vielseitigen Lösung die Technologie wird, die Ihnen hilft, sich auf zukünftige Leistungs- und Kapazitätsanforderungen einzustellen. Die Lösung speichert auch detaillierte Informationen über den Netzwerkverkehr und stellt die Ergebnisse einfach und verständlich dar. Sie werden erfahren, wie Flow-Daten, die oft als Billing- und Top-Statistiktool wahrgenommen werden, die vollständige Paketerfassung und -analyse vollständig ersetzen und eine noch nie da gewesene und zukunftssichere Skalierbarkeit bieten können.

Die Paketanalyse untersucht die Kommunikation, um ihren Inhalt zu analysieren. Es ist keine Aggregation, Komprimierung oder Trimmung erforderlich, und die Daten werden in ihrer ursprünglichen Größe gespeichert. Folglich stellt diese Methode extrem hohe Anforderungen an die Leistung und die Festplattenkapazität.

Stellen Sie sich vor, Sie erfassen ein Netzwerk mit durchschnittlich 250 Mbit/s Traffic. Dies entspricht einer Datenlast von über 31 MB pro Sekunde, 1,8 GB pro Minute, 108 GB pro Stunde und 2,6 TB pro Tag. Bei 10Gbps-Netzen erreichen wir kaum fassbare Zahlen – es wären mehr als 100 TB gespeicherte Daten pro Tag.

Doch nicht nur große Datenmengen sind der Nachteil. Die wichtigste Einschränkung der Paketanalyse ist der verschlüsselte Datenverkehr. Ohne den Verschlüsselungscode können wir den Inhalt der übertragenen Daten nicht verstehen und oft nicht einmal das Übertragungsprotokoll oder die Anwendung aufdecken. Dennoch wächst das Volumen des verschlüsselten Datenverkehrs ständig.

Die kontinuierliche, vollständige Traffic-Aufzeichnung (Full Packet Capture) erfordert die richtige technische Ausstattung, insbesondere Hochgeschwindigkeits-Speicher-Arrays mit ausreichender Kapazität. Ein solcher Ansatz zur Netzüberwachung ist sehr teuer und nur für kritische Infrastrukturen und Netze mit einem bestimmten Zweck geeignet. Es muss betont werden, dass die Speicherung solcher Daten nicht das einzige Problem sein kann. Sobald die Daten gespeichert sind, beinhaltet jede Fehlerbehebung ein umfangreiches Mining von Informationen, das viel Erfahrung und Fachwissen erfordert. Für die Mehrheit der Netzwerkprobleme, die nicht unter die teure kontinuierliche vollständige Paketerfassung fallen, setzen Unternehmen auf einen anderen Ansatz.

Er wird als On-Demand-Paketerfassung bezeichnet. Bei diesem Ansatz erfassen wir Pakete nur bei Bedarf – typischerweise, wenn wir uns mit Problemen der Systemkompatibilität befassen – zum Beispiel, wenn wir fehlende oder beschädigte Pakete entdecken. Die On-Demand-Paketerfassung ist eine einfache Methode, die für jeden Netzwerkadministrator erschwinglich ist, aber sie hat ihre Vor- und Nachteile. Die Einschränkung dieses Ansatzes besteht darin, dass der Administrator im Voraus entscheiden muss, welcher Traffic gespeichert werden soll. Daher gibt es keine Möglichkeit, das Traffic-Archiv zu erreichen, um die richtigen Informationen für die Analyse im Falle eines Vorfalls zu erhalten. Ein Netzwerkadministrator muss mit seinem Notebook an einen physischen Ort (z.B. Serverraum) gehen, das Notebook an einen Mirror-Port oder TAP anschließen und die Aufzeichnung des Netzwerkverkehrs durchführen. Probleme können bei weitem Abstand, aber auch bei optischen Netzwerkschnittstellen und 10Gpbs-Infrastrukturen auftreten – Einschränkungen, die mit einem Notebook kaum zu überwinden wären.

Obwohl die Notwendigkeit der Erfassung von Paketen nicht wegfällt, sinkt die Nachfrage jedoch sicherlich. Es gibt ein klares Skalierbarkeitsproblem, insbesondere aufgrund der ständig wachsenden Anzahl von Geräten, die mit einem Netzwerk verbunden sind, oder der Anzahl von Anwendungen und Diensten, die aus der Cloud bereitgestellt werden und höhere Bandbreiten erfordern. Lösungen zur vollständigen Verkehrserfassung und -analyse sind sehr ressourcenintensiv und damit teuer. Außerdem gibt es technologische Grenzen in einer Hochgeschwindigkeits-Netzwerkumgebung und eingeschränkte Einsatzmöglichkeiten bei verschlüsseltem Datenverkehr.

Wenn es um die Überwachung des Netzwerkverkehrs, die Fehlerbehebung oder die Erkennung von Bedrohungen geht, würden Netzwerkingenieure selten denken, dass ihnen zwei Optionen zur Verfügung stehen. Die erste ist die vollständige Paketerfassung und -analyse, die eine vollständige Netzwerktransparenz bietet. Die andere sind die Flow-Daten.

Flow-Daten sind eine Abstraktion des Netzwerkverkehrs selbst. Flow-Statistiken werden als Aggregation des Netzwerkverkehrs erstellt; sie verwenden die Quell-IP-Adresse, die Ziel-IP-Adresse, den Quell-Port, den Ziel-Port und die Protokollnummer als Attribute, die die einzelnen Flow-Records identifizieren. Der Inhalt der Kommunikation wird nicht gespeichert, und die erreichbare Aggregationsrate liegt bei etwa 500:1. Mit den oben aufgeführten Informationen sind wir in der Lage, die Verkehrsstruktur zu analysieren, Endgeräte zu identifizieren, die große Datenmengen übertragen oder Netzwerkprobleme und falsche Konfigurationen zu beheben. Mit anderen Worten, wir können 80% der Netzwerkereignisse bewältigen, wie Gartner seit 2013 berichtet.

Es ist offensichtlich, dass die Flow-Daten für einige Aufgaben nicht genügend Informationen enthalten. Im Gegensatz dazu ist die IT-Abteilung durch die Paketanalyse meist mit kaum überschaubaren Mengen an Detaildaten überlastet. Wenn wir beide Perspektiven kombinieren und traditionelle Flow-Daten mit Informationen aus der Anwendungsschicht erweitern, können wir die entsprechenden Details erhalten, die einen Einblick in die Datenkommunikation, ein flexibles Reporting und eine effektive Fehlerbehebung bei betrieblichen Problemen sowie die automatische Erkennung von Sicherheitsvorfällen bieten. Dieser Ansatz wird als angereicherte Flow-Daten bezeichnet und nutzt die Flexibilität des IPFIX-Protokolls. Nach unserer Erfahrung sind wir heute in der Lage, 95% der Netzwerkprobleme mit der skalierbarsten, kostengünstigsten und benutzerfreundlichsten Lösung auf Basis von Flow-Daten zu bewältigen.

Die bekannteste Implementierung dieser Technologie ist Cisco’s NBAR2 (Next Generation Network-Based Application Recognition). Die Flow-Datenüberwachung wird mit einer kontinuierlichen Paketanalyse kombiniert, die die Traffic-Statistik um den Namen einer Anwendung oder eines Anwendungsprotokolls erweitert. Basierend auf diesen Informationen ermöglichen moderne Flow-Kollektoren die Traffic-Berichterstattung und -Analyse.

Eines der am weitesten verbreiteten Kommunikationsprotokolle ist HTTP oder seine verschlüsselte Version HTTPS. Heute wird es für den Zugang zu Websites verwendet, aber das ist nicht seine einzige Funktion. Das Protokoll ist auch die Grundlage für die Kommunikation zwischen den Komponenten von Geschäftssystemen oder Anwendungen, die mit sensiblen Daten arbeiten (z.B. Electronic Banking). Durch die Identifizierung dieses Übertragungsprotokolls können wir die Statistik der Flow-Daten um grundlegende HTTP-Anforderungsattribute erweitern – einen Hostnamen oder URL-Informationen. Dank SNI (Server Name Indication) können wir Hostnamen-Informationen erhalten, auch wenn das HTTPS-Protokoll verwendet wird. Ebenso können wir aus der HTTP-Kommunikation andere Informationen gewinnen, z.B. das Betriebssystem und seine Version, die Identifizierung eines Browsers und seiner Version oder bei Mobiltelefonen einen Gerätetyp. Und dies ist nur ein Beispiel für viele Protokolle, für die wir L7-Informationen ohne die Notwendigkeit des manuellen Data Mining verwenden können.

Dennoch können die Flow-Daten um etwas vielleicht noch Stärkeres in der modernen Welt bereichert werden – Network Performance Monitoring (NPM). NPM-Metriken können bei der Fehlerbehebung bei der Netzwerkleistung erheblich helfen. Anhand der Server-Response-Time- und Round-Trip-Time-Metriken können wir zwischen Verzögerungen in der Netzwerkinfrastruktur (z.B. ein fehlerhafter Access Point) und Verzögerungen im Server (z.B. unzureichende HW-Ressourcen) unterscheiden. Diese Art von Informationen ist entscheidend für eine schnelle Fehlerbehebung im Netzwerk. Die Metriken für Verzögerung und Jitter sollten uns besonders interessieren, wenn wir VoIP-Anrufe oder Videokonferenzen verwenden, da sie auf eine schlechte Audio- und Videoqualität hinweisen können. Wenn wir über die Übertragung großer Datenmengen sprechen, interessieren wir uns vor allem für die Anzahl der TCP-Rückübertragungen, die auf Probleme auf der physikalischen Ebene (z.B. Interferenzen, fehlerhafte Ports) und eine geringere Bitrate hinweisen können, oder auf fehlerhafte Pakete, die auf Fehler in Kommunikationsverbindungen hinweisen können.

Und wenn dieser Informationsgehalt immer noch unzureichend ist, ermöglicht Flowmon die Auslösung einer On-Demand-Vollpaketerfassung. Dies kann manuell oder automatisch bei einem erkannten Ereignis erfolgen. In diesem Fall wird der Erfassungsfilter vom System selbstständig bestimmt, wodurch das erfasste Datenvolumen auf ein absolutes Minimum reduziert wird und nur der relevante Teil des Datenverkehrs erhalten bleibt. Dies kann natürlich in jedem Teil des Netzwerks und mit Geschwindigkeiten von 100Gbps erfolgen; mit Wireshark oder WinPCAP sind diese nicht erreichbar.

Die Vorteile der Flow-Datenüberwachung und der Application-Layer-Analyse liegen auf der Hand. Wir erhalten detailliertere Informationen über die Datenkommunikation, bessere Möglichkeiten zur Verkehrsanalyse. Gleichzeitig behalten wir die ausgezeichnete Kompressionsrate der Netzwerkverkehrsstatistik im Vergleich zum ursprünglichen Traffic-Volumen bei, um sie auf mehrere hundert Gigabit-Netzwerke zu skalieren. Außerdem aggregiert das System die wichtigsten Informationen, so dass sie auf einen Blick bereitgestellt werden können, ohne dass manuelles Data Mining mit Paketanalyse erforderlich ist. Dies führt zu einer enormen Reduzierung der mittleren Lösungszeit bei gleichzeitiger Reduzierung der für die Nutzung der Lösung erforderlichen Fähigkeiten. Mit Flowmon ist es jederzeit möglich, eine vollständige Verkehrserfassung durchzuführen, wenn notwendig, und zwar auf der gleichen Plattform.

Im ersten Teil dieses Technical Reading haben wir Unterschiede zwischen kontinuierlicher Paketerfassung und Flow-Daten im Zusammenhang mit der Verwendung dieser Technologien zur erfolgreichen Überwachung des Netzwerkverkehrs identifiziert. Lassen Sie uns die Vorteile von angereicherten Flow-Daten gegenüber der Paketerfassung zusammenfassen:

Durch ein durchschnittliches Reduktionsverhältnis von Rohdatenverkehr vs. Speicherbedarf für entsprechende Flow-Records von 500:1 (im Gegensatz zur Paketanalyse 1:1) ist die Flow-Technologie wesentlich skalierbarer.

Die Budgetanforderungen an die Paketanalyse-Technologien erlauben es selten, den gesamten Netzwerkverkehr zu überwachen. Daher werden sie nur zur Überwachung kritischer Systeme im Gegensatz zum Flow eingesetzt, bei dem die Abdeckung des gesamten Unternehmensnetzwerkverkehrs, einschließlich Rechen-zentren und Cloud, ein Standardschema ist.

Die Fehlersuche im Allgemeinen erfolgt nicht in Echtzeit. In Unternehmen dauert es oft Tage, bis ein gemeldeter Vorfall von einem Netzwerkadministrator überprüft wird. Mit nur einer begrenzten Datenspeicherdauer wäre eine retrospektive Analyse nicht möglich. Die Flow-Überwachung kann leicht die Aufbewahrung über Wochen oder Monate ermöglichen, so dass Sie Ihre Arbeit leicht priorisieren und sich auf die retrospektive Analyse konzentrieren können, wenn Sie wichtigere Aufgaben erledigt haben.

Nahtlose Bereitstellung, Integration mit bestehenden Netzwerkgeräten, Kompatibilität mit einer Vielzahl von Flow-Quellen, schnelle Schulung von Administratoren sind nur einige der Gründe, warum es so einfach ist, Flow-Technologie in Ihr Netzwerk einzuführen und einen sofortigen Mehrwert zu erzielen.

Der Detaillierungsgrad der Paketanalyse macht sie geeignet für die forensische Analyse von hartnäckigen Problemen im Deep-Dive-Bereich. Unternehmen wenden sich dem Flow zu, um die Zeit für die Ursachenanalyse zu minimieren und mehr Zeit für die Behebung von Ursachen zu gewinnen, indem sie benutzerfreundliche Dashboards und Drill-Down-Funktionen verwenden.

Eine zu detaillierte Granularität der Paketanalyse bedeutet höhere Kosten, geringere Skalierbarkeit und einen viel höheren erforderlichen Qualifikationsgrad. Allerdings ist nur ein kleiner Prozentsatz der erfassten Daten relevant. Angereicherte Flow-Daten hingegen halten die interessantesten und wichtigsten Informationen bereit, so dass 95% der Netzwerkprobleme damit gelöst werden können. Darüber hinaus ermöglicht Flowmon die bedarfsgerechte vollständige Paketerfassung für den Rest der Fälle.

Die Paketanalyse wurde mit Blick auf eine unbegrenzte Transparenz entwickelt. Sie ist gut geeignet für die zeitaufwendige Forensik von hartnäckigen Problemen. Um den normalen Geschäftsbetrieb schnell wiederherzustellen, wenden sich Unternehmen an Flowmon, um analytische Arbeitsabläufe und Automatisierung zu erhalten und so die Lösung zu optimieren.

Da immer mehr Datenverkehr verschlüsselt wird, wird die Paketanalyse nutzlos. Beim Export von Flow-Daten aus verschlüsseltem Datenverkehr konzentriert sich Flowmon auf unverschlüsselte IP-Header, die dazu beitragen, 80% der Vorfälle zu lösen. Darüber hinaus verwendet Flowmon verschiedene Techniken, um Informationen aus der Anwendungsschicht zu extrahieren, die sonst für ein unerfahrenes Auge verborgen bleiben.

Public-Cloud-Anbieter erlauben es nicht, ihr Netzwerk zu nutzen, um eine vollständige Paketanalyse zu ermöglichen. Sowohl Cloud-Provider als auch virtuelle Hypervisoren exportieren jedoch oft eine Form von Flow-Daten, die mit Flowmon kompatibel sind und eine nahtlose Bereitstellung einer hochwertigen Netzwerküberwachung ermöglichen.

Der Detaillierungsgrad der Paketanalyse macht sie geeignet für die forensische Analyse von hartnäckigen Problemen im Deep-Dive-Bereich. Unternehmen wenden sich an Flowmon, um die Zeit für die Analyse der Ursachen zu minimieren und mehr Zeit für die Behebung der Ursachen zu gewinnen, indem sie benutzerfreundliche Dashboards, kontextbezogene Präsentationen und Drill-Down-Funktionen verwenden.

Ich habe meinen Paketanalysator mit kontinuierlicher Erfassung im Einsatz. Hoffen wir also, dass mein Rolling Buffer noch die Daten enthält, die ich brauche. Glücklicherweise können wir das PCAP mit dem Traffic der IP-Adresse 192.168.222.87 herunterladen und den Traffic in Wireshark öffnen.

In der obigen Abbildung sehen wir die Kommunikation zwischen Benutzer und services.invea.com. Domain services.invea.com wird korrekt in die IP-Adresse 89.185.224.79 aufgelöst, aber nachdem die DNS-Antwort empfangen wurde, versuchte ein Benutzer, eine TCP-Sitzung ohne Antwort von der externen IP-Adresse aufzubauen. Wir müssen in unseren Firewall-Einstellungen überprüfen, ob diese Kommunikation erlaubt ist.

Das zweite Problem bezieht sich auf eine nicht existierende Domäne, die vom Benutzercomputer abgefragt wird. Wir können sehen, dass update.invea.com nicht existiert, was wahrscheinlich eine falsche Konfiguration des Benutzers und kein netzwerkbezogenes Problem bedeutet.

Ich habe Flowmon Probes an Ort und Stelle die das Netzwerk überwachen und Flowmon Collector mit Wochen der Historie von nicht gesampelten und nicht aggregierten Verkehrsstatistiken. So kann ich direkt eine DNS-Anfrage nach der Domain services.invea.com stellen.

Ich kann die IP-Adresse, die vom DNS-Server als Antwort bereitgestellt wird, sehen und nachsehen, ob der Datenverkehr zu dieser IP-Adresse geht. Es ist möglich, weil die Flows von der Probe entsprechend dem DNS mit den wichtigsten L7-Informationen aus dem DNS-Protokoll angereichert sind.

Ich sehe, dass nur SYN-Pakete ohne Antwort von einer externen IP-Adresse an das Netzwerk übertragen werden, was bedeutet, dass die Firewall-Regeln überprüft werden müssen. Neben den allgemeinen L3/L4-Informationen habe ich Einblick in TCP-spezifische Elemente wie die Standardgröße des TCP-Segments (Fenster), die mir bei der Fehlerbehebung in der TCP-Sitzung helfen können.

Die nicht existierende Domain ist ebenfalls in meinem Flow Evidence. Die Domain update.invea.com existiert nicht, so dass der DNS-Server „NXDomain“ antwortet.

Stellen wir uns eine Abteilung von Ingenieuren der Stufe 3+ in einer Bank mit 50.000 Mitarbeitern vor. Diese Ingenieure konzentrieren sich auf die Ursachenanalyse von Netzwerkproblemen, die bisher kein anderes Team lösen konnte. Zum Beispiel, um herauszufinden, warum eine VPN-Verbindung zwischen dem Kunden und der Bank, beide auf verschiedenen Kontinenten, einen Ausfall hatte. Es ist sehr häufig, dass diese Ingenieure viele Stunden damit verbringen, in Wireshark nach Petabyte von Daten zu graben, die von Hunderten von verschiedenen Systemen in einer komplizierten und heterogenen Umgebung erzeugt werden. Und genau das ist die Situation eines Flowmon-Kunden, der uns gebeten hat, eine alternative und effektivere Lösung für den Umgang mit Betriebsstörungen zu liefern.

Es ist wichtig zu sagen, dass unser Kunde eine ganze Plattform aufgebaut hat, um ihn bei seinen Netzwerkbetriebsaufgaben zu unterstützen. Es basierte auf einem kommerziellen Tool zur kontinuierlichen Paketerfassung, einer kundenspezifischen Open-Source-Software zur Flow Überwachung und einem SNMP-basierten Tool, das Datenübertragungs-Wärmekarten in Echtzeit anzeigt.

Bald wurde klar, dass die Wartung, Unterstützung und Aufrüstung der kundenspezifischen Lösung für den täglichen Betrieb zu teuer und zeitraubend war. Deshalb suchten sie die NetFlow/IPFIX-Technologie, um die ursprüngliche Lösung zu ersetzen. Die IT-Abteilung der Bank suchte nach einer Lösung, die die ursprüngliche vollständig ersetzt. Obwohl das Budget kein Thema war, war die Wahl nicht so einfach, wie sie zuerst erschien. Beim Testen verschiedener Anbieter, war das Problem manchmal die Datenaggregation, manchmal keine Virtualisierung, aber immer war es die Langsamkeit in Bezug auf die Zeit, die benötigt wird, um Messergebnisse zu liefern.

Ihre Traumlösung sollte:

• nicht nur kontextbezogene Top-Level-Dashboards bieten, sondern auch ein Dashboard, das ein manuelles Drill-Down für jeden Flow ermöglicht.
• die gespeicherten Daten nicht aggregieren und die Rohdaten so lange speichern, wie das Storage freie Kapazität hat.
• nicht unbedingt von den eigenen Sensoren abhängig sein, da sie es sich aufgrund ihrer heterogenen Umgebung nicht leisten können, in eine einzige Technologie eingebunden zu sein.
• virtualisiert sein, so dass Management und Migration so flexibel wie möglich sind.
• Flow-Überwachung mit der On-Demand-Vollpaketerfassung kombinieren.
• vor allem die Ausgabe der gemessenen Statistiken der Flow-Daten schneller liefern als die Plattform, die sie vor zehn Jahren aus einem Open-Source-Tool selbst aufgebaut haben.

Dann stieß das Team auf Flowmon, das seinen Bedürfnissen voll entsprach. Seit dem Proof-of-Concept-Projekt ist Flowmon zu einem wichtigen Bestandteil des Tool-Sets geworden. Es ist zum eigentlichen Workflow der Ursachenforschung geworden. Die Ingenieure beginnen nun mit dem Dashboard, gehen in die Top-Level-Statistik, vertiefen sich in die Ebenen von NetFlow und konzentrieren sich dann nur noch auf einen kleinen Teil des Datenverkehrs, wo sie die vollständige Paketerfassung durchführen können.

Die Dynamik und Vielfalt der heutigen Netzwerke stellt den vorherrschenden Ansatz der Netzwerküberwachung in Frage. Angesichts steigender Netzwerkgeschwindigkeiten, Sichtbarkeitslücken durch Migration zu Cloud, IoT und softwaredefinierten Netzwerken haben Paketerfassungslösungen Mühe, die erwarteten Ergebnisse schnell und zu einem vernünftigen Preis zu liefern.

Paketerfassungslösungen wurden zu einer Zeit entwickelt, als die Dynamik der heutigen Netzwerkumgebungen noch schwer vorstellbar war. Heutzutage funktionieren sie gut in spezifischen Anwendungsfällen, aber sie können die Flexibilität, Skalierbarkeit und Benutzerfreundlichkeit von Flow-Daten in den meisten der alltäglichen Anwendungsfälle, mit denen Netzwerkingenieure konfrontiert sind, nicht bewältigen.

Wir haben einen Anwendungsfall demonstriert, bei dem Flow-Daten mit erweiterter Transparenz ebenso leistungsfähig sind wie die vollständige Paketerfassung und Paketanalyse. Auf der anderen Seite kann man sagen, dass Sie auch bei erweiterter Flow-Level-Visibilität immer noch mit Problemen konfrontiert sein können, bei denen die Analyse von PCAPs unvermeidlich ist.

Wir von Flowmon Networks glauben, dass die Zusammenführung der Sichtbarkeit auf Flow- und Paketebene in einer vielseitigen Lösung die Technologie ist, die Ihnen hilft, sich auf zukünftige Leistungs- und Kapazitätsanforderungen einzustellen. Also, lassen Sie uns bei Bedarf eine kontinuierliche Flow Überwachung und Paketerfassung durchführen. Am Ende des Tages werden Sie höchstwahrscheinlich PCAPs weniger analysieren müssen, als Sie erwarten. Testen Sie Flowmon und sehen Sie, wie es Ihrer Organisation helfen kann.