Eine der wichtigsten Voraussetzungen bei der Protokollanalyse ist ein fundiertes Protokollverständnis. Ohne dieses Verständnis erhalten Sie nur schwer Informationen in Form nutzbarer Ergebnisse. Am Markt finden sich inzwischen verschiedene Analysewerkzeuge, so genannte Expertensysteme, die das fehlende Protokollverständnis teilweise ausgleichen können. Diese Art der Fehleranalyse funktioniert jedoch nur bei einfachen Fehlern. Expertensysteme werten die im Netzwerk vorgefundenen Protokollrahmeninformationen sowie Sende- und Empfangsinformationen auf Basis der im Protokoll vorgeschriebenen Werte aus und stellen die Abweichungen in einem Report dar. Damit entlarven Sie schnell fehlerhafte Endgeräte und eine fehlerhafte Konfiguration, allerdings sind diese Programme bei tieferen Fehleranalysen überfordert. Um zu belastbaren Analyseergebnissen zu kommen, bedarf es eines vollständigen Verständnisses des jeweiligen Systems (also etwa der Clients, Server oder Switches). Im Rahmen dieses Artikels zeigen wir Ihnen die wichtigsten Netzwerk-spezifischen Grundlagen anhand eines Beispielszenarios auf.

Zuerst einmal gilt es, sich einen Überblick über ein klassisches Layer 2 beziehungsweise Layer 3-Netzwerk zu verschaffen. Bild 1 veranschaulicht die wichtigsten Aspekte. Das Netzwerk besteht (von links nach rechts betrachtet) aus dem Anwender-Desktop (Client), danach dem Access-Switch, dem Backbone-Switch und dem Server-Switch. Der Server ganz rechts ist an den Server-Switch angebunden.


Bild 1: Die klassische Netzwerkstruktur mit Layer 2 und Layer 3

Um im Netzwerk eine Protokollanalyse durchzuführen, gibt es verschiedene Herangehensweisen. Diese Fälle unterscheiden sich grundsätzlich nur in ihrer Wirkungslogik. Hier geht es um eine direkte oder indirekte Wirkung. Eine direkte Wirkung erhalten Sie beispielsweise dann, wenn Sie auf dem Client oder Server mit einem Protokollanalysator arbeiten. In diesem Anwendungsfall werden alle relevanten Kommunikationsinformationen analysiert, indem sich das Werkzeug (beispielsweise das Programm Wireshark) im TCP/IP-Stack des Servers oder des Clients direkt vor das Netzwerk-Interface integriert. Somit wird die gesamte Kommunikation (Broadcasts, Multicasts und Unicasts), die über das Netzwerk-Interface übertragen wird, vom Analyseprogramm erfasst und kann entsprechend untersucht werden. Beim in Bild 2 dargestellten indirekten Beispiel wird das Analysewerkzeug (im Regelfall ein Notebook mit dem Analyseprogramm Wireshark) über einen so genannten Portmirror an einen Switch angeschaltet.

Dabei muss auf dem entsprechenden Switch die Konfiguration so verändert werden, dass beispielsweise die gesamte Kommunikation von Port 48 durch das Gerät auf Port 10 gespiegelt wird. Somit wird die gesamte Kommunikation ebenfalls über das Interface von Port 10 übertragen. Bei dieser Messung kann jedoch der Fall eintreten, dass nicht mehr die gesamten Daten der für die Anwendung relevanten Kommunikationsströme aufgezeichnet werden können. Die Ursache ist in der Funktion der heutigen Switches begründet.

Eigenheiten heutiger Switches
In der Vergangenheit wurden einzelne Ethernet-Segmente mit so genannten Brücken verbunden. Bei Brücken handelt es sich um die Vorläufer der heutigen Layer 2-Switches. Diese kannten die Kommunikationsteilnehmer auf beiden Seiten und haben in der Broadcast Domain auf dem Layer 2 die benötigte Kommunikation sichergestellt. Diese früher realisierten Ethernet-Netzwerke stellten somit eine Hintereinanderreihung von Ethernet-Segmenten dar, die durch Brücken miteinander verbunden wurden. Danach wurden diese Bridge-basierenden Segmente durch sogenannte Hubs ergänzt. Diese Geräte ermöglichten es, die Kabel in Sternform zu installieren. In der Folge entwickelte die Netzwerkindustrie die Store-and-Forward-Switches. Diese vereinen die Hub- und Bridgefunktion in einer Komponente. Aufgrund der heute meistens vorliegenden Sternform und der vorhandenen Bridge-Funktion in den heutigen Layer 2-Switches entscheidet der Switch, was jeweils auf den entsprechenden Port gesendet wird. Dies bedeutet, dass im Regelfall ein normaler Port eines Switches nur den gerichteten Unicast-Traffic an die am Port angeschaltete MAC-Adresse sieht. Hinzu kommen der Broadcast-Traffic der Broadcast-Domain und, falls durch den Client angefordert, der entsprechende Multicast-Traffic. Im Gegensatz zu früheren Hubs, bei denen der gesamte Traffic sichtbar war, ist dies deutlich weniger. Dies muss berücksichtigt und in die Vorbereitung einer Protokollanalyse aufgenommen werden.


Bild 2: An den Mirror Port angeschlossener Netzwerkanalysator

Aufgrund des Mirror Ports kann der angeschlossene Netzwerkanalysator nur noch die Kommunikation sehen, die auf Basis des gespiegelten Interfaces übermittelt wird. Aus diesem Grund empfiehlt es sich, mit einem Port Mirror zuerst das Trunk-Interface des Switches zu spiegeln. Da über dieses Interface die gesamte ein- und ausgehende Kommunikation des Switches läuft, sind in dem aufgezeichneten Datenstrom auch die Client-spezifischen Anteile der anwendungsrelevanten Kommunikation enthalten. Tritt auf dem Trunk-Interface zu viel Datenverkehr auf (was durch mehrere parallele Verbindungen sehr schnell passieren kann), bleibt nichts anderes übrig, als den jeweiligen Client-Port zu spiegeln. In diesem Fall müsste, bezogen auf den Anwendungsfall in Bild 2, anstatt des Trunkports 48 der Port 1 vom Client als Mirror-Port genutzt werden.


 

                                                Seite 1 von 3                     Nächste Seite>>

Michael Engelhardt/dr/ln