Unter diesem Begriff werden allen alle technischen Maßnahmen verstanden, die Erkenntnis über die Datenkommunikation in einem LAN geben.
Die Kommunikation via WAN gilt als Teil, der LAN-Analyse, insofern die LAN-zu-LAN-Kopplung via WAN heute als alltäglicher Bestandteil der Datenkommunikation anzusehen ist. Aus dieser Sicht wäre der umfassendere Begriff der Netzwerk-Analyse neutraler und weniger missverständlich.
LAN-Analyse wird oft sinngleich mit Netzwerk-Analyse verwendet. Dies ist nicht grundsätzlich falsch; Abweichungen der Begriffe wären, wollte man sie definieren, eher unbedeutend.
Unverzichtbar sind LAN-Analysatoren bzw. LAN-Analyzer. Hierunter ist in jedem Falle Software zu verstehen in Kombination mit mehr oder weniger spezieller Hardware zum Zwecke des Erfassens, Aufzeichnens und Auswertens von LAN Traffic.
Für forensische Analyse sind noch zusätzliche Hardware-Erfordernisse zu erfüllen, da Dauer-Aufzeichnungen von Datenverkehr die größtmögliche verfügbare Leistung benötigen.
Zu einem Netzwerk gehören die kommunizierenden (Daten austauschenden) Datenendgeräte ( DTE, Data Terminating Equipment ), also etwa: Client-PCs, Server, Printer (Drucker).
LAN-Analyse umfasst die Untersuchung (a) des Teils der Datenkommunikation, der unmittelbar das LAN selbst betrifft -und- (b) des Teils, der den Daten-Dialog der Teilnehmer betrifft (und nicht unmittelbar das LAN).
Umfassende System-Analyse umschließt z.B. auch die Windows-Registry von Client und Server. Die hierzu passende Software im Sinne von Experten-System ist RegCheck von Synapse:Networks.
Netzwerk-Analyse ist also der umfassendere Begriff und schließt die LAN-Analyse mit ein.
Bei der Online-Analyse werden die Erkenntnisse während der Daten-Erfassung (bzw. während des Capturings) in Echtzeit gesucht.
Bei der Offline-Analyse werden die während der Online-Phase aufgezeichneten Messdaten bzw. Trace Files nachträglich ausgewertet.
Online-Analyse hat den Vorzug, sofort bzw. noch während der Messung zu Aussagen zu kommen. Nachteil ist, dass die Prozessor-Zeit nicht ausreicht, um bei hoher Paket-Rate außer einfachen Statistiken noch komplexe Fehler-Szenarien berechnen bzw. entdecken zu können.
Offline-Analyse liefert - was ihr Nachteil ist - die Ergebnisse später, dafür aber in wesentlich größerer Tiefe, weitaus umfassender und genauer.
Beide Formen der LAN-Analyse schließen sich nicht aus, im Gegenteil - sich ergänzen sich.
Jedoch sind die meisten LAN-Analyzer nur höchst eingeschränkt in der Lage, wirkungsvolle Offline-Analyse zu betreiben. Das hierzu am Markt eindeutig führende Werkzeug ist TraceMagic von Synapse:Networks.
Für die Online-Analyse und Messdaten-Aufzeichnung sind leistungsfähige LAN-Analyzer erforderlich, die schnell genug arbeiten, um Paket-Verluste durch Buffer Overflow zu vermeiden. Ein wegen seines schnellen Assembler-Codes empfehlenswerter Analyzer ist EtherPeek von WildPackets. Dieser und andere Analyzer werden besprochen im Abschnitt "LAN-Analyzer".
1 = Physical (mit Kabel, Stecker, Buchse, Erdung, ggf. auch Repeater, Hub, Switch) 2 = Data-Link (samt MAC Layer) (mit Repeater, Hub, Switch) 3 = Network (mit Routing und auf Layer-3 arbeitender Redundanz)
Zur LAN-WAN-Analyse gehört in jedem Falle zwingend die Betrachtung der Übertragungswege bzw. Übertragungstechnik, im OSI-Modell abgebildet auf den Schichten 1+2 (Layer 1 = Physical; Layer 2 = Data-Link; Layer 3 = Network) einschließlich dem MAC-Layer.
Zu den einfachen Fehlern der Übertragungswege gehören Signal-Verfälschungen (u.a. sichtbar in CRC Prüfsummen-Fehlern), der Wegfall von Kabel-Verbindungen und das Fehl-Leiten von LAN-Paketen zwischen Routern.
Fehler durch Signal-Dämpfung, Nah-Nebensprechen (NEXT) und dergleichen mehr sind seit Abschaffung des Koax-Kabels eher selten geworden. Sofern die Längen-Beschränkungen der verwendeten Kabel eingehalten werden, sind derlei Fehler eher unwahrscheinlich.
Mit der Ersetzung des Koax-Kabels durch das Twisted Pair-Kabel sind jedoch nicht allle physikalischen Probleme verschwunden. Geblieben sind zum Teil massive Erdungs-Probleme, im Wesentlichen dadurch erzeugt, dass Erdung als Problem unterschätzt und beim Aufbau von Kabelschränken übereilt gearbeitet wird.
Fehler in Switches haben sich als eher selten heraus gestellt. Switches der letzten Generationen arbeiten ganz überwiegend zuverlässig. Paket-Verluste durch Buffer Overflow können zwar auftreten (und sind niemals prinzipiell voll auszuschließen), sind aber allgemein durch die Switch-eigenen Statistiken schnell und zuverlässig erkennbar. LAN-Analyse in dem Sinne, dass ein LAN Analyzer eingesetzt werden müsste, ist in solchen Fällen oft überflüssig.
Vielmehr bedarf die LAN-Analyse oft der Unterstützung durch das Vorlegen von Switch/Router-Statistiken. Denn bei der Frage, ob Übertragungswege zwischen A und B möglicherweise gestört waren, sind Log-Dateien z.B. des SNMP-Managers hilfreich (voraus gesetzt, dass Switches und Router per SNMP-Trap meldungen über Leitungs-Ausfall etc. versenden bzw. dass die SNMP-Management-Console derlei Statistiken zuverlässig abfragt).
Ausfall von Übertragungswegen führt zu Paket-Verlusten. Und Paket-Verluste wiederum lassen sich indirekt nachweisen über Paket-Wiederholungs-Übertragungen bzw. Retransmissions (z.B. TCP ReTx).
Insofern ist eine Layer-2-Analyse bzw. Layer-3-Analyse immer zugleich auch eine Layer-4-Analyse (und umgekert), denn zum Nachweis von Paket-Verlusten direkt auf Layer-2 müsste jeder Teil-Abschnitt bzw. jedes LAN-Segment mit einem LAN Analyzer ausgestattet werden, und dann müssten die Messdaten der Teil-Abschnitte am Ende noch verglichen werden. Dies ist praktisch nicht möglich, zumindest nicht mit vertretbarem Aufwand, und schon gar nicht mit vertretbarer Aussicht auf Erfolg.
Eine Layer-4-Analyse jedoch kann zuverlässig Layer-2-Fehler und Layer-3-Fehler aufdecken - und kann sogar den Ort des Fehlers sichtbar machen, sofern alle an TCP ReTx beteiligten IP-Teilnehmer in einer Verbindungs-Matrix erfasst werden. Wird diese Matrix auf die geografische LAN-Topografie herunter gebrochen, stellt sich meistens heraus: Alle an Retransmissions beteiligten Dialoge durchlaufen immer den selben Punkt im LAN - und dort ereignen sich folglich die Verluste.
Zuverlässige Layer-2-Analyse verlangt also eine intelligente Layer-4-Analyse. Nicht jedes Werkzeug ist in der Lage, diese Rückschüsse durch lesbare Aufbereitung der Daten zu liefen. Ein Beispiel für die Fähigkeit, dieses schnell und übersichtlich zu liefern, stellt das Experten-System TraceMagic dar.
Es zeigt sich, dass Netzwerkanalyse die gleichzeitige Betrachtung mehrere (wenn nicht aller) OSI-Schichten verlangt.
2 = Data-Link (sofern verbindungs-orientiert gearbeitet wird, also z.B. mit LLC-II, nicht LLC-I) 4 = Transport (sofern verbindungs-orientiert gearbeitet wird, also z.B. mit TCP, nicht UDP)
War der Übertragungsweg im Netzwerk fehlerfrei und richtig gewählt, kann trotzdem das Dialog-Verhalten fehlerhaft sein. Allgemein wird das Dialogverhalten bestimmt von der Applikation sowie dem entsprechenden Kommunikations-Protokoll, welches Applikations-Dialoge unterstützt; in den meisten Fällen ist dies TCP - Transmission Control Protocol .
Deren wesentliche Funktion ist die sog. Data Flow Control bzw. Datenfluss-Steuerung. Zu ihr gehören der geregelte Aufbau, Erhalt und Abbau einer jeglichen Daten-Sitzung. Diese Funktion sichert den Daten-Dialog gegenüber Störungen ab und wird als verbindungsorientiert bezeichnet.
TCP ist verbindungsorientiert und bietet die wesentlichen Merkmale der Datenfluss-Steuerung. Der "kleine Bruder" von TCP, das User Datagram Protocol UDP, bietet diese Sicherung nicht, und gilt demnach als verbindungslos: UDP kontrolliert nicht den Dialog-Ablauf, sondern sendet Daten-Pakete ohne Rücksicht auf Verluste (sprichwörtlich).
In rund 1/3 bis 2/3 aller Fälle sind Fehler oder Schwächen der Namensdienste daran beteiligt, dass Applikationen nicht richtig arbeiten und Anwender Störungen wahrnehmen.
Die wesentlichen Namensdienste sind NetBIOS, WINS und DNS; in Novell-Umgebungen kommen noch NDS und SLP hinzu.
4 = Transport (sofern verbindungs-orientiert gearbeitet wird, also z.B. mit TCP, nicht UDP) 7 = Application (etwa: SMB/NCP/NFS; Lotus-Notes; SAP/R3 etc.)
Ist auch der Dialog fehlerfrei (also der Kommunikationsteil des Daten-Austauschs), so kann doch der logische Hintergrund des Dialogs gestört sein, etwa veranlasst durch Fehler in der Anwendungs-Software oder in einem Treiber.
Die physikalische Antwortzeit (die Summe der Signal-Laufzeiten sowohl von Client-Anforderung wie Server-Antwort) offenbart Einsichten in die Beschaffenheit des die Signale übermittelnden Netzes.
ART = Application Response Time
Die logische Antwortzeit (die zwischen Daten-Anforderung und Daten-Rückgabe verstrichene Zeit) gibt Einsichten in die Verzögerungen, die im Server intern bei der Bearbeitung und Bereitstellung von Daten entstehen.
Das Setzen von Filtern während der Aufzeichnungs-Phase (Capturing) ist nur selten günstig. Herkömmliche LAN-Analyzer verfügen zwar über passable Filter-Funktionen, erlauben aber letztlich nur die Filterung ziemlich kleiner Daten-Bestände, da sich die Filter immer nur auf eine einzige Trace-Datei beziehen.
Das nachträgliche Filtern großer Mengen von Messdaten ist möglich mit TraceMagic; insofern ist der Zwang zu Online-Filtern nicht (nicht mehr) gegeben; schließlich kann beliebig mit Offline-Filtern gearbeitet werden.
