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.

Port Mirroring

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.

Network TAP

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.

TAP Fibra TAP Rame

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.

Port Mirroring with Hardware Timestamp

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

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

Luca Di Stefano

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive