Netzwerk-Analyse

Wenn nicht anders vereinbart / gewünscht, werden grundsätzlich alle Daten erfasst (kein Capture-Filter). Das wird sogar dann empfohlen, wenn es „nur“ um Störungen im VoIP-Bereich geht. Die tägliche Praxis zeigt nämlich, dass die tatsächlichen Ursachen (‚root cause‘) häufig gar nicht im VoIP-System selbst, sondern im non-VoIP Kontext liegen.

Nein. Standardmäßig ist auf den Mess-Servern ein Capture-Limit von 70 Byte konfiguriert, d.h. alle Datenpakete werden bereits bei der Erfassung automatisch nach 70 Byte abgeschnitten. So werden lediglich die Header (MAC, VLAN, IP, UDP/TCP) und einige wenige Bytes des jeweiligen Datenprotokolls (z.B. Art der ICMP-Message, Typ des IGMP-Reports) aufgezeichnet. Die eigentlichen Inhalte (Gespräche, Videos, Daten) sind damit überhaupt nicht zugänglich.

Die Grafik verdeutlicht am Beispiel des G.711 Codecs mit 160 Byte Payload, dass bei 70 Byte Capture-Limit pro Paket immer nur kleinste Sprach-Fragmente von 16 Byte (10 %) erfasst werden – im Falle von VLANs sogar nur 12 Byte (7,5 %). Gespräche lassen sich so definitiv nicht abhören.

Darüber hinaus hat das Capture-Limit den Vorteil, dass die Aufzeichnungskapazität der Mess-Server (1 TB) nicht vorzeitig erschöpft ist.

In ganz besonderen, durch den Auftraggeber / Endkunden explizit schriftlich zu bestätigenden Ausnahmefällen (z.B. Analyse der SIP-Signalisierung) müssen zur Erfüllung der Aufgabenstellung die Datenpakete allerdings in voller Länge erfasst werden. In solchen Fällen wird jedoch das selektive Messen empfohlen (d.h. mit Capture-Filter ‚SIP‘), sodass andere Daten unberücksichtigt bleiben.

Idealerweise stellt der Auftraggeber / Endkunde zum Ende der Messung eine externe USB 3.x SSD entsprechender Größe (z.B. 1 TB, 2 TB, …) bereit. Die Messdaten werden dann von den Mess-Servern direkt auf die SSD gesichert und dort verarbeitet. Zum Projektende erfolgt die Archivierung (Verschlüsselung) aller originalen und verarbeiteten Messdaten auf der SSD sowie deren Rückgabe an den Auftraggeber / Endkunden.

Die Verarbeitung / Auswertung erfolgt mit einer speziell entwickelten, äußerst leistungsfähigen und effizienten modularen Tool-Suite, deren Funktionalität die Möglichkeiten marktüblicher Tools deutlich übersteigt.

VoIP-Daten werden (sofern in den Messdaten vorhanden) zum Zwecke einer nachgelagerten applikationsspezifischen Analyse / Diagnose / Korrelation herausgefiltert.

Darüber hinaus werden weitere Merkmale / Dienste / Protokolle, wie z.B. Broad- / Multicasts, QoS (VLAN-Prio, DiffServ), low TTL, ICMP, IGMP, DNS, MDNS, DHCP, ECN, TCP Zero Window, etc. (Funktionsumfang ist Gegenstand permanenter Erweiterungen) immer automatisch separiert, statistisch ausgewertet und -sofern Auffälligkeiten festgestellt wurden- zusammen mit den Verursacherlisten ergänzend zum Sachverständigenbericht als sog. Referenz-Traces zur Verfügung gestellt. Der jeweilige Verursacher kann so an Hand der separierten Traces die Situation im Bedarfsfall mit Tools seiner Wahl nochmals nachvollziehen.

Die originalen Messdaten selbst bleiben dabei natürlich als Nachweis immer unverändert erhalten.

Die aus mehreren Schritten bestehende, sehr ins Detail gehende Auswertung beginnt nach Beendigung der Messdaten-Erfassung. Wesentlichen Einfluss auf die Dauer der Auswertung haben neben der Menge der Messdaten (GB .. TB) auch der Umfang der Aufgabenstellung sowie die Komplexität der zu analysierenden Störungen. Die Bereitstellung der validierten Ergebnisse (ausführlicher Sachverständigenbericht inkl. Anlagen) kann frühestens eine Woche später erfolgen – bei besonders großen Datenmengen ist ggf. auch mehr Zeit erforderlich. Im Interesse des Endkunden / Auftraggebers gilt der Grundsatz „Sorgfalt vor Schnelligkeit“.

Bei Feststellung von gravierendem Handlungsbedarf erfolgt jedoch zeitnah eine Vorab-Information.

Alle Mess-Server verfügen über eine 1 TB Festplatte. Jeden Tag um 00:00 Uhr startet eine automatische Archivierungsroutine (Komprimierung) der Messdaten des Vortages, sodass wieder Speicherplatz freigegeben wird.

Nein. Die Auslastung wird üblicherweise durch (z.B. SNMP-basierte) Netzwerkmanagement-Tools ermittelt. Bestimmungsgemäß weisen deren Daten i.d.R. natürlich nur einen begrenzten Informationsgehalt auf (z.B. Packets / Bytes in / out). So ist es trotz geringer (Gesamt-) Auslastung durchaus möglich, dass einige Funktionen / Dienste / Protokolle unbemerkt bereits alarmierende Zustände / Situationen anzeigen / aufweisen.

Ja. Unabhängig vom Ziel der Messung (Troubleshooting, Statusmessung, Abnahmemessung, etc.) ist es nie erforderlich (und natürlich auch unmöglich), den gesamten Verkehr eines Netzwerks zu erfassen. Ein repräsentativer Anteil davon ist völlig ausreichend – es müssen dazu lediglich Messpunkte mit einer der Aufgabenstellung entsprechenden praktischen Relevanz bestimmt werden.

Es gibt hauptsächlich zwei Gründe, die gegen die Verwendung von Mirror-Ports sprechen:

• offenbar läuft der Replikationsprozess auf den Switches mit untergeordneter Priorität. Das kann in der Praxis bei der Bereitstellung des gespiegelten Verkehrs durchaus zu Paketverlusten führen, welche der originale Datenverkehr nicht aufweist. Bei „normalen“ Daten wird dieser Sachverhalt praktisch kaum bemerkt. VoIP-Verkehr, d.h. (S)RTP-Pakete sind hingegen mit fortlaufenden Sequenznummern versehen, was Paketverluste sofort erkennbar macht. Mirror-Ports werden daher als -zumindest latent- unzuverlässig angesehen.
• i.d.R. werden die beiden Übertragungsrichtungen (Rx / Tx) eines zu spiegelnden Ports an einem physischen Mirror-Port bereitgestellt (Tx), was zu einem potenziellen Bottleneck führt. Darüber hinaus gestaltet sich die Auswertung dadurch aufwändiger.

Netzwerk-Analysen werden natürlich immer passiv durchgeführt, d.h. Erfassung von Messdaten – ohne die (aktive) Erzeugung von Testdaten. Folglich besteht ein passiver Messpunkt immer jeweils aus einer Kombination von TAP (Test Access Port – ausschließlich für die Konnektivität zuständig) und Mess-Server, welcher die über den TAP ausgekoppelten Messdaten aufzeichnet.

TAP steht für ‚Test Access Port‘. Das sind kleine Cu- oder LWL-Devices, welche einfach temporär in die zu messende Verbindung eingeschleift werden, um deren Verkehr blockierungsfrei und mit wirespeed an zwei Monitor-Ports, d.h. also getrennt nach Übertragungsrichtung (Rx / Tx), bereitzustellen. An den beiden Monitor-Ports des TAP ist zum Aufzeichnen der Messdaten ein Mess-Server mit Dual-Port Interface-Karte angeschaltet. Die TAPs selbst sind also lediglich für die Konnektivität zuständig – vermeiden dabei jedoch die typischen Nachteile der Mirror-Ports.

Nein. TAPs sind voll transparent – besitzen weder eine MAC-Adresse, noch benötigen Sie eine IP-Adresse.

• Kupfer, RJ45-Stecker, 1 GB/s
• Multimode-LWL (50µm Querschnitt, 850nm Wellenlänge), LC-Stecker, 1 und 10 GB/s
• Singlemode-LWL (9µm Querschnitt, 1310nm Wellenlänge), LC-Stecker, 1 und 10 GB/s

Nein. Auf Grund ihrer geringen Baugröße – sie beträgt lediglich [B x T x H]:

• Kuper-TAP: 11,3 x 13,3 x 3 cm oder 11,3 x 12,3 x 3 cm
• LWL-TAP: 11,3 x 9 x 3 cm oder 11,3 x 8,5 x 3 cm

benötigen die portablen TAPs keinen 19“ Einbauplatz.

Kupfer-TAPs besitzen ein Steckernetzteil. Fällt dieses Steckernetzteil aus, bleibt die Verbindung, in welcher sich der TAP befindet, trotzdem bestehen. Allerdings kann der TAP nun keine Messdaten mehr zum angeschlossenen Mess-Server weiterleiten.

LWL-TAPs sind rein passiv – benötigen somit kein Steckernetzteil, welches ausfallen könnte. Die Bereitstellung der Messdaten an den Monitor-Ports des TAP wird über eine Aufteilung (Split) der Glasfasern realisiert. Die Split-Ratio der eingesetzten TAPs beträgt 50:50, d.h. der zu untersuchenden Verbindung stehen 50 % des Lichts zur Verfügung, während die anderen 50 % dem Mess-Server zugeführt werden. Im normalen Enterprise Umfeld (Campus) sind 50 % völlig ausreichend.

Grundsätzlich gilt: je mehr repräsentative Messpunkte, desto informativer die Ergebnisse. Es stehen bis zu 10 Messpunkte zur Verfügung. Deren konkrete Anzahl ist projektbezogen abzuwägen.

Die konkrete Auswahl geeigneter repräsentativer Messpunkte ist durch die Aufgabenstellung determiniert. Grundsätzlich eignen sich jedoch Router (allg. Übergänge zu Carriern, anderen Standorten oder Netzen), Firewalls, SBCs, Gateways, Uplinks, zentrale Server, Basis-Stationen, etc., sowie nicht zuletzt exemplarisch auch die Netzwerk-Peripherie (Benutzer).