05. 03. 2024
Unified Monitoring
09. 06. 2016
Luca Di Stefano
Uncategorized
Netzwerk Performance Monitoring: Port Mirroring vs. Network TAPs vs. Hardware Timestamp
Bis vor kurzer Zeit war die Überwachung des Netzwerk Traffics einzig und allein darauf ausgerichtet die Typologie des Traffics und die Anzahl der übertragenen Pakete/Bytes zu ermitteln. Diese Informationen sind wichtig für:
- die Analyse von Anomalien
- die Optimierung des Netzwerkverkehrs (Ausgeglichenheit des Traffics)
- die Dimensionierung der Infrastruktur
Um Informationen zum Netzwerk Traffic zu sammeln, wird üblicherweise NetFlow verwendet. NetFlow kann einerseits von den Netzwerkgeräten selbst generiert werden, insofern diese Funktionalität vorhanden ist, ansonsten können Ad Hoc Geräten, wie z.B. die nBox, eingesetzt werden, um NetFlow zu generieren. Empfohlen ist dabei jedoch die Variante mit einer nBox, da dadurch eine zusätzliche Belastung der Netzwerkgeräte vermieden wird und keine Aggregation der Daten stattfindet.
Port Mirroring
Wird ein solches externes Gerät für die NetFlow-Generierung verwendet, wird Port Mirroring genutzt, um den Traffic zu duplizieren und an die Sonde (in unserem Fall die nBox) zu schicken.
Für die quantitative Analyse des Traffics ist Port Mirroring ausreichend, da es hierbei nur wichtig ist, dass alle Pakete innerhalb eines (halbwegs) vernünftigen Zeitraums an die Sonde weitergeleitet werden.
Zu beachten ist hierbei, dass Packet Ingress Time (in der Grafik T1 und T2) und Packet Mirror Egress Time (T3 und T4) hier weit auseinander liegen.
Port Mirroring ist in den modernen Netzwerken nicht mehr ausreichend
Da das Thema Netzwerk Performance Monitoring/Management immer wichtiger wird (APM, NPM) gewinnen die Einschränkungen durch das reine Port Mirroring (SPAN) zunehmend an Bedeutung. Die Zeit, die die Switche benötigen, um die Kopien der Pakete zu erstellen und diese anschließend weiterzuleiten, verfälscht die für die Analyse der Netzwerk Performance verwendeten Werte. Wenn es darum geht Netzwerk Latenzen im Bereich von Micro Sekunden zu bewerten, wie es in modernen Netzen immer häufiger notwendig wird, ist absolute Exaktheit gefordert. Erschwerend kommt hinzu, dass einige Netzwerkgeräte die Pakete nicht sofort weiterleiten sondern so lange anstauen bis eine gewisse Anzahl zum Versenden bereit ist. Dadurch sind die (ursprünglichen) Zeitabstände zwischen den Paketen nicht mehr ersichtlich, wodurch die Zeitmessung der Sonde weiter verfälscht wird.
Um diese Einschränkungen des Port Mirrorings zu umgehen, bieten sich zwei Lösungsmöglichkeiten an: Netzwerk TAPs und Hardware Timestamps.
Variante 1: Network TAPs
Netzwerk TAPs sind Geräte deren Zweck die sofortige Spiegelung des Traffics ist. Die Pakete werden also nicht gesammelt, sondern sofort dupliziert und an die Sonde weitergeleitet.
Netzwerk TAPs schützen zuverlässig von Paketverlusten beim Mirroring, machen kein Buffering und reduzieren die Arbeitslast der Switche. TAPs sind für Kupfer- und Glasfaser-Verbindungen erhältlich und relativ preiswert.
Variante 2: Hardware Timestamps
Im Handel sind spezielle Switche erhältlich, welche den Paketen einen Zeitstempel (Timestamp) verpassen bevor sie im Ausgangsbuffer des Port Mirroring aufgereiht werden. Ist dieser Zeitstempel vorhanden, nutzt die nBox diesen anstatt den Timestamp vom Zeitpunkt wenn das Paket bei der nBox ankommt. Dadurch wird die Latenz welche vom Port Mirroring (Erhalt, Aufreihung, Versendung) generiert wird von der Analyse ausgeschlossen. Diese Geräte sind zwar nicht so kostengünstig wie die Netzwerk TAP-Variante, ermöglichen aber einen höheren Grad an Flexibilität (Mirror mehrerer Ports, Konfiguration ohne Unterbrechung des Service/Hot Configuration) und liefern exakte Daten.
Abschließend können wir zusammenfassen, dass Port Mirroring ein gutes Ergebnis liefert wenn sie als IDS (Intrusion Detection System), oder für die quantitative Analyse des Traffics einsetzen. Für ein detailliertes Netzwerk Performance Monitoring, bei welchem die Zeiten ausschlaggebend sind, sind Network TAPs eine gute, ausreichende und vor allem kostengünstige Lösung.
Luca Di Stefano
Solution Architect at Würth Phoenix
Hi everyone, I’m Luca, graduated in electrical engineering from the University of Bologna. I am employed by Würth Phoenix since its foundation. I worked mainly as enterprise architect and quality assurance engineer. Previously I was involved in systems measurement and embedded systems programming. I have gained experience on Unix (Solaris, HPUX), Windows, and C, C + +, Java. I personally contribute to the Open Source community as beta tester and developer. During my spare time I love piloting airplanes fly over the beautiful Alps. I practice many sports: tennis, broomball, skiing, alpine skiing, volleyball, soccer, mountain biking, middle distance, none have a sample but the competition excites me! I love hiking, tracking and traveling.
Author
Latest posts by Luca Di Stefano
27. 04. 2017
Uncategorized
Chi si sta mangiando la banda? Scoprilo con ntopng
27. 04. 2017
Uncategorized
Identifizieren Sie Bandbreitenfresser mit ntopng
22. 09. 2016
NetEye, Real User Experience Monitoring
Warum erhöht sich meine Netzwerk-Latenz an Arbeitstagen?
22. 09. 2016
NetEye, Predictive Analysis, Real User Experience, Unified Monitoring
Why does my local network latency increase during working hours?